Brandon Werner

Much has been made about the purchase of Webify by IBM a few days ago, and for good reason. This is the first time that a large company has put it’s money where it’s SOA mouth has been all this time. Despite the enthusiasm such a purchase as created among the SOA community (especially smaller groups specializing in vertical markets such as Insurance), the bigger point this purchase makes is that despite all the marketing blitz and betting of the Enterprise Software market on SOA by large players, it’s the small players who seem to be doing it right. IBM, for it’s sake, has so far failed in it’s SOA products for specific industries, and it’s purchase of Webify demonstrates their weakness in developing their own custom SOA solutions.

Sadly, I have been in the position to experience this failure first hand.

I am currently neck deep in an Insurance SOA experiment with IBM as we speak, structured primarily around WPS (Websphere Process Server), SDO (Service Data Objects), Websphere Integration Developer IDE and all the rules engines you can imagine. In the SOA future, no matter what the business, business rules (BPEL) that drive the business processes in our environment will be the most important aspect of the Service Oriented Architecture. It is these mediation flows consuming and transforming messages on the ESB that give a large enterprise the flexibility that SOA promises in rapidly exposing and using services to respond to business needs. For an industry such as Insurance, the business rules and services are some of the most complex and highly regulated in the business world. In IBM’s SOA view, Websphere Process Server is the engine that combines Connectors, transformations of ESB messages and mediation flows all in one package. At least, that was the plan.

We were one of the first to attempt to use WPS in partnership with IBM, and we came in to the experiment with great enthusiasm. After all, insurance is a field ripe for taking control of complex business rules. However, some attempts we have made to stretch or conform WPS to our liking has met with failure on IBM’s side. This includes the following issues:

• Consuming SOAP with attachments to convert a message to a ESB compatible Business Object or SDO is not possible
• Consuming webservice messages not HTTP or other standard form is tedious
• Numerous .xx releases to WPS and its development environment, Rational Integration Developer, has been IBM’s usual reply to issues with service connectors and visual mapping of services to Business Objects*.

This isn’t to say IBM’s suite of products in the SOA space isn’t impressive. Their Integration Developer IDE, built on top of Eclipse in much the same way Rational Software Architect and Rational Application Developer are (indeed, it’s just a few extra plug-ins), is amazing in it’s ability to attempt to consume external webservices and transform them in to SDOs that are controlled through the use of BEPL through-out the synapse. The problem is that the technology isn’t quite working yet, something that is disappointing when SOA has already made such inroads in the marketplace.
To this point, we are scaling back our strategy of using WPS in our new SOA architecture until the product matures, a very sad real world lesson to the marketing websites and seminars IBM is currently pitching. Keep in mind we’ve not stepped outside of IBM’s technology ecosystem once so far, including using every single piece of Websphere branded application server and Component we can license.

Although I developed the architecture of the SOA migration, including an inventive strategy to wrap existing non-SOA capable services to create custom SDOs for our ESB (some of which is hinted at when I published my SDO pattern for Rational Software Architect), the primary pain has been experienced by our Integration Team who are trying to get Websphere Process Server and it’s various services to work according to our designs. It is here, in the constant PMRs with IBM in nose-bleed level support tiers, that we are getting the most reality.

Insurance, as I stated, is a tricky business to begin with, and IBM was right in realizing that when it came to this vertical market, it needed someone who knew what it was doing. However, given my experience with IBM’s SOA products to date, they are going to need much more help than Webify can provide.

* - “Business Objects” is IBM’s term for SDOs generated from messages in WPS. It does not conform to the idea of “Business Objects” from an architecture stand-point. At this point, we should probably rename BOs from Fowler’s viewpoint since it is widely mis-used.

As I was architecting some software lately, I noticed that the DeveloperWorks Reusable Asset directory had all the Enterprise and Security patterns, but the SDO pattern was sadly missing.

The Service Data Object is one of the most powerful tools in abstracting any data from it’s datasource, and is used heavily by enterprise architects and developers in Service Oriented Architectures (SOA) and in DAO patterns where you may have different data sources and abstraction is key. The SDO gives you built-in ChangeSummary ability, so that you can automatically update your datasource or XML with new data after you’ve finished using the SDO! Also, the SDO itself is serializable.

