Philly Emerging Technologies Event: Call for Papers

I'm Philly born and bred. And aside from cheesesteaks and soft pretzels, the Emerging Technologies Event (ETE) is one of the best things associated with the city of brotherly love. Chariot Solutions organizes this event annually and this year looks to be better than ever.

ETE looks to have a block buster lineup covering the latest lightweight/agile development frameworks, web 2.0 concepts, java and ruby/rails. ETE has both business and technical tracks. So, there is something for everyone. If you would like to be part of this event, the call for papers just went out.

Come hang out and while your here grab a cheesesteak and soft pretzel. ;)

ESBs: the value of indoor plumbing, public water and sewer

I just saw Joe McKendrick's entry on the value of an ESB. Although I appreciate his comments, and even agree with some of his points, I don't come to the same conclusions.

There are two things that drive common understanding: shared experiences, and common problems. The wide acceptance of ESBs is driven by common experiences trying to implement SOA on a large scale with disparate organizations involved.

Without an ESB, the product of such situations is often a fragile, tightly coupled, tangled web of services that is nearly impossible to change, or even reason about -- this causes a lot of pain that motivates people to consider alternative approaches. (This is often the architectural equivalent of burning your hand on the stove -- something you don't do twice =)

Now, this is not to say that ESBs for the sake of ESBs is a good idea. Often, organizational boundaries can be used as a good litmus test when deciding whether or not to use an ESB, but consider "organizational boundaries" in the more broad sense of the term. This is more than just the end-consumers/producers involved (e.g. trading partners). It takes into account the vendors supplying and integrating the functional components (infrastructure) of the system. For example, if you're authentication & authorization components are coming from a different vendor than your service stack; you have an organizational boundary you probably want to consider.

Thus, if your scope is small enough, and you are getting all of your infrastructure from the same vendor (and plan to continue to do so), ESBs may not be worth it.

Joe was actually just reacting to an article by Bobby Woolf, which has some good insights in it...
"The problem is this: An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do."

I completely agree with Bobby's statement and just (IMHO) believe Joe made an incorrect inference.

Faucets and toilets deliver the value, but the pipes are not to be overlooked. Lets all face it, if it wasn't for plumbing we'd all still be sh*tting in outhouses. There *is* value in being able to connect a Moen faucet to any well pump, and being able to inject a UV-filter and water softener into the line without disturbing either the faucet or the pump; plumbing enables that. If we take another step back, there is value in being able to then hook into a public sewer system eliminating the need for everyone to install their own septic system.

A real world example of this can be found in Chad's SIP to XMPP tutorial. He was able to build that capability without coding because he used a JBI-based ESB approach. In this example, the two networks (SIP & XMPP) had "plumbing interfaces", and BPEL could be used as the manifold to connect them. Consider that Chad could have quickly and easily also added security "in-line" as well that ask the question "Is Alice authorized to talk to Bob?". These kinds of things are difficult to do without a standards-based, orchestratable messaging and transformation infrastructure (i.e. an ESB).

So, although plumbing might not be worth it for everyone, I for one don't like having to walk outside to relieve myself -- especially in the dead of winter. =)

An Open Technology Manifesto

Many people have read Stevey's post. where he contrasts agile with Agile. Stevey does a great job of separating out the important "agile" value system from the methodologies and processes of "Agile" that were created to help the masses implement it.

Because in fact, it is in the implementation of agile that the values sometimes get lost. Ive' seen Agile often bundled with Extreme Programming tactics (Test-Driven Development, Paired Programming, etc.). which muddied the waters and resulted in teams claiming "agility" simply because they have junit tests. When people focus on processes, tools and methodologies too much, they can't see the forest for the trees.

Likewise, I believe we need a similar separation between values and implementation in "open development". In the details of the implementation, there are decisions about licensing (GPL or Apache?), and community (Java.Net or Sourceforge?). These can be argued just like people argue over the details of Scrum vs. Lean Devlopment vs. RUP. But in the end, "open development" manifests itself more so within the attitudes of the team members, than in the implementation decisions -- just like "agile".

Thus, humbly, I'd like to propose just such a manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Open discussion over closed "white-paper" analysis.
• Collaborative contributions to existing efforts over proprietary (re)invention.
• Open sharing of experiences over knowledge hording.

These combine with an overarching desire to commoditize the lower-level functions of the software stack, allowing all software development (and service-delivery) to focus on ever harder more valuable problems.

Enlightened developers often embrace the above values without knowing it, just like many of the same are inherently agile (in the "move fast and react fast sense of the term"). Others operate with a very closed mentality, despite the fact that sometimes they've "open sourced" their code.

For example, we often see "white-paper" analysis performed by the evil genius architects that lock themselves in a room with their crystal ball, carefully considering all options, finally emerging with an architecture that accounts for all the requirements, *and* all of the unforeseen changes to come (notice the paradox). Meanwhile, the enlightened developer has spent the same time discussing the options on a mailing list, effectively forcing some of the "unforeseen" changes forward in time by soliciting input from others and adopting suggestions (even if they don't directly address existing requirements).

Likewise, once an enlightened developer accomplishes a feat, he/she will blog about it to advance the productivity of the community at large, whilst the less enlightened will add this to their little secret bag of tricks enhancing their "job security". (the same developer goes on to prove black is white and gets himself killed in a crosswalk)

I was in diapers when the pioneers were doing the real work on open source. So I feel presumptuous even suggesting such a manifesto and I certainly don't intend to even hint that these are novel thoughts. I'm sure the likes of Eric Raymond and others have been espousing such values for years. My only point (if any) is that the Agile Manifesto did a great job of distilling agile into four statements that could be internalized by all. Open Development might be served well to do the same, separating it away from the "noisy" licensing debates discussing freedoms, and capitalism.

FWIW.

JBI: Catch the second wave...

If people remember back to the early days of Java EE (J2EE), there was a lot of promise, but a lot of frustration. I still have mental scars (and a slight eye twinge) from the countless hours tracking down typos in deployment descriptors. But, we were willing to endure the pain because there was a lot of power in the platform.

And as a model, J2EE was solid. Sure, there were squabbles over the value of different parts of the model (e.g. Entity Beans), but the general abstractions and approach were incredibly valuable, as evidenced by its success. JBI is similarly positioned.

However, mainstream adoption requires not just a solid design model . Mainstream demands ease of use, immediate gratification, and passionate community support. This is the fundamental appeal of Ruby/Rails and why J2EE struggled in the beginning. In the beginning of J2EE, it was a week long effort to get an EJB deployed. Meanwhile, Rails has caught on like wild fire because it takes less than 10 minutes to get an entire n-tier application up and running.

In an effort to learn from this, independent of the actual implementation communities (Apache - ServiceMix, Java.Net - OpenESB, etc.), we've created a JBI community site jBIZint, where the various implementation communities can come together to discuss common needs that will improve a user's over all experience. If this sounds like something you would like to be involved in, please join the mailing lists.

As an example, there are two movements afoot that will improve JBI adoption and ease of use. The first is a movement to standardize the diagramming technique for service assemblies, and the communication between them. Much like SCA has done, a standard diagramming technique will allow system designers to communicate effectively, the components, meta-data and communication paths of the services in the system. (Again, please join the discussion on the mailing lists to get more info)

The second movement is to get an "easy-install" package management system in place akin to Debian's apt-get and maven's repositories. (credit Bruce Snyder for the idea). This would make it simple to install components through tooling (e.g. Eclipse, NetBeans, or command-line). The package management system would pull down the component and all of its dependencies (e.g. shared libraries), perhaps even a sample service unit.

Combining standardized diagramming with an easy-to-use package management system should make it even easier to pick up one of the numerous "10-minute" tutorials on JBI, like Chad's XMPP-RSS Demo, and get it up and running in 2 minutes with an understanding of how and what you did. =)

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.

SCA & JBI: Made for each other. (SOA Gone Wild)

I agree with Shaun Connolly's
observation that "While they [JBI and SCI] may share some similar patterns, those who pit SCA vs. JBI only demonstrate their inability to distinguish between the two perspectives".

In fact, we set out to prove the assertion that:
- JBI and SCA are entirely complementary.

And we've made quite a bit of progress by taking an example SCA composite application / contribution and figuring out how it translates into a JBI runtime environment. But translation is only one example of how JBI & SCA may fit together.

There are actually three different relationships that make sense. First, SCA run-times that already exist (e.g. Tuscany) could be deployed as containers within JBI by packaging them as Service Engines. JBI would leverage the SCA Service Engine as a means of integrating SCA contributions into a JBI runtime. In this respect, JBI provides an integration backbone that would improve the utility of SCA contributions by making them available to networks, capabilities and systems for which there is no SCA component implementation. (e.g. SIP and XMPP) Essentially, this would attach an SCA contribution to an bus architecture, with all of the benefits that comes with that.

Secondly, I don't see any reason why there wouldn't be a JBI Component Implementation added to SCA's list of implementations. This would allow an SCA contribution to declare a JBI service unit (or service assembly) as a component implementation within an SCA contribution.

Lastly and most interesting, JBI can be the run-time for SCA contributions. In this capacity, a translation layer would translate an SCA contribution into a set of service units deployed to binding components and service engines. In this example, each binding in the SCA composite application the would result in a service unit bound to a binding component. Likewise, for each service implementation in the SCA composite application, a service unit would be deployed to a service engine. (e.g. bpel, pojo, etc.)

The translation is a tremendously powerful construct. It lets JBI deliver all of the bus-like features, life-cycle management, and administrative controls, while allowing architects to define their composite applications in SCA.

We are working all of this through on jBIZint . If all goes well, we hope to deliver a Grand Unified Platform by the end of the year that when combined with Eclipse and/or NetBeans will directly interpret developers brainwaves into SOA. =)

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. =)

