|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
July 2, 2004
|DDD - Diagram Driven Design|
|What Does It Mean to Use Messaging?|
|A Chapter a Day...|
|Clouds and Integration Patterns at JavaOne|
|My First Google Wave Robot|
|Into the Clouds on New Acid|
|Design Patterns: More than meets the eye|
|Reflecting on Enterprise Integration Patterns|
|Google Gears Live From Japan|
|Double-Dipping: OOPSLA and Colorado Software Summit|
|Enterprise Mashup Summit|
|Facebook Developer Garage|
|Mashups Tools Market|
|Mashups == EAI 2.0?|
|I Want My Events|
Both Oracle and BEA used their platinum sponsor keynotes to show their latest SOA and orchestration tools. Scott Dietzen from BEA demo'd the latest process designer additions to WL WorkShop under the Liquid Computing banner. We also got a brief glimpse at project Quicksilver, BEA's answer to the Enterprise Service Bus. QuickSilver is based on an asynchronous messaging bus and I was happy to see our familiar patterns Content-Based Router and Message Translator in the mix. We are supposed to see a beta version of these tools by the end of the year. The BEA keynote was pretty good, except that I can't help but cringe when I hear the line "we have a visual tool so it is suitable for business analysts" (see Doodleware).
Oracle showed their trusty JDeveloper demo, albeit with a new SOA and Web services spin. We got to see Ted Farrell build Web-based UI's based on external Web services. We then saw a BPEL editor that allowed us to chain Web service calls and the usual flow constructs such as decision points, forks and joins. The tools are nice, but in my opinion all process modeling tools start to look very similar to one another. Oracle's continuous zoom-in-zoom-out feature is neat even though it looks like once you have a good overview over the process you can't read the label text and vice versa. I agree with Charles Young that all integration developers should be setup with two large monitors side-by-side. Seriously, I believe that what we are seeing now is simply the first generation of BPEL editors. It's somewhat analogous to Java code editors before IntelliJ -- they do the job just fine but once the new generation arrives you realize just how much more potential there is. It will take some time for vendors to better understand the developer usage patterns and how to make BPEL development more efficient. While this year seems to be a "me too" year for BPEL editors I expect to see quite some innovation in this area next year (maybe I can help?).
Oracle revealed that their BPEL tool is essentially based on the freshly acquired Collaxa BPEL engine and editor. Edwin got to be up on stage with Thomas Kurian and demo'd the Collaxa tools turned Oracle BPEL Process Manager. I was lucky enough to have dinner that night with Edwin and Amlan from Oracle and hear about their future plans. Integration and orchestration is high on Oracle's list so stay tuned. The good news is that they will continue to support multiple app servers.
I attended a number of Web services talks, mostly hosted by Sun engineers. In general, nothing really blew my socks off. A talk comparing Web services architecture and performance between J2EE and .NET showed a bunch of meaningless numbers somehow making us believe that J2EE is faster. The tests were done with the old WSE 1.0 stack from MS and the presenters lamented the fact that Microsoft Web services are script-based ("like JSP"). I guess they had not heard about code behind pages. I am not saying that Microsoft Web services implementation is better than Sun's but at least give us a fair comparison instead of slides filled with meaningless numbers.
A number of sessions talked about JAX-RPC 2.0. Despite the unlucky name, this API covers both sync and async Web services invocations and supercedes JAXM. JAX-RPC 2.0 will take advantage of generics and futures, making asynchronous Web services invocations more comfortable -- very similar to Microsoft's delegates (available now) and generics coming in .NET 2.0.
I attended a good session on Fast Web Services. I agree that sending verbose XML strings across the wire on the off chance that a human wants to look at them without using a tool is a rather big waste of network bandwidth. A simple binary format can cut the message volume and parsing effort quite a bit. Other aspects of Fast Web Services include removing the self-describing nature of the documents. I am a bit more on the fence on that aspect; one can't help but wonder whether you should be using Web services in the first place if your performance requirements force to use a fixed binary format.
The glut of new WS-* specs seems to be never ending and even I have a hard time keeping track. Two months ago, WS-MessageDelivery was submitted to the W3C and is likely to compete with WS-Addressing. So we have essentially Sun, Arjuna, IONA, Nokia, and SeeBeyond pitted against BEA, IBM and Microsoft. The WS-MessageDelivery team sports some very bright individuals like Mark Hapner (Sun), David Ingham (Arjuna) and Eric Newcomer (IONA) so I am inclined to keep an eye on this spec. Unfortunately, for users of Web services things seem to get more and more confusing and the WS-I profile seems to lag more and more behind the reality.
I have to admit that I have not had a lot of time to track the JSR activities in Java world. I am always a little skeptic of integration-related efforts that are language specific but maybe I am judging prematurely. I am going to check out JSR 208 - Java Business Integration and JSR 207 - Process Definition for Java. On the other hand, JSR 181 - Web Services Metadata for the Java Platform seems very reminiscent of the existing ASP.NET Web services attributes.
The mandatory "Pavilion" was packed with vendors showing their wares and handing out tickets to various parties. Once again, BPEL was well represented. I saw BPEL editor demos from SAP and Oracle. As I said before the tools are not bad but will take some work. Opening a dialog that makes me enter XPATH to assign a single field from one message to another is not likely to boost developer productivity. Do we need a reminder that developers do not code in dialog boxes? Or is this one for the business user? I was happy to hear that Oracle is planning on building a nice documentation function that allows me to print the process with all the detailed settings.
SeeBeyond was not demoing anything as per corporate order. I can understand that they are afraid of the competition getting free demos (or bloggers ranting about their product) but not showing anything does not seem like the right answer to me either. If your product is truly worth steeling from you should focus on extending your lead not on trying to keep it secret.
Unfortunately, I missed the JINI session discussing Orbitz' architecture. Orbitz went the JINI route as opposed to the EJB route and is quite happy with the results. I think architects building services architectures (including myself) can learn quite a bit from JINI. Too bad that I missed the Java Communities in Action event. Next time I need to coordinate with Bill Venners to get the whole scoop on JINI-related events at JavaOne.
Last but not least, my session on Asynchronous Messaging Architectures was well attended, somewhere around 300 - 400 people. My slides mentioned the word "Java" only once and apparently escaped the legal review, which tends to insert "TM" after every other word. I made a bet with Rupin from DigitalGuru that my book would sell out. I won -- it sold out by Wednesday morning but still made it to be the highest-ranked non-Java book at the show. Hopefully, Rupin will stock a few more copies next time :-)
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is a software architect with Google. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.
|© 2010 • All rights reserved.|