Brandon Werner

I get a lot of emails about my critique of IBM’s Websphere Process Server, mostly along the lines of this email:

I’ve sent this email to you a couple of months back but didn’t get any reply. just thought would try my luck again…

we’ve made some progress with WPS and identified what areas are less risky so we can use at least some of the product features. we’re now building a prototype that uses mostly human tasks and some processes wrapped around them and we expose this all via webservices. there’s some pain around versioning, BPEDB queries, security, etc but at least we’re making a progress and early indicators seem to be on a positive side. we have had a couple of IBMers on site for a week and they helped us somewhat to rejig the design and focus on the features that seem to work and would add most value

still would be extremely interested to find out if you have done more with the product since you blogged about it

Well, obviously for competitive and disclosure reasons I can’t spill the beans on where my current employer is, what they are doing or why they are doing it. With those hand-cuffs in full public display, I will effort a more general entry about the state of affairs of this odd stack IBM has built.

In order to understand IBM’s approach to Websphere Process Server, you have to understand SCA/SDO, the unholy combination that seems to be driving the SOA mythology as of late.

About SDOs

There are currently three different implementations of the SDO spec, including Apache’s Tuscany (the one I’m cheering for), IBM’s from their EMF project for Eclipse and the interesting EclipseLink from Oracle and Interface21 (when those two get in a room together you should listen). EclipseLink is more of a consequence of combining SDOs and JPA, however.

I’m extremely excited about SDOs in general, to the point that sometimes I sit on my deck and dream about them. I even write presentations about their architectural implications. SDOs are awesome things.

They are, in essence, disconnected DataGraphs of DataObjects from some source. This source could be relational databases, entity EJB components, JCA, XML pages, Web services, or a combination of them all.

They can be acted upon and changed, updated and deleted, transformed, even serialized and sent to other objects and then connected back to the original data source with a ChangeSummary() to boot. For a more detailed understanding, check out IBM’s Introduction To Service Data Objects.

This is what they do in a nutshell:

1) You have data in any form from anything: Databases, XML, text, anything (or a combination of them).
2) You feed that data in to a Service Data Object.
3) Things can get pretty loose in there, so you can impose an XSD to define the types or just create the model on your own as you feed data in.
4) You disconnect the SDO from it’s source.

SIDEBAR: Last year I wrote a design pattern for SDOs in Eclipse’s UML2 framework that you can import in to Rational Software Architect.

Now you can do anything with this thing. Change the data inside, add more things to it, remove things from it, serialize it and send it across the wire, query the data inside of it, introspect it, combine it with JPA and tell it to save itself away from it’s source, anything.

Imagine the implications.

Design Strategy: Using SDOs with POJOs

No longer do objects have to have a strong contract, or any contract at all besides taking a type of DataObject. Your Business Objects can introspect the object itself to see if there is data inside of the DataObject it requires to do a task, do work on your behalf, update the DataObject’s DataGraph with new information (or replace existing information), and pass that SDO right back. The calling object can ask for a ChangeSummary() to see what occured to the data in that object, act on that data, and send it right along again to another object. When you are finished passing it around, it can immediately turn back in to the XML or database row it was loaded from.

Your Business Objects can change, the data inside your DataObject can change, or be a totally different DataObject all together. As long as the Business Object can query to see if the data it cares about is in there nothing about the contracts between your objects need change. Further, because of the API that comes with the SDO spec, your object doesn’t really need to know anything about the DataObject it’s feeding data into or getting data from. It can work with the part of the DataGraph it needs in a hands-off way and be done with it.

Think of it from a automobile insurance Use Case:

Say that you had a document based webservice that took an automotive insurance policy. This automotive policy would have an XSD that ensured it contained the data necessary for a complete policy. That XML document, once received, would be loaded in to an SDO with the XSD which would “strongly type” the data inside the DataObject that was generated.

