I have been fighting with this for a while now. I need to prototype SOA, and with it, the registry. I have been fiddling with jUDDIv3 on JBoss SOA Platform 5, but there don't appear to be any tools that allow me to publish to a v3 jUDDI registry. See my related questions here and here.
I realize after reading comments on those questions, and some articles on the internet (like this one) that UDDI is failing or dead, however my organization has some legacy tech we need to work with.
Also, my supervisor (I'm an intern) is adamant about sticking to standards. In principle, I agree with this, but perhaps a dead standard really isn't a much of a standard if nobody uses it.
In short, I need to provide the registry component of Service Oriented Architecture. It probably needs to be UDDI, so that it fits with the legacy tech, and satisfies the standard. Whatever the solution, it would be best if there were tools available that allow me to publish web services to that registry.
This problem has dragged on much longer than I would have liked. Any small piece of advice is really appreciated.
You may use WS-Discovery. WS-Discovery is a standard protocol for discovering services and service endpoints. This enables service clients to search for services based on a given criteria and bind with the discovered services. There are tow modes of WS-Discovery,
ad-hoc - servers advertise the services they have using a UDP multicast protocol
managed mode - servers and clients use an intermediary known as the discovery proxy for all service discovery purposes.
You can simply try this out with WSO2 Platform (free and open source under apache2 license). Please follow [1] to see a simple scenario of WS-Discovery in managed mode.
[1] http://charithaka.blogspot.com/2010/04/ws-discovery-with-wso2-carbon.html
Related
I'm looking at building a new service discovery platform to allow our customers to provide plugins to our platform. I know that UDDI was the technology "du jour" a while ago, however, in doing some research it appears that UUDI is falling out of favour with people. What are you using for service discovery these days? What would you like to use given the chance?
These days API Gateways are becoming popular choice for Sharing API & related documents along with. As far service discovery is concerned specific vendors have their own implementation as well such as Oracle API Catalog.
I want to find many functionality similar services, and when one service failed, I could switched to the other.
Is there a repository where I could find Web services, using functionality e.g., weather forecasting?
(I heard that UDDI seems to be deprecated, but I cannot confirm for that)
#Bogdan - The Apache jUDDI project actually put up two instances:
one for demo, for which there is no guarantee your data will stay around, but it's nice to play around with it. Find the link for it at the landing page of the prod instance (it only allows me to post two links)
one for (semi) demo production purposes for which you can request a user account, and data is guaranteed to stay around. You can find it at: https://www.webserviceregistry.com. If you want the certificate to match the address then use: https://uddi-jbossoverlord.rhcloud.com, which is a less catchy address to the same instance.
Cheers,
--Kurt
There was only one notable public UDDI registry (put in place by IBM, Microsoft and SAP) but that has long been discontinued. If you are to find a public registry it will probably be something set up just for demonstrative purposes (e.g. jUDDI demo).
#JohnSaunders is right, nobody uses UDDI in the wild. Public repositories are not practical while the private ones are most of the time unnecessary, providing for a complex solution to a simple problem.
You should find (and evaluate) a few stable web services and have their endpoints in a configuration file of some sort. Call one of the services and on failure go for the others you have configured.
If on the other hand you insist on going the UDDI route, then create your own private repository and use that because you won't find a public one (others - me included - have tried and got out empty handed).
To directly answer your question, yes UDDI does support this kind of query. Basically, you'd want to use a "Inquiry API" method "Find_service", passing in a CategoryBag/keyReference that matches a known pattern for weather services with some wildcards to help you get results. In addition, you'll need a find_qualifier for approximateMatch to enable the wildcards. Part of the issue is that UDDI allows registrants to use the spec in many different ways and thus this example assumes that there is in fact a standardized way to register and tag a service as providing weather information. It's up to the governance process of the organization hosting the uddi node.
"#JohnSaunders is right, nobody uses UDDI in the wild" - talk about a blanket statement. Perhaps you both meant "few people", but to say "nobody" without being able to prove it is silly.
"(I heard that UDDI seems to be deprecated, but I cannot confirm for that)". Widely used? probably not. Deprecated? Apache, Microsoft, IBM, HP, Oracle, and WS02 still sell or give away implementations of UDDI so I wouldn't exactly call it deprecated.
Do any of the major open source ESBs such as Mule or ServiceMix properly support web service transaction specifications (like http://en.wikipedia.org/wiki/WS-Atomic_Transaction)?
I've just briefly looked but it seems like support is not very good.
I would like to use the ESB to build macro services by composing from modular smaller services. I think this would be a pretty typical use of an ESB, and I don't see how you can implement anything practical if you don't have transactions.
WS Atomic Transaction is not in the list of supported WS-standards for Mule, so no luck here.
In term of design, the "transaction over SOAP" paradigm never really took off. Approaches likes stateful conversations with idempotent retries and compensations is usually what people prefer when integrating services over HTTP. It sure is more work than simply flipping the "transaction" switch on.
The project I'm currently involved requires that business logic must be implemented in Web Service that will be consumed by the Presentation Tier Components (i.e. Web Applications).
The company has an Enterprise Service Bus, and up-to-date almost every Web Service developed is exposed through this bus. I asked some colleagues around about when to expose Service through ESB and I got this answers:
If there's an ESB, expose everything through it: There are several benefits like Load-Balancing and location transparency
If the ESB will only act as a Proxy -i.e no message transformation- just don't use it: You'll overload the ESB and lose performance. You'll better do a point-to-point connection.
You should expose a component through ESB if there's a protocol transformation (like exposing a Stored Procedure as a SOAP Service). If this isn't present you better go Point-to-Point.
So I'm curious if there's a general agreement or best-practice of when to expose a Web Service through it or not. Any reading/reference would be a great help.
From my point of view and after 4 years of experience with SOA technologies, using an ESB will always overload the system since you are adding a new layer and making all your communications go through it. Transformation (either messaging or protocol) and routing aren't to hard to accomplish without an ESB and point to point communication will have a bit higher throughput. Same happens also with business process automation, there are ways to get there without the need of an ESB.
In the other hand, the use of an ESB has several benefits in the scope of a corporation but it must be within a vision and strategy. One of the best examples is a company that has been working for a long time with a wide range of tools, each of them for a specific purpose and that made the company be distributed in teams which work in silos, ones isolated from the others. After a long time that makes interaction between teams complex and slow. A well planned SOA strategy will help to integrate all those tools and start replacing them for more meaningful lightweight items.
So, IMHO, Using an ESB just to solve a couple of "issues" in a single project without a corporate strategy isn't a good idea and, eventually, the word SOA will be banned in your company, when the problem isn't SOA by itself by rather the lack of vision and corporate strategy.
The only rule of thumb that I found regarding the use of ESBs is: The requirement of transformation, routing, business process automation (with or without human interaction), etc. in a single project is not a symptom of going SOA (almost every project has to perform transformations, routing and business process automation), but when those needs are the ones for a whole corporation then it's worth to think about it from a business point of view, never a technical one. If there isn't a business perspective, then SOA will fail.
This is a really wide topic and discussion can last for ages, I will suggest you a couple of links for further reading:
Some SOA Case Studies
Top 10 Reasons why SOA fails
At my day job we have load balanced web servers which talk to load balanced app servers via web services (and lately WCF). At any given time, we have 4-6 different teams that have the ability to add new web sites or services or consume existing services. We probably have about 20-30 different web applications and corresponding services.
Unfortunately, given that we have no centralized control over this due to competing priorities, org structures, project timelines, financial buckets, etc., it is quite a mess. We have a variety of services that are reused, but a bunch that are specific to a front-end.
Ideally we would have better control over this situation, and we are trying to get control over it, but that is taking a while. One thing we would like to do is find out more about what all of the inter-relationships between web sites and the app servers.
I have used Reflector to find dependencies among assemblies, but would like to be able to see the traffic patterns between services.
What are the options for trying to map out web service relationships? For the most part, we are mainly talking about internal services (web to app, app to app, batch to app, etc.). Off the top of my head, I can think of two ways to approach it:
Analyze assemblies for any web references. The drawback here is that not everything is a web reference and I'm not sure how WCF connections are listed. However, this would at least be a start for finding 80% of the connections. Does anyone know of any tools that can do that analysis? Like I said, I've used Reflector for assembly references but can't find anything for web references.
Possibly tap into IIS and passively monitor the traffic coming in and out and somehow figure out what is being called and where from. We are looking at enterprise tools that could help but it would be a while before they are implemented (and cost a lot). But is there anything out there that could help out quickly and cheaply? One tool in particular (AmberPoint) can tap into IIS on the servers and monitor inbound and outbound traffic, adds a little special sauce and begin to build a map of the traffic. Very nice, but costs a bundle.
I know, I know, how the heck did you get into this mess in the first place? Beats me, just trying to help us get control of it and get out of it.
Thanks,
Matt
The easiest way is to look through the logs, but if that doesn't include the referrer than you may also want to monitor what is going out from your web to the app server. You can use tools like Wireshark or Microsoft Network Monitor to see this traffic.
The other "solution" and I use this loosely is to bind a specific web server to app server and then run through a bundle and see what it is hitting on the app server. You could probably do this in a test environment to lesson the effects on the users of the site.
You need a service registry (UDDI??)... If you had a means to catalog these services and their consumers, it would make this job of dependency discovery a lot easier. That is not an easy solution, though. It takes time and documentation to get a catalog in place.
I think the quickest solution would be to query your IIS logs and find source URLs which originate from your own servers. You would at least be able to track down which servers your consumers are coming from.
Also, if you already have some kind of authentication mechanism in place, you could trace who is using a particular service based on login.
You are right about AmberPoint. There are other tools that catalog the service traffic and provide reports showing what is happening to your services. Systinet, SOA Software and Actional also has a products similar to Amberpoint but Amberpoint has a free-ware version, I believe.