SOA, ESB, JBI & SCA: A caveman's perspective

Software development techniques and processes are changing at ever faster rates as open collaboration development spreads globally (thanks to the adoption and promotion of open source software). As the systems we architect and implement become increasingly complex, the mechanisms, infrastructure and patterns with which we build the complex systems constantly improve to keep the problems tractable.

The Java Business Integration (JBI) specification and Service Component Architecture (SCA) are the latest additions to our tool set.

Now, I'm a simple man, a caveman really. And for the last three years, I've been working to construct a multi-channel service oriented architecture for the federal government, with pluggable enterprise services (pub/sub, security/encryption, messaging, VoIP, etc.)

As you can imagine, this is a hard problem for a caveman to solve, especially when you layer in a complicated political landscape filled with software infrastructure vendors, and their professional services divisions. We needed an industry standard on which to hang our hat.

Now, most people would hang their hats on "Web Services". Those same people would probably define web services as WSDL + SOAP + HTTP + (UDDI). They would then proceed to convert all RMI, RPC, and potentially database communication into web services: then call that a SOA. Unfortunately, that only results in a rat's nest of invocations and derived dependencies that can bring down an entire enterprise. (we have the battle scars to prove it)

So, we evolved.

We realized that we needed a common communications backbone to unravel the mess. Enter Enterprise Service Bus (ESB) concepts, but again we were disappointed. We looked around for one of these new fangled ESBs, but all we found were re-applied messaging systems that required proprietary extensions to achieve a services layer. (and we knew enough to stay away from those, and the vendor lock-in that came with them)

