Monday, November 24, 2003

BPEL and Car Windows I had one of those experiences today that makes you realize the value of standards and a common understanding of those standards.  I was travelling to Vancouver, Canada to present an Oracle Developer Days for a workshop entitled Best Practices for J2EE.  At the workshop I will be  presenting three sessions - the introduction, Apache Struts and J2EE performance tuning.  As part of this, I rented a car to get around. When I pulled up to the hotel, I instinctively reached for the window handle/window control on the door so I could roll down the window and pick up the parking ticket.  No nob!  No handle!  I couldn't figure out how to open the window so ended up opening the car door and reaching for the ticket.  After parking, I spent a minute looking around and poking at buttons and then realized that the window control was in the center console of car, not on the door at all - literally to the *right* of the driver (I won't name the brand - just think small and the least expensive you can rent).  For whatever reason, I generally believe car window handles/nobs should be on the door that has the window - not somewhere else. This disconnect, cognitive dissonance or whatever you want to call it, is often what developers get these days when discussing J2EE and you *don't* use commonly understood terms.  At the core is a wide understanding of what EJB's, JSP, Servlets and services like JMS, JTA, JMX etc are.  Design patterns are another level in J2EE that have wide comprehension by developers.  Talk technically  to a J2EE audience and and these terms will grant them instant understanding of your topic. Now turn to my area of BPEL.  Before Oracle decided to embrace BPEL, like every vendor who has made the transition, we had our own internal way of thinking and describing business process constructs - for example BPEL constructs like <variable>s, <invoke>s, <receive>s, <assign>s, <correlation>s, <flow>s, <sequence>s - before adopting BPEL, each construct had alternative construct. Anytime we described BPEL, it was in terms of - "well a BPEL <receive> is kind of like <xyz_thingy_majig>" or "we don't have a BPEL <switch>, we have  an <if_then_else_kind_of_thing> construct" and so on. We always had to translate back and forth.  Now, with the world is going to BPEL, customers want to hear about how good your implementation of BPEL construct <xyz>.  They *don't* want to hear about how your proprietary construct <abc> is just like BPEL's <xyz> but better in these ways.  When standards win, they win big - SQL and J2EE show this.  By no means are SQL and J2EE perfect, but try selling someone an IDMS database today or a Powerbuilder 5.0 client/server application today and see how far you get.  Great technologies in their time, but no longer standard - de facto or de jure. One area that causes some folks difficulties when they make the transition to native BPEL is the concept of "data flow" versus "control flow" (there is a rich literature on this - this link is just an example picked from a Google search).  BPEL has a simple conception of dataflow with assign so speaking about more complete data flow concepts to BPEL fanatics who only know control flow will give them the same disconnected feeling I had when looking for my window handle - "oh, it's in the middle of the car ... strange ... I guess I get it.  Hmmm, I think  I like window handles on the door with the window!" There is always a catch-22 with this lesson ... if the standard you adopt in hopes of riding this common understanding wave *doesn't* catch on, you've gone down a dead end.  When there's no data flow, there's no data flow.  The goal of standardizing business process languages has been  a long journey so many XML BPM languages have had untimely deaths. The other danger of course is being slave to a standard that stifles innovation.  You don't want to be innovating on the horse and buggy when the real action is in the automobile.  Maybe a window nob in the center console is the best way to do windows.  This is somewhat a JBoss argument with AOP - yup, we like J2EE (we're all signed up) but check out this AOP stuff ... So does BPEL pass the test?  You can't do much better than having Oracle, Microsoft, IBM, Siebel, SAP, Sun and nearly every major IT vendor on the planet backing it.  It really does appear to have a reasonable chance to be the business process equivalent of SQL for databases or J2EE for business applications.    Is there lots of innovation about to happen here?  I think so.  However, of course, only time will tell. comment [] 10:39:57 PM