I am currently finishing an article about SDO and how to create a poor-man’s SOA from existing Business Objects using the SDO. Look for that somewhere soon.

In Rational Software Architect, having patterns in your Pattern Repository that you can drag and drop in to your Analysis or Design diagrams is essential to ensuring you’ve designed your own products correctly, and that you have the best representation of the pattern in your environment. With that in mind, I have recreated in complete detail the Service Data Object pattern here so that many SOA and DAO developers and architects can simply import it in to their RSA through Import –> RAS Asset and use it.

About The Pattern

I have included documentation from the ServiceDataObject specification Version 2.0 and have relied on several IBM and EMF document sources from DeveloperWorks and the SDO specification itself to create one pattern that seems to take in all the various text based and UML based examples of this pattern.

The completeness of this pattern is very important, so if you find anything wrong or would like to make suggestions either edit the included java file and send it along or comment to this thread.

This is an example of how it should look in your design document after you have filled out the pattern template completely and dragged the classes on to your design.

Click for larger view above.

Because of my current project name, the pattern will appear under Maestro -> Core Patterns, but you are free to copy / paste it where you like after import.

Download Files

Here is the Java file and the RAS file if you would like to do your own patterns or see how I made the associations I did above. To use the RAS file, simply do an Import... RAS Asset in your Rational Software Architect product.

1. ServiceDataObject.java
2. Service Data Object RAS File

Last month I wrote an article called “How To Save J2EE, And It’s Not EJB 3.0” that sparked a lot of controversy and a public spat with Gavin King (inventor of Hibernate and spec lead of EJB 3.0).

I argued that Java on the enterprise should be moved forward as a set of patterns and best practices, not just a set of JCP approved technologies. In other words, before you had an entire architecture (J2EE) and your designs at the application level had to conform to the architecture of the blessed JCP specification.

Or, in the words of a Jewish proverb, “You cannot break the law, you can only break yourself against the law.”

Well, it turns out that you can also change the law. That’s what I argued in my article, stating that people might not want to get wrapped up in EJB 3.0 propaganda and instead continue to use Hibernate and Spring, as well as push for new technologies that can be applied in a JEE context.

In other words, architecture becomes less important, and design extremely important as businesses develop applications that are more agile and service oriented. Most important, they can customize their JEE space to their business needs, not import the whole elephant just because you want the trunk.
A direct out-growth of that idea is a new article at O’Reilly’s OnJava called “J2EE Without the Application Server” by Guy Pardon, which gives good examples of practical design strategies for non-ejb J2EE development.

That is why I am very excited about JBoss going forward, and very nervous about hearing Oracle was looking to buy them. JBoss might be the way all application servers will look in the future, a pluggable framework of services (some JCP, some not) that offer to annotate a container with functionaity but is light-weight and flexable. You pick the architecture pieces, then design.

I’m sorry Sun, but I think the EJB ship has sailed. It was a good idea that never worked, at least not as transparently as the idea of “JavaBeans that persist state” would suggest.

Soon, ServiceLocator will be replaced by Dependency Injection (also known as Inversion of Control) type annotations in EJB 3. However, as these annotations won’t be available to helper classes like current JNDI lookups are, the ServiceLocator singleton might still be around even after EJB 3’s release, to the dislike of many Singleton haters.

There are some caveats to IoC in EJB3:

1. They are not be available to non-ejb programmers or in helper classes
2. Those who use Composite Entity patterns in their JEE architecture will not have JNDI look-ups available to them in their Dependent Objects and must aquire all their resources from the EJB itself.
3. Those who use Session Facades and Business Delegate patterns for more than EJB lookups will have to continue to rely on JNDI lookups and ServiceLocator.
4. The way IoC is implemented in EJB3 leaves a lot to be desired (not just POJOs with XML files like Spring)
5. This means that those who prefer (or are mandated) to use light-weight web frameworks and code for small to medium web applications will be stuck with JNDI look-ups and ServiceLocator(s) for some time to come.

Therefore, this article seeks to help people who want an honest comparison between the two methods of operation, about where we got where we are today, and how migrating from JDK 1.4.2 to JDK 1.5 might change their ServiceLocator pattern to reflect Java 5 Generics, since ServiceLocator makes heavy use of Collections API to cache JNDI lookups for services.

