Brian O'Neill's Blog

Community: Java Communications Archives

Communications Binding Components get upgrades

Before JavaOne, two projects kicked-off, XMPP BC and SIP BC . The projects released JBI binding components for both XMPP and SIP providing instant messaging and presence capabilities for those protocols. Recently, both were upgraded.

The XMPP binding component now supports groups. An application developer can quickly orchestrate participation in a Jabber group chat. The BC provides all of the functions necessary to fully participate including:

• sending messages to the group chat
• joining the group chat
• leaving the group chat
• inviting others to the group chat
• kicking people out of the group chat

Also, the XMPP BC now supports complex message types, which means the interface can now handle structured payloads, and a developer can map those entities in a BPEL process.

Additionally, the SIP BC is now easier to use and more capable. It adds session capabilities (e.g. VoIP) to any application and now allows application developers to setup multiple sessions simultaneously.

Please kick the tires! Chad Gallemore has an easy to follow tutorial that can get you up and running in no time.

JBI on your cell phone?

Despite the fact that many early JBI implementations are reusing enterprise infrastructure for their implementations (e.g. JMS messaging backbones and J2EE containers), my prediction is that JBI will start invading the mobile market.

Already, people are looking to leverage JBI implementations on small footprint platforms as a means of realizing the benefits of an "enterprise" service bus, but without the overhead of the "enterprise". In this capacity, JBI is a great means of achieving service re-use , while maintaining loosely coupled composition.

For example, JBI may be the best means to inject security into a mobile application. Since JBI focuses on data flow, , a developer can just "drop in" security components, rewire the messages to first pass through an authentication and authorization engines. Without changing the app at all, it would be capable of invoking services that require digital signatures. I go through this use case here.

It is a common misconception that OpenESB is wed to NetBeans and Glassfish. This isn't the case at all. In fact, you can follow these instructions to get OpenESB up and running in a J2SE environment, with XMPP capabilities and RSS feeds!

Lots of fun. =)

JBI as a Convergent Communication Platform

I have a hard enough time keeping my mind straight as it is, maintaining multiple internet persona's only makes my life more difficult: a skype account, IRC, AOL, XMPP, Yahoo, email, PSTN, mobile, etc. Some clients have been doing a better job of bridging the networks from a user perspective, but this does nothing for capabilities development on the server side -- and the disparity between the networks still causes user headache.

For example, even using one of the multi-protocol chat clients, to coordinate a chat-room I need to get everyone to agree on a common protocol, everyone needs accounts, and everyone needs to be on the same "type of network". (ie. firewalls need to permit traffic to the agreed upon network)

Why?

Because there isn't a server out there capable of maintaining presence, and location information across the multiple protocols. Sure, there are lots of gateways being built (e.g. XMPP -> SIP and back), but this results in the need for nxn gateways. Any architect will tell you that you need a common normalized schema to reduce the number of necessary conversions. Then you only need to develop n gateways, each converting from the protocol specific format into the normalized message format.

Hmmmm, interesting - this sounds awfully familiar. Enter JBI.

The devil is in the details, but if we ignore them for a moment, this is exactly the concept behind binding components (BCs) and the normalized message router (NMR). Over the past six month, we've developed binding components for XMPP , SIP , UDDI , and RSS . The purpose of each of these is to convert between normalized messages and their protocol specific equivalents.

Since the BCs expose those disparate communications networks over a single "bus", this appears to be the perfect environment for convergent applications development. Thus, you could implement a single presence service, a single locations repository, etc. Finally, I'll be able to join a chat-room over SIP, while friends join over XMPP, with the entire conversation broadcast over RSS.

Now, back to the devilish details. In a previous life, I spent long hours working on SIP (registrar, presence and proxy) servers. More specifically a commercial derivative of the NIST JAIN-SIP-Presence-Proxy server. Recently we've formed a new project, Marlin to attempt the very idea described in this blog, implementing the same capabilities as the JAIN-SIP-Presence-Proxy project, but independent of the protocol.

We're putting use cases together here , and meeting to determine how all of this relates to Sailfin .

Its an exciting time to be in communications infrastructure. =)

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.