Brian O'Neill's Blog

Distributed Archives

Web Services & SLEE -- Whats the best fit?

The word "web" in "web services" is misleading. Web services do not in any way shape or form depend on the "web". They are not tied to any specific protocol or means of invocation. Very generally, a web service is simply a service made available to other loosely coupled systems via an interface that is usually described using the web services description language (WSDL).

In WSDL, the actual means of invocation (binding and port) are implementation details. Their could be multiple bindings because the service supports multiple means of invocation, RMI, EJB and SOAP for example. One can envision a day when HTTP is not the primary protocol via which a service receives and responds to invocations. This lead me to thinking about SLEE.

SLEE is the perfect platform on which to build generic event-driven applicaitons that provide services to external entities. Via the resource adapters, the application achieves the necessary abstraction layer away from the underlying protocols. In a SLEE container, I can develop my service without tying it to any particular protocol or invocation method.

Beautiful, but how does one do this? The question that is open for debate (and to which I don't have an aswer) is how does one develop a traditional web service in a SLEE container? Is it possible? Is it suggested? Do I have to first develop it in J2EE then tack on a SLEE mechanism to expose it via other means? That seems like the wrong solution.

So, I would like to propose an HTTP adaptor for the SLEE container. For some reason, I've "heard" this is frowned upon. In my opinion, this is the cleanest way of building services in the future.

Call me silly but I want to develop my service in a Service Logic Execution Environment (without thinking about J2EE), and whether or not it gets invoked via HTTP requests or someone tapping out morse code, is only an implementation detail.

How does one make this happen?

A Communications Services Framework to fuel IP telephony deployment?

I've started the snowball rolling for a Communications Services Framework. (CSF)

IP telephony deployment has been slowed by some major hurdles, and we have yet to see the "enhanced services" that will really drive the market. I think a web services environment, hosted on Java.Net, through which enhanced communication capabilities could be delivered, combined with a client side API that allows developers to take advantage of these capabilities could solve the problems found in current IP telephony deployments and provide impetus for migration.

One of the first problems I'd like to tackle with the CSF is that of identity. Currently, there is no way to automagically discover a persons contact addresses given one of the set; SIP address, phone numbers, email address, AOL screenname, etc.

This causes many problems. If I am on a SIP phone, dialing a phone number, it will go out through a gateway to the publicly switched telephone network (PSTN). If the person I was dialing happened to be available via SIP as well, the phone call will still travel out to the PSTN, and back in through another gateway because there is no way to discover that the person I was trying to call is available via IP. There is no way to keep from traversing the PSTN. How inefficient? This needs to be remedied.

What if there were a web service, an Aggregate Directory Service (ADS), that given a users contact address, phone number for example, would return the set of contact addresses via which that user is available? It would solve the problem. A SIP Proxy Server could then utilize this web service to determine if it can keep the call on the IP network, before blindly passing it to the gateway. How beautiful? Lets build it.

Because this is not the only such service required by these next-generation communications networks, it makes sense to house the ADS in a larger more general framework. This is the Communications Services Framework.

Bingo. we have a plan. I just started working on the complete specification for the CSF and the Aggregate Directory Service. If you would ike to get involved PLEASE contact me.

This work is licensed under a Creative Commons License.