First of all, ruby code *is* documentation. The constructs, conventions and style used in ruby (e.g. the unless construct, and underscores in verbose method names) make the code more descriptive. The code is readable. Evidence of that is found in rdoc, which is ruby's JavaDoc equivalent. The actual code is embedded directly into the rdoc pages, as if it were part of the description.... because it is!

Ruby also attracts a different crowd (at least for now). Ruby developers enjoy riding at the forefront of the technology wave. This makes them more likely to have blogs. And they use those blogs to document code recipes, successes, etc. Those blogs get absorbed into the ethos, indexed by the engines, and reiterated by the rest of the blogosphere like a big echo chamber. Consequently, the blogosphere is the biggest ruby manual and how-to in existence.

Now, that suits some, but not everyone. Despite the readability of the code, and the mass of the "documentation" on the web, I completely understood what my friend was getting at. There are very few ruby "specifications" that you can download, read, and process in their entirety.

One could argue that the success of Java is in (a large?) part due to the success of the Java Community Process (JCP). You may dispute the quality of the APIs themselves, but the JSRs fill a real need. The specifications coming out of the JCP give individuals and enterprises a firm fixed interface on which to hang their hats.

To my knowledge, Ruby has no such organization. Without it, when developing a ruby application, you are left praying you stumbled upon the right blog post, at the right time, with the right solution.

The importance of community accepted interfaces becomes even more important when considering pluggability, and solution portability. Recently, I ran into the need for HTTP Digest authentication in Rails App. I found lots of proposed solutions, and a ton of authentication plugins, gems and modules, but none of them were swappable, and not one of them offered me a "standard" means of achieving digest authentication. In Java, I could have gone to the JCP, found a suitable interface, examined the vendors that passed the TCK tests, and gone about my business knowing (at least in part) that the interface I was about to use had some consensus and support behind it.

Alas, I love Ruby. I love Rails. They are a joy to program in. And for that reason, I'm entirely okay with the "faith factor" required in pulling down random solutions from blogs. Hell, if the solution doesn't work, it will be fun to fix it. And that is fine for the beer review site I put together, but that is (arguably =) not a mission critical application. I'm not sure businesses can assume the same risk.

I'm not foolish enough to believe the JCP is flawless (e.g. Entity Beans anyone?), but businesses can't always afford to bet the farm (or their investor's farms) on solutions not backed by real consensus organizations. I understand slow consensus processes run counter to everything Ruby on Rails stands for, but perhaps the Ruby Community Process can offer a more agile environment basing specifications on code and capability, not politics and vendor positioning. (which IMHO is the thorn in the side of the JCP)

just some more food for thought,
bone

I've spent the last six months developing in Ruby (some on Rails). It quickly went from just a past time, where I was developing a silly little beer review site called liquidMirth to serious business applications (at the day job: rVooz). And now I have to admit, the compile, build, deploy cycle of a standard J2EE application seems unbelievably daunting. Combine that with the cumbersome and seemingly never ending twiddling of meta-data and deployment descriptor files required by the libraries and frameworks (e.g. Spring & Hibernate) that are supposedly helping the problem and you have an incredibly unproductive environment for web application development.

I'd emphasize that this is unproductive for web applications, because web applications need to be especially responsive to user requirements. J2EE simply isn't agile enough. There is a fantastic video by someone out at NASA JPL that does a fantastic job comparing the latest web application development frameworks. He does a great job emphasizing this point.

Now, all that said, J2EE != Java and Java's present sweet spot is in SOA, and business process integration, where things need to be transactional, and message-oriented/event-driven. Web frameworks are having trouble in that area, where things don't fit into a nice request/response interaction. On the "back-end" you need a bit more rigor, and typically you need to integrate with systems that won't conform to convention.

So, IMHO -- let more flexible languages accommodate the fickle nature of users. Use Java, with specifications like JBI and SCA, to implement an ESB on the back-end to do the heavy business process lifting, systems integration, and B2B style interactions.

And if you do that, you'll quickly realize that you don't need much (if any) of the J2EE spec to get-r-done. Instead, OpenESB in J2SE, ServiceMix, or Mule fill the bill quite nicely.

just two cents, and here is another nickel's worth of similar sentiment.

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

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.

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

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.

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

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.

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.]]> 2007-06-27T19:59:37Z 2007-06-27T19:59:20Z tag:weblogs.java.net,2007:/blog/boneill42/104.7751 2007-06-27T19:59:20Z

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

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

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 .

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?]]>