How JBI can improve your love life. (JBI for Social Networking)

Our team just released four JBI Components, a SIP BC, an XMPP BC, an RSS BC, and a UDDI BC . Having developed those components, we're now reaping the rewards; we're able to combine these low-level collaboration "services" to produce new and cool collaboration capabilities. Essentially, the four components together create a collaboration platform. One use for just such a platform might be a social networking application. hmmmm...

Lets pretend I'm looking for love (in reality, i'm happily married, but we can pretend). I've joined an online singles dating site and I want to write a quick application that will let me find a date. Lets call this SaaS app the lovinator.

First, things first --- I don't want to have to continually go to the dating site to get the information. So, I quickly write a a python script to crawl the website looking for profiles of interest. Once the script finds a profile, it posts the profile to the lovinator.

Fortunately, the lovinator is built on a JBI platform. An HTTP BC receives the request, which contains a raw XML document that has the profile. That XML is routed to the RSS BC via a simple BPEL process. On my desktop, I'm subscribed to the lovinator feed, and am able to view new profiles.

I see a particular profile that is interesting. Now, I want to be able to see when he/she comes online. And since I'm so hip (a.k.a geekish), I have an iPhone with a jabber client installed. Lets assume the prospect's XMPP and SIP addresses are in their profile and I'm headed out of the office. Leveraging the XMPP BC, the lovinator can subscribe to the prospect's presence information and send me an update when he/she comes online; directly to my iphone. Nice.

OK, so now I can peruse prospectives from my desk via RSS, and stalk them from my iphone using XMPP. The only thing left to do is call them out of the blue. (believe me -- they love that) Fortunately, the lovinator can do that for me; automagically. Using the SIP BC to perform a bit of third-party call control (3PCC), the lovinator can setup a call between us. (saves me the time required to look at their number and dial the phone)

Now we're cooking, but where is the social networking aspect? Well, as I said -- prospects are disseminated over RSS. So, there is nothing to prevent others from subscribing to the same feeds. Additionally, it would be trivial to incorporate a Java EE service engine that would allow me (via a webapp) to submit feedback about prospectives.

Lets say that voice conversation didn't go so well. (e.g. I found out he/she has a dozen cats and lives with his/her mother at the age of 39... and I'm not feline fan) I could feed that information back into the prospect's profile feed via the webapp. That would get disseminated to all those subscribed, saving other people time and energy -- or making that "special someone's" day.

One can imagine a ton of extensions to the lovinator. For example once I do find that special someone, the lovinator could send me messages(via the XMPP BC) when their birthday rolls around. (anniversaries, etc)

A bit contrived? perhaps. But the point is that JBI creates a great, extensible, platform with new loosely coupled capabilities being added everyday that we can "wire in" easily.

So, the point is; we save time.

Estimated time to develop the lovinator? Only a few weeks. I just checked and the domain lovinator.com is available. Any takers? =)

For some more realistic use cases you can check out jBIZint where we're trying to outline the "tougher" use cases, that the spec may or may not accommodate.

JBI: Application Development w/o Coding, are we there yet?

Many people, including myself, approached JBI as a standards-based means of achieving ESB capabilities. That was the big value proposition. In the early stages of using it, we treated JBI like JMS on steroids. It wasn't until later in the game, we realized the full potential of JBI.

And, it really boils down to knowing the Fundamentals of JBI. For developers like myself that have a tad bit of an attention deficit disorder, it is easy to overlook the implications of those fundamentals. Specifically, the JBI specification had plans within plans, and containers within containers.

The JBI run-time acts as the first level container, consuming service assemblies for deployment. Those service assemblies contain service units which get deployed to service engines and binding components. So, JBI components themselves act as a second-level containers for the artifacts within service units.

This is often misconstrued by people that believe Service Engines *implement* the business logic in an application. This is not the case. Instead, business logic gets *deployed* to Service Engines as part of a service unit (within an assembly). Service Engines contain and execute the business logic, but they by themselves do not provide it. This is tremendously important because it allows JBI to deliver, "Application Development without coding".

Lets look at an example, the BPEL Service Engine lets me wire together services mapping the results of one service to the inputs of another. So, without any coding I can deploy a bpel process to the BPEL Service Engine. Furthermore, I can connect that process to specific transports, like XMPP and SIP by simply deploying service units to the XMPP BC and SIP BC respectively.

In this situation, the BPEL SE, XMPP BC and SIP BC are acting as containers for specific business logic and "instances" of capability that could have been defined graphically in an IDE like NetBeans.

Thus in our never ending quest to make our lives easier and leave the world of semi-colons, I believe JBI has brought us one step closer.