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.

8 comments:

Unknown said...

Hello, Scott

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

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.

Anonymous said...

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

Anonymous said...

What a great resource!

Unknown 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.

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.

Huynh Ngoc Tho said...

I have a question relating to use SOAP or REST on DOSGi, Both use TCP to communicate. We can configure it for UDP ?

Scott Lewis said...

Huynh Ngoc Tho said:

>I have a question relating to use SOAP or REST on DOSGi, Both use TCP to communicate. We can configure it for UDP ?

Hi Huynh Ngoc Tho. The answer to your question is yes. OSGi Remote Services specification...that's the name for what used to be called 'Distributed OSGi aka DOSGi' in the enterprise specification, found here:

https://osgi.org/download/r5/osgi.enterprise-5.0.0.pdf

allows for multiple 'distribution providers'. A distribution provider can implement the specification over whatever transport is desired. ECF's implementation of the spec already has multiple distribution providers, which support a variety of transports. See here for some examples:

https://wiki.eclipse.org/ECF#Customization_of_ECF_Remote_Services_.28new_Discovery_and.2For_Distribution_providers.29

and here for an architecture diagram

https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF

Unfortunately, I don't think there is currently a UDP-only distribution provider although given that the underlying APIs and all the existing distribution provider implementations are in open source, it would be possible to extend an existing provider or even implement one from scratch yourself fairly easily.

Using UDP alone, however (i.e. without tcp reliability and ordering guarantees) presents some fairly difficult technical challenges..since particularly ordering guarantees (and associated reliability) are typically required. That's why most/many of the existing distribution providers generally use TCP.

But the answer to your question is 'yes'...multiple distribution providers can/do exist, and ECF's implementation supports the use of whatever transports are desired. As an example of this, I recently personally extended one of the existing providers to use the new websockets specification (asynchronous messaging based upon http/https). If you are curious about this work, please see

https://github.com/ECF

and join the ecf-dev mailing list:

https://dev.eclipse.org/mailman/listinfo/ecf-dev

I and the other ECF committers frequently communicate via that list.

Thanks, Scott