Do to formatting issues in Internet Explorer regarding all the code samples I used, it’s best if you just read this article on JavaLobby instead: ServiceLocator Pattern: Does EJB 3 Really Kill It Off?.

I got a lot of heat for stating that the way to save Java EE was to focus on architecture and not concrete JCP implementations. Although my metaphor regarding AJAX was over-represented in the press, I still believe that we shouldn’t be so concerned about using non-JCP technology in implementing Java EE architecture.

As I stated a few weeks ago:

If I am an enterprise developer, and the architect has done his job of abstracting DAO and dependent objects from the Business Objects, I can quickly plug and play from Spring to EJB 3.0 quickly. That was the whole point of DAO patterns in the EJB 1.x and early EJB 2.x days; so that when this mythical time came when CMP EJBs were fast and ready for wide deployment we could just implement that, clean the overrides and slice off the DAO / JDBC side… Why was it acceptable to do this during the J2EE 1.4 days with EJBs, but is sacrilegious to do so now to allow for Spring vs. EJB 3.0 plug-and-play? How does it not help JEE principles to write Adapter patterns to do this anymore than it did to abstract the dependent objects from DAO or to incorporate XML web service processing in our Business Delegate patterns using the Delegate Adapter Strategy?

I got knocked by Gavin pretty hard on talking down EJB 3.0, but I can’t help but think that now that his technology has been integrated in to the JCP (i.e. he won) he has become a little bit of a cheer leader for all things JCP. I wonder what he would think of Jerome Louvel’s Restlet project, a implementation of Roy T. Fielding’s excellent doctorial thesis on the REST architecture style.

The Servlet API has grown significantly over the last few years, with the addition of JSP, JSF and web service consuming all being stapled on top of the common API. Essentially, anything that has to do with HTTP travels through servlets. Although extremely simple and flexible at the base level, which has allowed for so much to be implemented on top of it, it has begun to show it’s age in its general philosophy towards persistence and mapping of sessions. Restlet is a replacement for the Servlet API and provides a lot of advantages over Servlets in HTTP communication, particularly for web services. Why has Restlet generated so much attention lately? Simply put, once again someone has decided to throw off the shackles of JCP-implied restrictions and write a solution that does not have to be crippled by the problems of the previous architecture (NIO blocking, session persistence). As we move in to thinking about SOA and the speed to which we can access and process web services from the ESB, Restlets might have appeared at just the right time.

What Spring and Hibernate did to EJB 2.x and J2EE in general, Restlet promises to do to the Servlet API.

This could mean more than just a replacement of course, but an eventual adoption and approval by the JCP. Just like Hibernate and Spring did to EJB persistence and Dependency Injection (killing my favorite asexual pattern, the Singleton), even a change in mind-set or “what is possible” could impact the next round of JCP submissions. In fact, This may already be happening as we speak.

This addition of Restlet to the Java EE open source landscape confirms what I have stated about programming to the problem domain using JEE best practices instead of just writing to the JCP specification. Those Jave EE architects who model the problem with an open mind when picking the best technologies for their next start-up or super-go-fast project will be the winners and push Java as a platform forward, particularly in SOA implementations where Java does not have the web service speed advantage.

As Gavin pointed out in his response to me, developers in Fortune 500 companies won’t be using Restlets, but then again they didn’t use Hibernate or Spring either. Although it is certain that these larger companies will always write to the vendor-pitched JCP standards, I believe that this is a demonstration of a weakness, not a strength. After all, what disruptive new way of doing something did any established company introduce? Why do they always kick themselves and try to catch up, when the obvious answer all along is that you don’t change things unless you are willing to take risks in technology?

Restlets, and its implications on the performance and flexibility of web services, is such a risk that could yield huge rewards. Unfortunately, the next Google (or maybe Google itself) will be the ones that deliver on this reward, while IBM and Sun will be demonstrating their Servlet tied technologies to Fortune 500 companies that will gawk at the idea of using such slow communication to and from their new SOA inspired Enterprise Service Bus.

But hey, at least it’s JCP approved and backwards compatible.

Good conversation between Gavin King (inventor of Hibernate & EJB3 spec) and myself regarding my article on Java Lobby. He takes me to task on arguing to leave JBoss and JEE more open to disruptive technologies like Hibernate was.