Now, imagine this policy was sent to the webservice for a claim to be issued. You could pass this new SDO in to a “claims” system to be processed. The contract for the Claims system is just an SDO (type DataObject). The Claims system would do a simple XPath query, or do a get() on some data that it expected any DataObject that would come in to the system to have (remember, the data inside does have querable types because it was loaded with an XSD). Technically, it could even introspect the SDO DataGraph to find the data it needed. Whatever.

It would probably want to get Customer Information, Units Insured, ect. It would then do it’s own thing looking up the coverages, the limits and going about process to start a claim.

After processing, it could then append it’s update to the SDO by inserting data back in to the DataObject. The DataObject would then be sent back to the webservice, which would change the SDO back in to the XML document (again, the XSD ensures compliance) and sent back to the ESB or some other thing, but now with information on the claim that was created for it.

Now, remember that the Claims system doesn’t really know or care that the SDO is a policy. In fact, the SDO really has no type at all. You could have policy information, a recipe for Apple Pie and an iTunes playlist in the SDO. As long as the Claims system can get the right data from the SDO, it’ll work.

You could just as easily send the Claims system an SDO that only has the data necessary for issuing a claim. You could also change the Claim system so that it requires more information from the SDO, or writes additional information to the SDO (say requirements change).

None of this need impact the contract or the SDO that gets sent to the system.

So essentially, this is what an SDOs used with POJOs alone gives us:

• Objects are loosely coupled
• Object’s data can be discovered at runtime through query
• Object’s contracts are data based, no types or tightly binding interfaces
• Object is protected from contract and interface changes in system
• Objects can be placed anywhere - maximum reuse
• Object can modify it’s types and data structure during runtime
• Object has no restriction on the data it can share
• Object is decoupled from the format and source the data came from
• Object automatically can roll back to the previous data state or act on changes

This is just the impact SDOs have on sharing data between objects. SDOs have much more up their sleeves, including transformations and mapping.

It’s easy to see how this would fit in nicely to the theory of an SOA architecture. If you could just push around self-contained datagraphs of dataobjects, disconnected for their source, and transform them, map them together or change them in to other types of data, a lot of the complexity of dealing with data in an SOA would be solved… or at least abstracted.

SDOs and Websphere Process Server

It’s helpful to keep in mind that all workflow engines (WPS, JBoss jBPM, BlueSpring’s BPM) is a movement of the business logic and process flow from inside the code to outside, and that can only mean better flexibility for organizations going forward, even if current architecture design patterns regarding Business Objects have to change and give up their power or expose it more freely for orchestration (Fowler be damned).

The most intriguing thing about WPS, or any modern workflow engine, is the idea of visually managing the flow and business logic of services in an SOA. WPS promises to separate this orchestration from any code (save the code that it generates) and mix in human tasks to boot.

Workflow tools can be great when you have an Enterpise Service Bus or other solution where you have data flows coming at you from different technologies and different protocols that you want to feed in to a workflow. When you pull in a webservice or other Type that WPS supports in to it’s grahical tool, Websphere Integration Developer, it essentially reverses these data streams or objects in to strong types that are represented visually so that you have common base on which you can orchestrate, transform, and map the data between the various other imported flows. It’s easy to see how it leverages SDOs to do this, as it’s essentially what SDOs are best at. Mapping between these things and orchestrating them are easier if you have an abstract representation of the service or object.

The idea of building an entire enterprise from the ground up with this product is intriguing. However, I doubt that any project already in motion could manage to migrate from business logic in code to business logic in a product without significant rework, and the consultants specializing in WPS (and they are starting to emerge) seem to only have experience starting from scratch and in projects with human interaction. Regardless, this orchestration is most likely where WPS has the most benefit. It’s idea of transformation and consuming of the documents in the mediation itself is where things break down.

In Websphere Process Server, IBM essentially decided to use SDOs to parse and transform any data that comes in to their system. They coupled this with their previous Websphere Business Integrator product (WBI) for business orchestration of the processes that use these SDOs, stapled on an ESB implentation, stuck a feather in it’s cap and called it Maccaroni.

