Edward Ort's Blog

June 2005 Archives

A Short Trip to Open Source Land

This morning I took a trip to open source land by attending back-to-back sessions on JBoss and Hibernate.

I always find it interesting to learn how people get exposed to their passions. In Bill Burke's case, his exposure to JBoss was pretty much driven by desperation. Burke, who was the speaker for the session "The JBoss Kernel: Plug and Play J2EE," was working for a startup the was in the process of going belly up. Money was drying up, and the company lost its license to the proprietary app server it was using. Someone in the comopany told Burke "I think there's some freeware/shareware out there called JBoss. Why don't you look at it?" Burke did and was soon hooked. He got even more entrenched into JBoss a bit later, when Marc Fleury, JBoss's CEO, asked him if he wanted to take the "red pill." (Those of you who've seen the Matrix movies know what taking the red pill means. For those who don't, let's say that it gives you a fresh and unobstructed view of reality.) Fast forward a bit, and now Burke is the Chief Architect for JBoss.

The reason most folks turn to JBoss in pretty much the same reason Burke turned to it. No, they're not all working for dying companies that are desperate, rather, they're all interested in an open source Java application server. The great thing about an open source app server is that you can extend it in ways that you need. One example of this is JBoss's use of interceptors to extend MBean services. (JBoss is built on top of the JMX architecture, and all JBoss services are MBeans.) Interceptors are a very flexible means of incorporating new behavior into applications deployed on the apps server. For example, Burke talked about a defense contractor that needed to use a proprietary security protocol in its applications on JBoss. Using interceptors on both the client and the server, the company was able to invoke the protocol when they needed.

MBeans also gives JBoss a way to expose metadata about services so that it's easy to write tools that access this metadata. Burke showed a console tool that did just that.

Dunno if I've quite got this right, but during Burke's talk, it did appear that JBoss can even extend annotations. For example, Burke showed an annotation that invokes EJB methods in a background thread. Burke then showed how a constraint can be put on the invocation such that only void methods will be run in the background (I think).

... and speaking of annotations, that leads me to the second session I attended. In this one, Gavin King, the founder of the Hibernate project spoke about some of the new things in Hibernate 3.0 (which has been available for a few months, and is now considered stable enough for production use). He also talked about some things planned for 3.1. Hibernate is open source object/relational mapping service for Java. Long separate from EJB, Hibernate and EJB forces are now coming together. In fact, King is on the EJB 3.0 expert group (as is Burke), and Hibernate fetures are making their way into EJB 3.0

One thing to be aware of is that there's lots of stuff going on in the Hibernate project. King showed six different subprojects that are in progress. One is a subproject on Hibernate annotations, another is on Hibernate-specific extensions such as constraints.

King spent most of his talk on identifying some of the major problems in object/relational mapping that Hibernate 3.0 and 3.1 try to address. For example, there are problems in inheritance mappings between object and relational models. Object models often include more information about subtype associations than relational database models (case in point: you can have an EffectiveDated abstract superclass in an object model, but you can't have an EFFECTIVE_DATED table). However, sometimes the relational model has subtyping that cannot be expressed in an object model (for instance, an object can only have one type, a relational database can have multiple types).

One of the new features in Hibernate 3.0 that King highlighted (and called "the coolest thing") is filtering. This feature allows a user to see temporal, regional, permissioned data -- in other words, data that's valid for a particular point in time, or data that the user has permission to see only for a particular region. Filter conditions are defined as SQL fragments in a mapping document, and can be applied cumulatively. King said that what's nice about this feature is that it turns messy dynamic queries (that is, queries where you have lots of join conditions) into a simple declarations.

For Hibernate 3.1, King highlighted some extensions to bulk update/delete, a new StatelessSession streaming API (that offers a more JDBC approach to streaming data into and out of a database), and "break" processing for ScrollableResults.

To find out more about these features, and what's going on in Hibernate, see http://www.hibernate.org/.

Both of these sessions were very well attended (a large room filled with lots of folks), but King's was pretty much standing room only. So I guess one could say that more folks came out of "Hibernateion" for the second talk. ;-)

Pragmatic SOA

I just returned from a session titled "Pragmatic SOA: A Case Study." So what did I learn? I think I learned that SOA is doable today. That although there are still some significant gaps in the set of web services standards and technologies, and although there still aren't a lot of good tools for implementing an SOA approach, you can still build an effective SOA solution. But you have to do it "pragmatically."

The central presenter for this session was T.N. Subramaniam, Director of Technology for RouteOne LLC, a credit aggregation management company for the auto industry. RouteOne brings together credit information that can be accessed by auto dearships in auto financing applications. T.N. said that RouteOne is one of the largest web service providers in the world. In this talk he focused on an SOA-based credit aggregation system that RouteOne implemented. He did an overview of the solution. He also covered the technology options that were available, and why RouteOne chose a particular option. For example, for B2B message binding, they use Document/literal and RPC/literal for reasons such as WS-I compliance. For XML security, they use XML-DSig because it provides for message authentication, message integrity, and message non-repudiation in a standard way.

Other presenters for this talk were Ashesh Badani, Sun's Group Marketing Manager for SOA, and Ashok Mollin, an Enterpise Architect at Sun. Ashesh essentially was the M.C., and Ashock did a follow-up, best practices, summary.

While the presentation of RouteOne's solution and their design choices were interesting, I found what RouteOne learned from this experience about implementing an SOA the most interesting part of the talk. Ashok characterized this knowledge gained as "Pragmatic SOA." Here are the SOA kernels of knowledge that came out of this experience:

• Start simple. A short term effort of say 3-6 months is best because you can quickly see if things are working as planned, and you can quickly get a sense of the return on investment.
• Let the business identify the service. Don't let IT drive what services get built. These services should follow the busines processes.
• Think XML documents, not objects. T.N. said that initially they passed around objects, and it caused problems. Document-based messaging is a less fragile and more scalable approach.
• Use SOAP as an envelope, but not as a binding
• Use WSDL for descriptions, not code generation.
• Think asynchronous conversations. Synchronous conversations can create performance problems.
• Use BPEL to orchestrate services. It's standardized.
• Use JBI for integration. It provides satndardized, pluggable framework for service integration.

T.N. ended the talk by underscoring that this is still a work in progress. He advised "Keep learning, this is not finished."

I think a lot of folks who are interested in SOA are waiting for case studies like this so that they don't have to be "guinea pigs." One of the most reasuring things I heard in this session is that RouteOne was pleasantly surprised as to how many of their decisions actually worked well. So maybe being a guinea pig in this stage of SOA maturation isn't that much of a risk. In any case, the more case studies like this, the more best practices on the books, the better and faster the promise of SOA will turn into reality.

A Hitchhiker's Guide to SOA

I thought that a session title that had the phrase "Hitchhicker's Guide" in it would draw a good audience, but I had no inkling of the crush of humanity waiting to get into the session "A Hitchhiker's Guide to SOA: Orchestrating Loosely Coupled J2EE Services with BPMN and BPEL." It felt like Times Square at New Year's Eve.

This was worth the mob scene. I know a few things about SOA, having written a few articles on it. However most of what I know delves into SOAP standards and JAX technologies for web services. I knew little about orchestration technologies like BPEL and nothing about BPMN, so I thought this would be a good session to sit in on.

It was definitely worth attending (even though I had to inch my way into the room with the rest of the mob). It was worth attending for two reasons. First it was witty. In a takeoff on Douglas Adams's Hitchhiker's Guide to the Universe, Beckham, Fast, and Frisino (all three are Sun Java enterprise tools architects, with Beckham Sun's lead architect) attempted to answer their version of the "Ultimate Question": What's the answer to everything? If you recall, in Adams's book, "A Hitchhiker's Guide to the Galaxy," Deep Thought, the second greatest computer of all time and space, gives the answer to the Ultimate Question. The answer is 42. Well, in Beckham's, Fast's, and Firsino's version, the Ultimate Question is: Are BPEL and BPMN the answer to everything for service orchestration in SOA? What's the answer? If you're chomping at the bit to know, skip the next few paragraphs.

The second reason the session was worth attending is that I learned some more about Business Process Execution language (BPEL) and I learned about Business Processing Modeling Notation (BPMN). Some of you might ask what are BPEL and BPMN? In fact, what's orchestration? Let's take the last one first, orchestration (in the SOA context) is the means of getting services to work together in the correct way and in the correct sequence. Imagine an online travel service. The service needs to do things like manage hotel reservations and handle flight scheduling. An effective way of architecting the service is to design it as a composite service, where each activity, such as managing hotel reservations, is handled by a separate service. The overall service, then, is a composite of these individual services. However to make this work you need a way to orchestrate the service, and the orchestration needs to conform to the business processes for the travel service. In other words, the sequence of services needs to mirror the sequence of "real-life" operations that take place as part of the travel service. And that leads up to BPEL and BPMN.

BPEL is an XML-based language that is used to describe business processes. It's very expressive and comprehensive. BPEL is more programming language-like than run-of-the-mill XML-based implementations. For example, it has constructs to manipulate data, and elements that describe the order of activities in a process (it doesn't only describe data). However it's not a complete programming language -- you can't for example, use it to access non-XML resources like database management systems. In addition, BPEL can't do real work. That's left up to worker services. These services are typically asynchronous, conversational, and document-centric (that is, AC/DC). So between BPEL and these worker services, you can describe a composite service that comprises a set of worker services, and enable the composite service for orchestration.

But coding using BPEL can be tedious. The BPEL schema is enormous, so although the language is highly expressive, programmers tend not to code in it.

One level of abstraction up from BPEL is BPMN, which is a standard for drawing business process diagrams. BPMN is a modelling notation that's used to graphically represent processes using common flowcharting symbols. The diagrams map to BPEL.

So let's get back to the Ultimate Question: Are BPEL and BPMN the answer to everything for service orchestation in SOA? The answer: no. Why? Because even with BPMN, describing and modifying processes are still too tedious. So what's the real answer? Tools!

O.K. you're not surprised -- after all, Beckham, Fast, and Frisino are tools guys. But they did back up their answer with a neat demo of Sun Java Studio Enterprise 9 (a future version of the JSE tool), that showed how easy it will be to describe and modify processes, and to orchestrate a composite service. You don't need to know BPEL. It's all graphical and it all maps to BPEL and Java. There seem to be pallets and menus for just about everything you need, including selections for Java-based "functoids". (I'm not exactly sure what these are, but I like the name.) There are also easy-to-use features for orchestrating a composite service. You wire the component services together by dragging a line between the services at the appropriate points in the process. And you can see what's going on (for example, what messages are being exchanged) one step of the process at a time.

I'll be on the lookout for more about JSE 9 over time. I'd like to get my hands on it and try it out.

You can get the slides for this session at http://developers.sun.com/learning/javaoneonline/2005/tools/TS-7121.pdf

Sitting Here in the Desert

Well the heat has hit Las Vegas, my hometown of over a year now. We were pretty lucky there for a while. Late Spring temperatures usually climb into the 100s and sometimes spike into the 110s. But this Spring was delightful, with no day getting above the mid-90s (at least that I can recall).

Right now it's 106, and will probably climb another degree or two. And with the rise in the misery index, my thoughts increasingly turn to the much more tolerable temperatures of San Francisco.

Next week I'll be among the throng of attendees at the 2005 JavaOne Conference. And I'm getting pretty excited. No, it's not just the heat talking. It's the opportunity to see old friends, compare notes, and see what's new and cool in the technology (O.K. I did say cool, so maybe the climate is talking). I took a quick scan of the schedule and I've got to admit that on paper this looks like one of the best JavaOne Conferences ever. How can you not be interested in sessions with titles like "A Hitckhiker's Guide to SOA" or BOFs like "Memory Leaks be Gone!"? And of course, just the opportunity to see James Gosling demostrate another tee shirt launching gizmo is worth the price of admission alone. I fully expect that one of these years, a tee shirt launched from one of these contraptions will hit with such force that the poor fool who attempts to catch it will be launched himself.

Then there are the guys like Graham Hamilton, Bill Shannon, and Mark Hapner. Perhaps they're not as cool as Gosling, but they always put on a good show.

This year I'm particularly interested in all things Service-Oriented Architecture. I get the sense that this is the year that the buzz around SOA turns into solid implementations and deployments.

Who knows? Maybe somewhere along the line Gosling will demo a tee shirt launching service complete with WSDL entry.

See ya all next week at Moscone.

This work is licensed under a Creative Commons License.