UDDI was proposed as a solution to publish and search services. UDDI defines data structures relevant to service discovery and a set of APIs to access them. The standard was supported by major software vendors such as IBM, Microsoft and SAP. Although UDDI was claimed to become successful in restricted and controlled environments (there are several implementations of UDDI servers available for the internal use these days), it has not prevailed in the domain of publicly available Web Services (you can read more about shutdown of IBM, Microsoft and SAP public UDDI registries and many articles discussing this topic as old as 2004, just to mention some of them for reference from pluralsight, techtarget or realworldsoa at inforworld).
We are frequently asked by users of seekda Web Services search engine if seekda develops or aims to develop a public UDDI registry. To be more specific what people really mean are UDDI APIs allowing to access seekda in a programmatic way. The short answer is that we are neither doing nor planning to do so in a short term. However at the same time we believe that we can learn a lot from the work done by UDDI designers and creators of public UDDI registries. We do not completely neglect the future possibility of implementing the standardized UDDI APIs (or ebXML registry APIs). Anyway at this stage we do not consider UDDI APIs as a very essential feature which would improve search for public Web Services and the exponential growth of Web of services.
Continue reading “The Fairytale of UDDI Registry and Public Web Services” »
When I am reading about mashups, I am getting often an impression that REST folks are trying to take over this term and restrict it mainly to REST based services. Equally at the same time in the Web Services community we got used to hear about Web Services composition, but not really about Web Services mashups (although there are of course exceptions). While both terms are not really equivalent, there are some overlaps and basically there is nothing preventing us from using Web Services to provide appealing mashups for Web applications. At seekda we strongly support the idea that Web APIs should be based not on one, but on different technologies. We can successfully mashup Web Services and REST services together to compose good Web applications so in our opinion the discussion about superiority of one technology over the other is quite pointless. The user is important and a new functionality we can provide to him or her; not really the technology or terminology, which have been used by particular communities. In this new series of tutorials, which I will call “Services by Example”, I will be mashing up (composing) various Web APIs to show how in a couple of simple steps to deliver mashups, which could not be produced, when using standard software libraries. Today I will show how to make a useful application composed of Web Services coming from two different service providers.
Continue reading “Services by Example: Web Services Composition” »
At seekda our developers never sleep… That statement is maybe an exaggeration 
, but the truth is that while lots of seekda development effort is currently committed to development of Web Services marketplace (read about seekda innovation in our about section), we continue to enhance the existing Web Services search engine portal with many new and useful features.
With our recent deployment, the history of viewed Web Services is now available to you from the context menu. It remains invisible until you browse for the first time the page of a particular Web Services. Once you find your first Web Service, the history box gets activated in the left context menu.
Continue reading “Recently Viewed Web Services” »