A product being a webservice de-seriailizer, data mapper and transformer, workflow tool and process manager is what ultimately makes Websphere Process Server the strage beast it is, and is also a major source of it’s problems.

In the work I’ve have done with WPS from a purely transformation and webservice flow standpoint, I’ve have found it to be slow but it works. There has been significant problems with the limited amount of flexibility WPS has in processing XML, managing messages and executing processes. IBM pitches that with WPS/WID business analyst or architects would be the ones that would do the mapping and process orchestration using visual tools. Often, however, we have been forced to fall down past the level of abstraction that WPS provides down to the Java code itself, which that is a sign of, if not failure, then immaturity.

Also, Websphere Process Server’s IDE where this mapping takes place visually, Websphere Integration Developer, is (since it is built on top of the Rational/Eclipse platform) hard for non-programmers to grasp; the idea of having to switch perspectives in Eclipse is foreign and unhelpful.

Ye Ol’ Impedance Mismatch

Unfortunately, even when you do go down to the Java level, things aren’t easy.

There are many times that what a WSDL specifies (compliant XML mind you) as a certain “type” and what “type” WPS renders for it are totally incompatible. For XSD:ANYTYPE, it dies flat out. However, so does any WSDL2Java tool. To combat this, code that was using the Collections framework has to be migrated to fixed length arrays so that WPS can interpret the output, as it sees any List as “AnyType”

Certainly, this type mis-match is experienced whenever one jumps from objects to documents in representing data (JSON anyone?), but that just points to the enormity of the problem WPS is trying to solve, and how trying to reverse XSDs without developer intervention is painful and filled with problems.

My Update

So, my update is that it still is not delivering on it’s promises, yet. However, I have heard from IBM that version 7, based off the Rational 7 (Eclipse 3.2) platform should be out in August / September.

I hope the reply was worth the wait.

The Eclipse Modeling Framework (EMF) is one of the least understood and most powerful frameworks ever handed down to us mortals by IBM. Often confused with providing UML modeling capability in Eclipse and the Rational toolset (that’s actually the UML2 Framework) EMF concerns models in the meta-data sense, and is, in essence, an abstraction engine for data and code. The fact that Service Data Objects (SDOs), one of the two frameworks of the holy SOA stack (SDO/SCA), is built on top of EMF points to it’s power.

Sadly, most of us often encounter EMF only as some tool failure where we get an .Ecore error or some other nasty issue, and we usually reverse tracks instead of digging in to the mysterious innards of Eclipse. It was in this scenario I discovered a problem with EMF and Websphere, and I’m certain from the message board posts it’s gonna get a whole lot worse before it gets better. Luckily, there is a simple way around it.

The EMF Error

If you do any deployment on Websphere 5.x and higher, particularly it seems now that version 7 of the IBM Rational Platform is out, and use EMF either in SDOs or other parsing technologies, you’re going to run in to this error:


java.lang.IllegalArgumentException: resolve against non-hierarchical or relative base
at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)


This is all the information you get, and it can be maddening. I was forced to face this error recently when trying to load in a xsd file in to an SDO from a relative URL. You can duplicate this problem by running the code below:

public class Test1 {

private static final String PO_MODEL = "po.xsd";
private static final String PO_XML = "po.xml";

private static void definePOTypes() throws Exception {
FileInputStream fis = new FileInputStream(PO_MODEL);
XSDHelper.INSTANCE.define(fis, null); // In Websphere container this will fail
fis.close();
}
}

public static void main(String[] args) throws Exception {
definePOTypes();

FileInputStream fis = new FileOutputStream(PO_XML);
XMLDocumentImpl xmlDoc = XMLHelper.INSTANCE.load(fis);
DataObject purchaseOrder = xmlDoc.getRootObject();

Of particular interest is this line here:


XSDHelper.INSTANCE.define(fis, null); // In Websphere container this will fail


Explanation Of Error And How EMF Determines Runtime Hierarchies

This XSDHelper simply takes an XSD (either String or stream) and prepares the SDO. In essence, the XSD gets parsed so that the SDO can apply the XML or any other data it gets to the XSD for Type validation. This XSDHelper is just a wrapper around EMF, which takes the XSD and begins to fit it in to a meta-model that Java can deal with. What is interesting is what EMF does under the covers, and for this we need to know about the URI class in EMF, and in particular the resolve method.

Recall the class we got the error from:


at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)


