Contract first for BPEL

Okay so I've started having a play with the new BPEL 2.0 tools from Eclipse and Netbeans, and the phrase early alpha certain comes to mind! But it is good to see that the two places where we are seeing these modellers is in the Open Source arena, and they are being developed by people who really know what they are talking about, Edwin over at Oracle in Eclipse and Charles (and Todd) over at Sun doing Netbeans.... it does make me wonder what they could produce together though.

Any how, one of the things that was annoying me is that I've become a big fan of doing contracts early on in projects. This is an incredibly new and trendy approach, designing and defining the contracts before you actually start future development, its so new and trendy that there is a paper called "Design by Contract" that was.... errr written in the early 90s. Don't you love it when people think they've discovered the holy grail that everyone has been missing for all these years? So anyway its a good practice, design the interface, in otherwords the WSDL which should have the operations and the datatypes, but unfortunately unlike Eiffel, the programming language from the guy who wrote Design by Contract, we can't define the formal contract very easily.

So anyway lets suppose that we have a new service doing Campaign Management, its a simple service that aims to automate the links between existing systems and facilitate the approval, release and withdrawl processes. So first off we define the WSDL.... which I won't cut and paste but here is the picture.

Now this is where we have the first set of problems with the current BPEL tools... I can't start with a WSDL. This is plainly rubbish and there really isn't a very big reason for it. So that is the first request: I want to be able to start from a WSDL then implement with BPEL.

Now this leads straight into problem number two. One BPEL = One WSDL but this isn't what makes sense from a services perspective, my CampaignService needs to deliver five capabilities, so I need five BPEL = one WSDL. This makes partner links easier to handle and by grouping these elements together you reduce the complexity and the clutter and provide consistency between your BPEL and non-BPEL implementations (lets face it if you had to deliver this WSDL in C# or Java you really wouldn't be looking to do it in five different classes. This separation of BPEL implemented things from OO implemented things forces more information onto the consumer that they just don't want to know about

This also helps you when you are build the BPEL as you can clearly identify calls to related elements (CampaignManagement) and calls to external things (IdentityManagement), and in the actual BPEL itself it makes no difference whatsoever as partner links are just calls to a WSDL anyway.

So here we have the two processes, one of which (create) calls the other (approve) to deliver on the capabilities of the service.

From a design, development, management, publication and versioning perspective it makes it much easier if you can have a single WSDL to describe what the service should be. Implementation languages like BPEL shouldn't be forcing us to break our service architectures because they can't cope with the idea of a service providing access to multiple capabilities. Which is the reason I raise the enhancement request to the Eclipse BPEL project. It would be fantastic if good practices like Design by Contract could be applied to all types of Web Service implementations, and not just the ones being built in OO langauges. If BPEL really wants to play well in the SOA world then its implementors need to start thinking of the service question rather than the process one.

Technorati Tags: SOA, BPEL, Service Architecture