Also, I’ve been busy moving all my code and environment over to my new iMac G5 I got myself for Christmas. I have been using Powerbooks for two years now since a lot of my work takes me all over and I needed a powerful system to follow me. However, considering it might be nice to have a dedicated desktop system to use when at home, I decided an iMac G5 was just enough of an investment to last me till the Intel chip switch (investing in a PowerMac at this point without seeing the Intel benchmarks would be a lot of money invested in an old platform). The Apple Store at Kenwood Towne Center did give me an (unintentional?)free upgrade that I didn’t want by giving me the iMac G5 with the wireless keyboard and mouse ($89 extra at Apple Store online). Unfortunately, I didn’t want this option because I was looking forward to getting the Mighty Mouse included for the right mouse click. Yes, I know they are generally bad and I do have a two button MS mouse, but I at least wanted to give it a go. I’m not certain if they were out of Might Mouse iMacs or if it was a packaging error (the employee scanned the box, the additional cost was not there).

If anyone doesn’t know about Apple’s excellent online service yet, .Mac, it is truly an incredible synchronization technology that is woefully missing on the Microsoft platform despite their attempts to do something like it in MSN. I moved all of my important documents, keynote presentations and code projects I wanted to be transparent across my Powerbook and iMac on to my Apple provided 2 GIG iDisk and told both to synchronize but keep a local copy (for speed). Also, .Mac synchronizes all of your calendar entries, address book entries, email, bookmarks, keychains (passwords and forms for the web and drive shares) and other system settings between the Powerbook and the iMac seamlessly. If you code on the iMac for two days, add lots of code to the project, and then open your Powerbook.. there is your code on the Powerbook. Same with an appointment you add to your Powerbook during a meeting, as soon as you go home and log in to your iMac.. there it is.

I knew it did this in theory but I had never before used it to keep everything in sync. It works wonderfully. (Both Mac OSX 10.4 Tiger, your mileage may vary).

It is a platform in itself, with the latest .Mac SDK 2.0 (Developer Preview 2) just released, which allows third party providers to write to this sync technology. Transmit, a great graphical FTP application, uses this SDK so that your list of FTP sites (and username / passwords) are updated between your computers - directly in the application - so that as soon as you launch Transmit the new FTP sites you may have added on your Powerbook now appear on your iMac. NetNewsWire also uses this to keep your RSS feeds synchronized across Macs, even keeping track of which articles you’ve read and which you have not. It’s not hard to imagine the other great applications using this technology.

Also, IntelliJ Idea on the Macintosh platform is a joy, although people should be wary of Apple’s latest J2SE 5.0 Release 4 Developer Preview 3 that appeared on the developer site two weeks ago, it seems to have some Swing bugs on redraw. I’d stick with the Apple J2SE 5.0 Release 3 for now.

Finally, I upgraded the site to Wordpress 2.0 two days ago. If you didn’t notice, it’s because it took 5 minutes (plus about 30 minutes to re-apply my stylesheet and code modifications I made to the old site). Wordpress has made the upgrade very easy, but for a 2.0 release the feature-set has not been added to greatly. However, a lot of the changes are under the hood and the site does appear faster. It even includes the AJAX goodies all web apps must have these days, but they are mostly just visual candy. For instance, when you delete an item the list fades to red and then disappears. Wooooo. Ahhhhh. Pretty!

The best things are to come in the future to be certain, when the plug-in developers begin working with the new 2.0 API. However, if you are holding off on upgrading to Wordpress 2.0 on downtime concerns, it’s not really an issue.

I write for a few journals and as I have been talking with editors about story outlines, articles and ideas going forward in 2006, I’ve noticed a huge push in talking up EJB 3.0. In fact, one “highly placed” editor told me flat out:

“Nothing about Hibernate or Spring, EJB 3.0 is coming out, people need to start writing to the standards now.”

Wow. As a person well versed in enterprise architecture and development, I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship. However, from the enterprise viewpoint, it doesn’t matter if you use EJB 3.0, Spring or even Hibernate to eliminate the DAO issues in dependent objects of light-weight Composite Entity patterns, it’s all JEE to the architect.