The URI class in EMF is simply a representation of a Uniform Resource Identifier (URI), as specified by RFC 2396, with certain enhancements. Like String, URI is an immutable class; a URI instance offers several by-value methods that return a new URI object based on its current state. Most useful, a relative URI can be resolved (that’s the resolve() method in the error we got) against a base absolute URI — the latter typically identifies the document in which the former appears.

It’s finding this absolute base URI that EMF is having the problem with when it says “resolve against non-hierarchical or relative base”. Why does it always want to resolve a base absolute URI? Think of the situation poor EMF is in when it gets a relative URI. What if your XSD refers to other XSDs (po-folk.xsd)? What if it specifies other relative links in relation to it’s own place in an heirarchy(../po-folk.xsd)? EMF can’t deal with that unless it knows exacly where it is in your filesystem or URI landscape.

EMF And Websphere

So, now we know how that works, but what’s wrong with getting the absolute base URI in Websphere?

Well, let’s talk about those “certain enhancements” IBM mentions when talking about the URI class. Even though you probably don’t think about it, almost everything you access in a Java runtime is some kind of archive, no matter if it’s Jar or Zip. Even if you don’t think your working inside a JAR, if you’re running an IDE chances are you are. One enhancement in the URI class of EMF provides support for the hierarchical form used for files within archives, such as the JAR scheme. By default, this support is enabled for absolute URIs with scheme equal to “jar”, “zip”, or “archive” (ignoring case), and is implemented by a hierarchical URI, whose authority includes the entire URI of the archive, up to and including the ! character.

If we would ask EMF for the absolute base URI of the po.xml file in a typical Java application, we would see this:


jar:file:/C:/workspace/test/xsd.resources.jar!/org/eclipse/xsd/po.xsd


This is the URI, with the absolute base URI being “jar:file:/C:”. EMF would be confident all things could be found in relation to this root location.

Now, what happens if we do the same thing in Websphere?


wsjar:file:/C:/workspace/test/xsd.resources.jar!/org/eclipse/xsd/po.xsd


What’s that? A non-standard archive scheme called “wsjar”?. It would appear that IBM, never content with being standard, has an archive scheme that is completely different from one if you were to access a Jar file from outside the container.

What happens when EMF tries to get an absolute base URI when it doesn’t know the archive scheme of the file it’s looking it up for?


java.lang.IllegalArgumentException: resolve against non-hierarchical or relative base
at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)


How To Fix It

Now we know what we’re dealing with. How do we fix it?

Well, all we need to do is let EMF know there is another archive scheme it needs to keep an eye out for, and you can do that two ways.

At the command line:


-Dorg.eclipse.emf.common.util.URI.archiveSchemes="wsjar wszip jar zip"


Or set it up in your WAS configuration as a JVM property.

I hope you learned something interesting about absolute base URIs and stumbled upon this article before you shed too many tears. I don’t know why more people are experiencing this problem with WAS and Rational Application Developer / Rational Software Architect 7, but hopefully IBM will see it fit to provide an EMF in Eclipse that has these new archive schemas built in. Lots of headaches could be solved.

Twitter, the service I talked some time ago (and use on my website for fun) is from the same company that releases the podcasting website Odeo. In order to get their AJAX goodness, they use Ruby on Rails. Needless to say, as Twitter has exploded they’ve run in to problems in scalability. But instead of hiding it (the way us Mac users hide that there is, in fact, an OSX BSOD) the lead developer is actually pretty frank:

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.

EDIT: I apologize for getting the companies mixed up. I knew that Twitter came from an experienced team already use to doing AJAX work, and when I saw the response to the Twitter scaling issue came from David Hannson, of 37 Signals, I got confused.

