LiteBytes from Lustratus Research

SOA for the scientific community - a practical example

I was intrigued to discover a discussion paper from the University of Southampton in the UK about how SOA is helping the scientific community. The paper, entitled 'A Collaborative Orthopaedic Research Environment', describes how SOA has been used to enable a Virtual Research Environment for orthopaedic researchers to collaborate in the design, analysis and dissemination of experiments.

What I found most interesting were the reasons for using SOA as the base architecture for this environment. The key objective, based on input from the specialists who will use the system, was to provide an easy way to share scientific data and results from collaborative research. However, it was deemed essential that the system could also evolve based on the changing requirements of the user community. One example of change that the paper gives is that of knowing which of a wide range of protocols will be followed for a particular clinical trial. Not only do these vary considerably, but it appears they are also susceptible to changes in regulations.

The solution decided to utilize a coarse level of services, essentially using just four - to manage the trial-related data, analyse it, submit and disseminate related research articles and support discussion forums. However, through the reliance on SOA, these services are flexible and extensible, making it much easier to address the changing needs of this particular scientific discipline. In addition, the services are reusable, and some could therefore be usable for other scientific areas.

It's good to see SOA being used to effectively address clear user needs in this way.

Steve

BPEL4People: mad or not mad?

I have a lot of sympathy with Steve’s blog item on the WS-madness:  Vendors will sometimes (inevitably) cynically use standards only for differentiation, standard bodies and the professional standard writers will do what they are paid to do: write standards.  And finally end-users are too disengaged to make sure the standards solve the problems they want solved.  All of which was going through my mind when I was reading the recently published BPEL4People standard:  Is BPEL4People just another piece of WS-madness?  (BPEL4People is an extension of WS-BPEL to handle human involvement in business process modelling and execution.  BPEL is the WS specification for defining business processes.)

To answer my question, I came up with the following simple sanity test (which many WS-standards fail):

1. Does it address problems that users have today or reasonably expect to have tomorrow?

2. Is it the unique standard in addressing the problem?  Anybody following of the web services standards around reliable messaging will remember the complete mess caused by multiple competing standards( WS-reliable messaging and WS-reliability).

3. Is anybody actually going to implement it?  There are too many standards both WS and previous which are never quite implemented.

In fact, BPEL has itself struggled to pass the three tests for sanity:  While business processes sound all pervasive, BPEL addresses only a subset of all business processes:  Those which have a central controller (i.e. not peer-to-peer collaborative processes which are covered by another standard), where the central controller is in the middleware (i.e. not controlled within your SAP application).  It has also been heavily criticised by BPM specialists who prefer more formalism than BPEL attempts to provide.  Therefore, it struggles to pass points 1 and 2.  These limitations have meant that many users are slow to adopt BPEL and are sometimes happy to stick with non-standard approaches with better capabilities.  All of which led to vendors delaying implementing BPEL for a number of years - which is point 3.  (However, I believe that BPEL does now make the sanity benchmark for those who need it and on that basis would have to disagree with Steve’s exclusion of its from his sane list.)

Turning to BPEL4People, the intention of the standard is to create a “BPEL extension to address human interactions in BPEL as a first-class citizen“.  To put it another way, it attempts to tie human-workflow back into the BPEL standard which is mostly used for system to system workflow (or business process flow if you prefer).  This means that BPEL4People contains concepts such as human roles, groups and tasks.

Returning to my sanity tests:  On the first test, BPEL4People certainly addresses a problem I have seen where some human interaction is required in a system-to-system business process.  It is a subset of the set of users of BPEL itself – maybe less than 50% of all BPEL use cases. 

A bigger criticism is at point 2:  You could (and many have) solved the problem BPEL4People addresses with BPEL on its own.  Yes BPEL4People provides standards where people made it up as they went along but it is not clear that the overhead of a new standard justifies its creation.  Finally, is it going to be implemented:  On the face of it, SAP, BEA, Oracle and IBM’s backing makes it a simple answer: “Yes”.  We will have to see.

All of which means that for the moment BPEL4People scrapes a bare pass on the sanity test:  If you are sure that your problem domain needs this type of functionality I recommend watching how implementations develop and planning on transitioning to BPEL4People when they are mature.  Otherwise, you already have standards and solutions capable of muddling through with.

Ronan

WS-Madness

OK, I think it is time to stop all the WS-Madness. Web services standards have become a complete joke. As far as I can see, there are now at least 70 (seventy) web services standards and drafts - more than anyone could humanly want, and enough to create chaos, and completely negate the advantages of standards in the first place. Standards are supposed to increase choice, but with so many the likelihood is it will actually REDUCE choice (do you support standards 27, 39 and 40? no, I support 23, 42 and 63 though, any good?).

So, who is to blame for this debacle? Well, the blame is pretty evenly spread. Perhaps the most obvious target is the vendors, who have unashamedly used WS standards as a battleground to try to create differentiation from competition. So, by creating a standard that fits in with ones own design, it is then possible to use this as a reason for rejecting other players. However, vendors are easy targets - but are they really the villains here? After all, you could argue that they are just doing what they have to do - trying to compete, to win business and pay their employees / shareholders. The next obvious choice is the standards bodies themselves. Sadly, there are many 'professional' standards body members who get intellectual kudos from defining standards - whether they are worth anything or not. But even this may be missing the point.

Perhaps, instead, blame should be turned on users. The vendors have stepped in because of two things - the opportunity created by the desire for standards in the SOA space, and the vacuum resulting from the failure of users to take an active role. Similarly, standards bodies have leapt into the void because in a way they have to generate standards to have any worth in the world. But the real accusation is that the standards are rubbish - most are immature, many are useless or pedantic. In other words, they do not add value for SOA users and implementers. And isn't this a case of users getting what they asked for? If users don't want to get involved to ensure the RIGHT standards are created, that really mean something to users, then they cannot complain when others jump in to fill the vacuum.

My advice to users on web services standards is to ignore all but the important ones - SOAP, WSDL, WS-Security, and maybe WS-Addressing although this is not as mature as the other three. Then take a more active role to ensure these standards mature into what you actually NEED.

Steve