If JEE is to survive as a platform, we have to stop teaching JEE as a set of JCP blessed related technologies, often complicated, as implemented in the Glassfish reference implementation, may Sun (Ra?) be praised. I believe that the best way to move on to the JEE 5 era and eliminate all the weeping and nashing of teeth that EJB 1.x and EJB 2.x introduced to developers is to teach JEE as a set of patterns and ideas, abstract from the actual implementations of various providers, and label them as best practices of the enterprise space.

Think AJAX. AJAX is not a set of any one company’s technologies, and there is not even a “reference implementation” of it. You are free to use any backend you want, use any persistence you want, and even implement your own call-backs and improvements. The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can’t JEE be more AJAX like? Why do we have to politically migrate towards these reference JCP technologies when the actual, real JEE patterns don’t give a damn what you use?

When I create UML models or look at others and see lots of Business Object patterns and DAO patterns and Domain Stores in their neat little component architectures, I see JEE Proper: isolation, coarse grained objects, security & independence. Now, what does it matter of company A decides to implement their business logic by plugging a EJB 3.0 embedded in to their JBoss app server, or use Spring embedded in the JBoss application server? If I am a web developer or application developer using a sea of Business Delegates to access the core services of an enterprise application, how does that affect me? If I am an enterprise developer, and the architect has done his job of abstracting DAO and dependent objects from the Business Objects, I can quickly plug and play from Spring to EJB 3.0 quickly. That was the whole point of DAO patterns in the EJB 1.x and early EJB 2.x days… so that when this mythical time came when CMP EJBs were fast and ready for wide deployment we could just implement that, clean the overrides and slice off the DAO / JDBC side.

Why was it “acceptable” to do this during the J2EE 1.4 days with EJBs, but is sacrilegious to do so now to allow for Spring vs. EJB 3.0 plug-and-play? How does it not help JEE principles to write Adapter patterns to do this anymore than it did to abstract the dependent objects from DAO or to incorporate XML webservice processing in our Business Delegate patterns using the Delegate Adapter Strategy?

Some people contend that the whole reason for following only JCP blessed and Sun approved JEE components is that the tools to develop these applications and the application servers that run these applications MUST have one standard to code and test to. However, if JBoss has proven anything, it’s that multiple JEE technologies can be housed in one application server and even made available to the container without compromising or affecting JCP-blessed JEE technologies. In fact, as we have seen, JBoss and Oracle both use their own persisting technologies (Hibernate and TopLink) to implement EJB 3.0. Spring can run inside JBoss, and a lot of enterprise deployers now strip much of the JEE JCP technologies right out of their JBoss configuration to increase speed and improve reliability.

Further, on the tools side, the explosion of Hibernate mappers and Spring helpers for Eclipse, Netbeans and IntelliJ shows us that developers are more than capable in this day and age to add tools that can automate JEE technologies that are not JCP blessed. In a world where our IDEs are platforms in themselves, the flexibility of creating plug-ins to manage complexity in new JEE technologies should not cause anyone to worry about productivity.

I believe that if we are to save the JEE stack, and keep it innovative, we have to allow for non-JCP or even pre-JCP technologies in JEE, and to embrace them as much as possible. Think of what EJB 3.0 or JEE 5 would be like if Hibernate and Spring never existed? Do we really want to now step on the fingers of these programmers and point towards EJB 3.0 as the one true way?

What if we just understood JEE the way it should be understood, as a collection of best practices and server-side solutions, and let the community loose to invent awesome technologies to continue to solve how these technologies in JEE can be better implemented? As this latest JEE upset has shown, we can’t predict what amazing and interesting things are out there from the incredible Java community, and to isolate them from JEE and politically push only JCP technologies in the stack ensures not just the end of JEE for the big guys, but a possible end to all the great work that has been done in JEE engineering regarding software development, the software development process (RuP, Iteration) and development patterns. JEE is much too important to all of us Java developers to abandon it or kill it with inflexible “picks” of technologies to go in the stack.

JEE is about persistence, high availability, scalability, coarse grained objects, best practices and rapid development of enterprise quality code that can be organized and managed by teams and companies through business processes and refactored or scaled by keeping best practices in mind. As we have seen in the past, JEE can deliver on this, even if Sun throws things like the EJB 2.x spec in its way. Let’s keep the innovation going, let’s not return to the days of old.

Java deserves better.