We are building a system that should integrate SOAP web services from different providers.
We want to allow providers to register web services.
It seems exactly the purpose of UDDI.
But according to its wikipedia article UDDI was never adopted widely and has fallen into disuse.
The question is: In favor of what? What is the current proper way of integrating a collection of web services registered by certain authorized providers?
If the answer is UDDI: Where can I find updated information on how to set up my own UDDI service?
I think that "disuse" is more of a 'disuse' publicly on the internet, meaning that there are few publicly available instances of UDDI. A number of large organizations use UDDI behind firewalls.
There are many other alternatives, ebXML, WSO2, WS-Discovery, mDNS, jGroups and more. It all depends on your use case, network topology and who you want to share information with.
For setting up your own UDDI server...
http://juddi.apache.org
We also have a cloud instance available for anyone to use (although it needs maintenance)
disclaimer: I am the PMC for jUDDI
Related
I know that UDDI gives the posibility of descovering a web service. Is there any alternative for UDDI that do the same thing : to discover web services?
UDDI is out of the scene these days. People are moving towards semantic web services. WSMO and OWL-s are major initiatives for semantic web services. These solutions can provide more precise results.
Here's a few
mDNS/Bonjour/Avahi - can be used to share endpoint information for a web service, or anything else using a TXT record
WS-Discovery - supported by CXF and WCF, shares implementation of a specific interface
ebXML - had a component similar to UDDI
I work as an intern Application Developer at a large organization prototyping SOA. I'm brand new to web services and technologies such as WSDL, SOAP, UDDI, and so on.
In the past week, I have been having a great deal of difficulty understanding UDDI, and how to use it effectively. The general consensus on the internet is that UDDI is dead, either too complex, unneeded, or a hindrance for most use cases. Some websites hint that UDDI is only useful as an internal registry within an organization and it's close business partners, rather than the universal business registry for which it was designed. You can see StackOverflow's attitude towards UDDI by reading some of the answers and comments on these questions:
Is the public UDDI movement dead or, was it ever alive?
How does SOA service discovery (UDDI) work in practice?
Does A Web Service Have To Be Registered?
Help understanding web services
What are some alternatives to UDDI? What are other ways that web services can be published so that developers can find a description and technical details without any of the complexity that UDDI seems to have? Is there any good business case for actually using a UDDI registry?
There are many open source registry/repository alternatives to UDDI.
I am an Architect at WSO2, so my answer could be biased - anyway WSO2 is not the only open source alternative.
The WSO2 Governance Registry is an open source, integrated SOA registry-repository, which supports you to efficiently manage your organization's growing SOA. The WSO2 Governance Registry provides an easy-to-use metadata repository complete with support for full versioning, lifecycle management, a rich model for users/roles/permissions, and social features such as tagging, rating and comments. You can easily add services and other resources through the web-based user interface.
WSO2 Governance Registry also has the WS-Discovery support.
WS-Discovery is a technical specification that defines a multicast discovery protocol to locate services on a local network.
You can read more from here.
Other types of look stuff up at a known location:
ebXML Registry
Options based on multicast networking
mDNS/Bonjour/Avahi/ZeroConf
WS-Discovery
UPnP
Could try using WebSphere Service Registry and Repository (WSRR) or similar product.
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.
I ask this question in anticipation as part of a project. I have experience of developing and consuming web services in the past and am au fait with those. However I have been told that as part of this next project I will need to use "secure" web services. Can you provide some insight into what additional development tasks there will be to implement these as opposed to standard dare i say it insecure web services?
Cheers
Unless you have a complex multi-hop scenario, then SSL is vastly more practical and interoperable than anything based on WS-Security or related specification
If your going to be using WCF, check out these guide lines on MSDN
Exising ASMX Web Service can be secured using Web Services Enhancements (WSE) 3.0