(Link via Daring Fireball)

I will speaking at the IBM Rational Software Developer Conference 2007 at the Walt Disney World Dolphin Resort June 12th, 2007 @ 11:30am (BBT07). This will be the first presentation I’ve done focused on one industry segment, and although I know that IBM has purchased Webify for it’s Insurance specific stack, I won’t be presenting that but instead some pitfalls and good ways forward for moving from a Legacy environment to a SOA using Websphere Process Server.

When I wrote my piece on IBM’s Websphere Process Server and it’s purchase of Webify, Robert LeBlanc, General Manager of WebSphere, forwarded it to Steve Mills, and the sparks flew (RedMonk’s James Govenor confessed it was him who forwarded it on to Robert). I understand, given the large amount of interest in these products, why such a public critism would cause concern, but there was a fair amount of praise for what WPS and WID has accomplished in the SOA space, particularly in the important (and thus far in Computer Science, elusive) goal of making a visual BPEL/development tool. This presentation will be along those lines; how to practically use these tools to create an even more compelling architecture without too much Legacy headache using Webpshere Integration Developer and Websphere Process Server.

Try to join me if you can, and if you are going to RSDC 2007 drop me a line so we can meet up and have a beer.

When I interviewed Bruce Tate a few months before his Comp. Sci. best seller Beyond Java came out, he introduced a term that has always stuck with me:

“Java is dead like COBOL”.

What he meant was that although the Java language will certainly go on in the future as a legacy language and find new implementations from lovers of familiarity and the haters of change, the future of languages most likely has moved on. To see it, look at C# or Python or Ruby, where their creators talk about lambdas, functional composition and closures. He did mention, however, that the JVM would continue to be an important and vibrant piece of technology even after Java has been moved to the dust bin. His pronouncement was in late 2005, before the idea of a scripting plug-in to the JVM was even formalized (but Microsoft’s CLR was realizing the promise of the JVM abstraction much to Sun’s chagrin)

Today I have an example of that future.

Everyone knows that the JVM has hidden gems that, because of past mistakes and present misconceptions, go unused. One of these is SWING and Java2D. While Adobe’s Flash and Microsoft’s XAML are taking a lion’s share of the buzz on rich web applications (which is really aimed at removing the restrictions of the web browser from the application process all together, and something I am definitely fond of) it is often forgot that the JVM also provides this technology in spades. Sadly, it would seem that this is something else that the JVM has an answer for but will lose to those with easier implementations. One of the promises of new scripting languages being plugged in to the JVM is that this functionality can be exposed in new and better ways. Browsing LtU today, which often depresses me that I can’t just sit in a tree and program Haskell and Scheme all day, I came across a Sun employee Chris Oliver who wrote his own scripting language called F3 (Form Follows Function). It is suppose to be better than JavaScript (static typed and compile-time error reporting) and exposes all of the Java2D and Swing stuff easily.

That would be an understatement of his accomplishment.

I was floored by his example in his post below, where he wrote a new frame for the Fantastic 4 trailer using his new language. Most amazing, because it can leverage the entire platform and delivery mechanisms of the JVM, it uses Java WebStart to push it your machine. He even creates a Mac-like reflection by painting the video off the y coordinates using a negative scale… all in real-time… all in two pages of script.

The results are amazing.. Link here

Some more discussion of his work regarding this example is here.

This shows how the Java platform may have a life post open-sourcing and light-weight framework trends, and will continue to influence how we write and deploy applications. Although most of the press around scripting engines in Java has been around Python and JavaScript, the real potential lies in allowing levels of abstraction on JVM functionality, not just allowing languages to mingle inside one runtime.

Brilliant.

I have been asked to present my work: “The Future of ACORD: Using Data Standards In The Semantic Web” at the Insurance Industry’s major conference ACORD-LOMA Insurance Systems Forum from May 20th - 22nd at the Dolphin Resort at Disney World. Since Microsoft and IBM are platnum sponsers, I’m expecting lots of free stuff At least, more than you get speaking at the Rational Conference.

