THE SOFTWARE SIMPLIST

Web Services Wisdom.

May 2007

So many gems in Steve Jones' recent post SOA isn't about technology.

business process isn't everything.

one interface = one process = what a load of crap interfaces you have.

... with "services exposing legacy and BPM orchestrating services". Its pretty amazing how this view just happens to match the product vendors stacks...

Its bollocks

BPM as the language of business is, IMO, snakeoil.

Starting with BPM is as silly as starting with WSDL.

I've talked about the BPM, SOA divide in this podcast, but from a more solutions architecture perspective. As well as this podcast on "Services as the interface to business processes".

The main problem I have with BPM is that there's this expectation that the steps of each process will actually be implemented the way that they were drawn. The way the business views its processes is, first of all, much different from the way the BPM analysts do. Second of all, who said these analysts have the ability to design systems that will be functionally correct, reliable, scalable, and all that. So, why in the name of X are we giving them tools to automate that? Software architects don't even have these kinds of tools, although they do have the requisite knowledge.

I'm with Steve. Bollocks!

Posted by Udi Dahan at 05:00 PM  Permalink |

Willam Brogden has an article up on SearchWebServices.com on How Web Services can use JavaSpaces. I don't want all the Microsoft folks tuning out now that they've heard the "J" word, so let me just say that there are technologies out there for .NET too.

A "JavaSpace" is really just a space, which is, at the end of the day, a queryable distributed in-memory hashtable. Something many of us are already doing for caching. The reason you shouldn't be doing this yourself is simple. While keeping a single hashtable in memory on a single computer and synchronizing it against changes to your database is simple, doing that in a highly available manner across multiple servers is not. Vendors providing solutions in this space include:

• Gigaspaces
• IBM ObjectGrid
• Alachisoft's NCache
• GemStone
• Tangosol's Coherence

But there are others as well. Bottom line: don't develop one of your own. Do a proof of concept with your short list of vendors and go from there.

The article sums it up nicely like this:

Although JavaSpaces servers are not trivial to set up, they are much easier than any other type of grid computing server. Furthermore, the simplicity of the interface makes the learning curve easier. The greatest advantage of the JavaSpaces approach is the ease with which additional workers can be added to the grid.

It should be clear from the example that there is a lot of extra communication traffic in a JavaSpaces solution so the only reason to use JavaSpaces or any other form of grid computing in support of a Web service is a requirement for computing power or special resources that are not feasible to supply on the server directly.

I have this to add to it. Whereas most traditional systems keep the idea of message-based communication and data caching separate, spaces allow you to kill two birds with one stone. Even if you don't go the whole Space-Based Architecture route, you'll find that spaces will fit nicely in your distributed architecture toolkit - I know I did.

Posted by Udi Dahan at 04:19 AM  Permalink |

Roger Wolter, who is trying to evangelize the architectural aspects of data in SOA, has this to say:

After all, you don’t have to go too far down the SOA path before you realize that unless you build reliable, asynchronous, loosely-coupled services, your SOA architecture is going to have serious reliability problems and Service Broker brought reliable, transactional messaging to a whole new level of reliability and efficiency. What I found was a bunch of architects trying to figure out how to use WS-Transactions to build tightly coupled services to replace their tightly coupled objects.

So far, I’m thrilled that he is pushing this message in, and out of, Microsoft.

He then goes on to debunk the idea of Entity Services:

I next ran into a lot of people architecting SOA systems to provide a common services interface to a lot of diverse back-end systems. I’ve talked to people who had over 100 systems that handle customer data for example. If you build a perfect customer service to wrap all these systems with a common schema for the customer record you have a single view of the customer right? The first time your user tries to change the phone number for Acme Rockets Inc. and gets back 80 records which may or may not be for the same customer, the single view of the customer loses some of its appeal.

I’m loving it.

He then suggests a solution:

That’s how I got interested in Master Data Management. I really believe that accurate, unambiguous clean data is a prerequisite to an SOA project.

Hmm, from what I’ve seen of MDM, it puts a different spin on all the other things he said above.

Other than that, I’m totally with him. A deep understanding of data is necessary to get a good service decomposition. Without understanding the transactional nature of that data, you just might end up back tightly coupled and with a monolithic web service mess.

Whether or not you use Microsoft’s SQL Server Service Broker, Roger is definitely a guy worth listening to.

Also, check out this podcast on Master Data Management & SOA for more information.

Posted by Udi Dahan at 05:49 PM  Permalink |

Thanks again Udi for your informative response. I have been having more and more continued success leveraging service oriented design principals in my work. My client is thrilled with the result - systems that work and are agile! :) Your advice over the last number of months has been a big ingredient in that success.

As per usual, I have another question I was hoping I could trouble you with. I have a service which needs to subscribe to a topic which is a parent topic in a topic hierarchy.

Say I have 3 different families of insurance products, each of which have a "Policy Written" event. So we would have:

Product Family 1 Policy Written
Product Family 2 Policy Written
Product Family 3 Policy Written

These 3 messages have some information in common - such as Policy Number, Product Code, Date Written, etc. I'd like to be able to add more products with their own unique "Policy Written" event, without altering the service subscribing to the "Policy Written" topics. This means that the subscribing service would need to know about the "Policy Written" base type of message, without knowing about the specific sub types. Assuming the messages are serialised using SOAP/XML, would you recommend achieving his using XML data type inheritance? So each of the message sub types would inherit from a message base type? Or would you recommend just having the subscribing service understand each message sub type, and update it as new sub types are added? Or is there another solution you could offer?

I can see that having the base message type increases coupling between publishing services because each service that publishes a Policy Written event must adhere to the base message type schema. But I can also see having the subscribing service understand all message sub types increases coupling between the subscribing service and the publishing services because adding a new insurance product requires modifying the subscribing service to understand the new message sub type.

Regards,
Bill

Posted by Udi Dahan at 09:06 AM  Permalink |