SO, we looked long and hard at the writing on the (cave) wall; and found a promising acronym: JBI. We set about downloading JBI implementations. Immediately, we were hooked. JBI provided a standard interface through which we could deliver our enterprise service "lollipops". Literally, we could drop our lollipops into existing JBI containers, rewire the connections and provide service consumers and producers with security, compression, discovery and other capabilities. Wow, nirvana.

In fact, as cavemen - we were more productive than ever. We could develop applications without writing a single line of code. Applications development became a matter of drawing pretty pictures. Using a palette of components, and drawing lines between them, in minutes we could create new convergent capabilities - e.g. take messages from XMPP, and post them to RSS feeds.

But alas, nothing gold can stay. The political landscape shifted, and SCA came down from the heavens like a meteor crashing into the earth. We ran for cover, trying to figure out how SCA fit into our new world view. What we had heard about SCA was promising, but we had trouble putting our fingers on it. SCA seemed like a great language with which to communicate with other cave people, a common way to describe what we were building, and compose larger services from smaller, recursively. This was much needed, and completely complimentary to our new found love - JBI. As cavemen, we couldn't see where SCA dictated a run-time, but we didn't need it to. We had JBI already.

Us cavemen proceeded forward with a new world understanding - determined to build a bridge demonstrating an SCA composite application, running in a JBI runtime.

You can follow along at jBIZint .

Better than Java.net?

I'm just wondering if blogspot is better than java.net. So, this is my test drive.
Ordinarily, I have a blog over on java.net, but I noticed some people had moved over here and wanted to see what all the hubbub was about.