I have included the detailed snippet from the brochure below, and more information about when I’m scheduled should appear on the website after February 2nd when I deliver all my media information (my head shots from junior high apparently don’t cut it anymore)

My primary thesis is how to use the language in which we communicate, XML (here ACORD standard) and apply meta-data to enable us to gain insight and increase both human and machine understanding of the data we have, essentially helping us make better decisions. It’s easy to see how a system knowing what a policy or a named-insured is beyond just an XML tag can benefit decision making systems including competative rating and data mining for risk patterns in insurance. All of this is based off of using RDF and Ontologies (here developed for insurance) to make relationships between data. Imagine how much more valuable a data warehousing operation would be with this solution.

I think you’ll like it and I hope you can make it.

My question to you is: Do you think the industry is ready, having just now got up to speed with webservices and Service Oriented Architecture, to apply meta-data to our language? Although the benefits of making the semantic leap are real, is it realisitic in the near future?

My Presentation Brochure Detail Snippet

XML, as a describer and standardization of data and datatypes, are changing as we move in to a future where humans won’t be consuming data as much as other computers will. The Semantic web is about metadata, or “data about data” that tells computers what type of data it is, and it’s context. It is about a language for recording how the data relates to real world objects. This allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing.

For the insurance industry, this transformation can bring incredible advances and solutions to the problems we are experiencing as an industry that XML and webservices alone can’t solve, including managing large amounts of data and customer information. In the Semantic Web, for instance, we can know what products may interest a customer through relationships built from their CLUE reports and their preferences or send self-describing products to agents without any upfront setup. Most importantly, it can be used in data warehousing applications to allow insurance companies to create their own meaning from their customer data for better rating by deploying reasoning systems to determine what risks are related to what datasets deeper than ever before.

ACORD standards will play the lead in this, and companies that are adopting ACORD standards in managing their business communications now, especially using ACORD in their webservices, will have a lead in this advancement. ACORD can become “richer” when paired with RDF documents that not only enforce the standards, but describe them as well.

In my presentation, I will demonstrate the future value of deploying these reasoning systems, demonstrate the work I’ve done in developing reasoning systems for ACORD formatted data, demonstrate a sample using Firefox and MIT’s Piggy Bank plug-in (http://simile.mit.edu/piggy-bank/ ) of a future ACORD standard based website that will show a customer, the products they may like and the best rate; all from self-describing meta-data and without any code (only the data itself)

I work with MIT’s Semantic Web SIMILE (http://simile.mit.edu/) project as well as invented and run the opensource cl-semantic project (http://common-lisp.net/project/cl-semantic/ ) that uses Lisp to discover relationships between data for automatic processing and the realization of patterns, geared specifically towards insurance and other probability based businesses. I have also been involved in research creating a RDF version of the ACORD standards (the subset of Surety) to allow ACORD standards to be used in a Semantic Web demonstration. I am also an ACORD voting member of the Casualty/Surety working group and sub-groups underneath. I am well known in the industry for my work, and you can browse my referred and non-referred research papers from my website (http://www.brandonwerner.com).

As the year draws to a close, I realize I haven’t been conference jumping as much as I use to, but did want to draw attention to a few places I will be presenting sessions for. If you are attending, be sure to say hello. More information on times when it becomes available.

ACORD LOMA Insurance Systems Forum
May 20 - 22nd 2007
Lake Buena Vista, FL
My Session: Future of ACORD: Using Data Standards In The Semantic Web

IBM Rational Software Development Conference 2007
10-14 Jun 2007
Orlando, FL
My Session: Websphere Process Server and SOA For Insurance

IBM has just announced it’s release of the following tools:

• IBM Rational Software Architect
• IBM Rational Functional Tester
• IBM Rational Performance Tester

You can get a hold of these by going here. (developerWorks login required)

I will have my writeup of what I think here soon. As of this moment, the download servers are full and I’m getting a 44 error.

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