Sunday, January 10, 2010

SOAP, REST, and ECF remote services

In addition to supporting the OSGi 4.2 remote services specification, we on the ECF team have also been working on support for accessing REST-style services, as well as those that use the Simple Object Access Protocol (SOAP).

The ability to support all these styles of service-oriented architecture is fundamentally enabled by ECF's provider architecture, but since mentioned that in a recent posting, in this post I'm going to touch on something useful that's enabled by this provider architecture.

Most remote services (whether web services, OSGi remote services, REST-based services, etc) have two basic roles

  1. The service host...aka the 'server'

  2. The service consumer...aka the 'client'


Typically, the service host is first 'registered'...to make it available for remote access, and after that the service consumer then accesses/uses the remote service (e.g. makes remote method calls on a proxy, issues http requests for resources, sends/receives messages, or has some other way of actually accessing/calling the remote service).

Note that the service host need not be exposed by a 'server' (although it frequently is)...in some systems clients can register/expose services as well as servers. And it's probably obvious that service consumers don't have to be 'clients' either...i.e. they can be servers that are communicating with other servers. This is why I use the role names 'host' and 'consumer' rather than 'server' and 'client' when referring to remote services.

OSGi remote services use the OSGi service registry...for both the host's registration of services, and the consumer's lookup and access to a remote service. Whatever the transport used to implement the distribution, typically both the host's registration and the consumer's lookup are done via the OSGi service registry. This typical use case implies, however, that both the host framework and the consumer framework have access to the OSGi service registry (since both registration and lookup are via the service registry).

But what if you would like to consume a service that doesn't use OSGi (and therefore doesn't have a service registry)? With ECF's remote services API, along with our recently added REST and SOAP support, we've enabled this use case (non-OSGi service host) while still providing the benefits of using OSGi remote services for the consumer.

How, you say? First of all, ECF's transport independent architecture allows clients to talk whatever protocol they require to communicate with a remote process...so, for example, the XMPP provider is able to communicate with any remote system that uses the (standardized) XMPP protocol. This does *not* have to be an OSGi-based system.

Second, ECF now has a very small, remote service client API...specifically to allow consumers to interact with non-OSGi services, while still using the OSGi service registry (if they wish) on the client. Since both the ECF remote services API, as well as this new remote service client API are also transport independent, and have both explicit support for REST-style and SOAP-based transports, providers for specific REST-based protocols and/or SOAP-based protocols are easy to create.

As an example, I recently created a SOAP/Web services client (for an existing web service), using Apache Axis (to convert wsdl to java), the WTP tooling (for automating the generation of the java code from wsdl), and this new remote services client API. To the non-OSGi service host, this client looks/behaves like all other clients. The same idea...for an existing REST-based API (Twitter in this case), is shown by this demo.

Unlike other clients, however, these clients can use OSGi to maximum value: i.e. to structure the client in a modular way, to handle the dynamic requirements of a remote/networked/unreliable service, or even (re) expose the proxy as a another remote service...that other consumers can access. This can be used for building load balancing of web services, or to aggregate sets of services...as well as other purposes.

Note there is no additional tooling required to build such a client...since your favorite tools for creating the SOAP-based and/or REST-based clients may be used, alongside APIs and tooling for interacting with the OSGi service registry...e.g. Eclipse PDE, OSGi declarative services and/or others.

6 Comments:

Blogger Pavel Samolisov said...

Hello, Scott

Does ECF support SOAP protocol? What provider does it? Thanks.

6:27 AM, January 12, 2010  
Blogger Scott Lewis said...

@Pavel: I've recently added a new API bundle org.eclipse.ecf.remoteservices.soap. This adds just a few utility/implementation classes for creating SOAP-based providers. There is not a single SOAP provider, because SOAP (like REST) isn't a protocol, but rather it's an rpc style (and serialization format). In order to create a SOAP provider example, I've been using Axis 1.4 (to create java code to implement the wsdl-specified protocol...using wsdl2java). The idea here is to make it as easy as possible to create specific SOAP providers...by using/extending o.e.e.remoteservices and remoteservices.soap classes.

Given some time and assistance, I'll be creating a simple SOAP provider example...to show how to create such a provider...given wsdl, axis/wsdl2java, and the new ECF remoteservices classes.

7:52 AM, January 12, 2010  
Anonymous Anonymous said...

Genial dispatch and this post helped me alot in my college assignement. Thanks you on your information.

8:32 AM, January 31, 2010  
Anonymous Anonymous said...

What a great resource!

5:16 PM, February 28, 2010  
Blogger Pavel Samolisov said...

May be this stuff can be interesting for you. I wrote small example of using Aeroflot (the greatest russian air carrier) SOAP web-services. My example gets information about airports and arrival table. I blogged about it on Russian: http://samolisov.blogspot.com/2010/04/ecf-soap.html You can use GoogleTranslate for translate it on English: http://translate.google.com/translate?js=y&prev=_t&hl=ru&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fsamolisov.blogspot.com%2F2010%2F04%2Fecf-soap.html&sl=ru&tl=en&swap=1

Sorry, GoogleTranslate spoil code formatting.

1:08 AM, May 19, 2010  
Anonymous Anonymous said...

I think you'll want to put a twitter button to your website. Just bookmarked this article, although I had to do it by hand. Just my 2 cents.

5:39 PM, March 30, 2011  

Post a Comment

<< Home