When designing a corporate SOA architecture you are often faced with a tough choice: do you rely on a common database (centralized) or do you implement replication instead?

Let me explain what I mean. The idea in SOA is that you define more or less independent services that correspond (hopefully) to clearly defined and business-related activities. For instance, you could have a customer management service and a payment/invoicing service. The customer management service belongs to CRM, the invoicing to the billing department. However, both of these services might need the same customer data. Now what do you do? Basically, you have the following options:

1. Use the same centralized customer database. This gives you the benefit of easy maintenance because there is only one copy. However, this also means that you are coupling your services into the same database schema, and updates to the schema are likely to affect more than one service.
2. Replicate the customer database, by identifying one master (the CRM?) that regularly pushes or publishes updates (in an XML feed, for instance). While you lose the benefit of easy maintenance, this does give you loose coupling: as long as the XML format is the same, you can change DBMS schemas as much as you like - without affecting other services.
3. Merge the customer and invoicing services into one. However, this may not always be possible or desirable, and may even defeat the purpose of service-oritentation altogether.
4. Have the invoicing query the customer service for each payment. Thi seems to incur a lot of dependencies and network traffic.

So what do you do? My preference tends to go to the second option. However, it means that realistic SOA architectures are likely to have an event-driven nature.

I have been waiting for ages to see web services get ready for SOA. Recently, hinted by a customer, I (re)discovered JINI. What that moment was like? Well, looking at JINI (in combination with JavaSpaces) I saw a dynamic lookup platform based on interfaces (read: capabilities - not names) and with scalability, self-healing characteristics and the performance of RMI. Javaspaces even adds the best of messaging and asynchrony. It sounds too good to be true.

To be continued…

For my Javapolis 2006 talk I decided to have a closer look at the WS-BA specification (then still in draft) and its relationship to BPEL 2.0 (then also still in draft). While I was at it, I also decided to use the committee's minutes to clarify any remaining questions I had. This exercise took me a few days but the result made clear that the WS-BA protocol has serious limitations that make it not so useful as it could be:

The WS-BA protocol is almost entirely modeled after BPEL. WS-BA participants map one-to-one to BPEL compensation scopes. Because BPEL doesn't provide close handlers, neither does the WS-BA protocol allow application logic on close. The implication? If you model your services as WS-BA services then you remain 'in-doubt' about every service invocation (in theory, the WS-BA close event would notify you that the deal is closed, but you're not supposed to do business logic in that callback so it might as well not be there).

To give an example: if you are an airline and want to use WS-BA to make seat reservations transactional then you would never know whether any reservation needs to be canceled or not. More precisely: it will always be possible for any of your current reservations to be compensated at some later time.

The bottom line for you as a service provider: compensation is always possible. The consequence is far-reaching: how do you produce sales reports? You can't, unless you accept that you are dealing with temporary data (that may later be compensated for). Every single sale you made can theoretically still be compensated.

Fortunately, WS-BA and BPEL allow you to model compensation as something that costs to the customer, so your sales reports may not suffer that much from compensation after all. But this leads us to another problem I have with WS-BA/BPEL: if you model compensation as something that leaves tangible effects (costs?) for the customer then what good is it for me to have that kind of transactional guarantee? After all, BPEL also says that compensation can be triggered by the failure of a parent task. So my customer may have to pay for my service just because some intermediary task has failed! I am not sure if it is just me, but I think this is a big problem.

One more point I have to make about WS-BA is that it appears polluted with workflow messages that don't really contribute to the purpose of an agreed outcome across services. For instance, the 'Completed' message seems to be there just to indicate whether a participating service should be canceled (leave no effects) or compensated. But like I argued before, cancelation can still lead to compensation somewhere down the call stack so this is an utterly useless protocol message anyway. It only makes sense in the context of BPEL. And since BPEL is workflow, WS-BA is a workflow protocol and not a transaction termination protocol. In terms of efficiency it isn't exactly very good either: there are too many unnecessary message rounds involved. It could all have been much simpler.

My advice: use the Atomikos TCC (Try-Confirm/Cancel) paradigm if you want really reliable and compensation-based web services. It is faster, better and leads to real business-level consistency across service invocations. You will at least know that your sales reports are permanent and correct, and your customers won't pay for failed business transactions.

…and not something you buy!

If you only remember one thing from the BEJUG workshop on SOA then it should be this. And if you didn't go to this workshop: make sure you can go next time, because it was worth it:-)

But seriously, all too often do people buy a product and then start to look at how to use it, say, to build a SOA (Service Oriented Architecture). This is like buying a car: would you get a rolls royce first, and then pick the road to drive it on? Or would you rather look at the road first, and then choose the best car for it? I would do the latter…

Best

Did you hear about Spring? In my opinion, it is going to play a big role in J2EE and simplifying Java programming. At least when it comes to transactional applications, things are much simpler than with EJB.

Have a look for yourself: TSS was kind enough to publish my presentation on Spring.