Not often I blog on something quite so general and to keep your interest I do intend to do a major piece on SOA for business and management rather than just a the usual techie dimension. It just takes a while to get my thoughts in order to do it.
On a more general topic I have changed jobs. Having been an entrepreneur for the last 10 years I have decided that I wish to devote time and energy to doing what I can in a larger organisation but one that is fast enough moving that I can use my entrepreneurial skills in. To this end I am now working for Cognizant as the lead architect for their Advanced Solutions Practice in Europe. All very exciting stuff because these guys are really growing fast and that gives me a whole lot of problems based on methodology and technology support for it to focus on.
I'm still very much Pi4 Tech and still associated with Hattrick (non-exec on the board).
I'm looking forward to bringing the experiences from my new role at Cognizant into the blogsphere.
Monday 25 February 2008
Wednesday 13 February 2008
Workshop on Web services, business processes and infrastructure
I attended a really good workshop last week and thought that I should probably blog a bit about what it was all about. There were some really good presentations. To the authors of these, alas sorry I missed a couple so I cannot blog about those I missed. But here goes ....
There was lot on global models during the course of the two days and a lot on session types (these are the types that WS-CDL was based upon and provides a behavioral type checking facility to determine liveness properties - i.e. does it deadlock or livelock and so on).
Several papers stood out for me.
There was one from Andy Gordon on F# - a formally grounded language for encoding data centre run books, similar in intent to that used at one of my old companies Enigmatec Corporation Ltd. What Andy has done is formalise a language for managing data centre, which when you step back and think about managing such assets really does have to be precise so formalisation is really important.
There was one from Joshua Guttman on global models (using WS-CDL) and security. Great paper because it added contextual security based on process. Something I have longed to see but have never had the ammunition to consider.
There was one from Mark Little about distribution and scalability which was very enlightening and showed many of the issues that concern today's web based applications and what we need to focus on to describe and manage transactions in an unreliable context (see link to mark on my links).
There was one on Sock and Jolie from Claudio Guidi's and colleague. Sock being the formal model and Jolie and implementation that enables complex systems of services to be enacted using a curly brace language (Jolie). They gave a great demo too.
There were a couple on session-based languages that really stood out. The first was from on her work on OO Languages with session types and the second was from Ray Hu on Distributed Java. The latter, which I have seen before, added a few jars which abstract communication away. Coupled with what is akin to an interface in Java but is actually a session type documenting behavior between processes it provided really good session typing and checking to ensure things work correctly between processes. For me this fits the bill as regards language extensions to Java that make Java a good end-point language with a strng notion of contract.
One paper dealt with a topic very close to my heart which is how can we use a global model (aka WS-CDL) to find services that meet the necessary behavioral footprint expressed as roles in WS-CDL If we could do this then when we write down out SOA blueprint for both existing systems and extensions we wish to make we can ensure a higher degree of reuse, not just at a functional matching level but at a behavioral level. The work is by Mario Bravetti and I hope very much that we can get Mario involved in the Foundation to help us move this to a reality for many people.
On some more comerically oriented presentations there was one from Matthew Rawlings and one from Dave Frankel. These two dealt with the realities of modeling and documenting standards that are very complex. Matthew is well known as an Architect and deep thinker in financial services and Dave is well known as one of the key people behind UML
The final paper I wanted to mention was given by my long time colleague, Gary Brown. The Foundation which was started by Gary and I has moved on. WS-CDL is where it is but we embarked (well less me and much more Gary and Kohei Honda) on looking at how better to describe global models. And so Scribble was born. Gary presented Scribble and in particular showed a simple HelloWorld process and how it is represented in WS-CDL and in Scribble. Scribble was great! It is early days for Scribble and I am aware that Scribble will try to be compatible with WS-CDL (so don't wait) but it is so clearly the was to go and I look forward to using it when it has all been done.
Thanks to the organisers (Marco Carbone, Nobuko Yoshida and Kohei Honda). It was very stimulating indeed.
There was lot on global models during the course of the two days and a lot on session types (these are the types that WS-CDL was based upon and provides a behavioral type checking facility to determine liveness properties - i.e. does it deadlock or livelock and so on).
Several papers stood out for me.
There was one from Andy Gordon on F# - a formally grounded language for encoding data centre run books, similar in intent to that used at one of my old companies Enigmatec Corporation Ltd. What Andy has done is formalise a language for managing data centre, which when you step back and think about managing such assets really does have to be precise so formalisation is really important.
There was one from Joshua Guttman on global models (using WS-CDL) and security. Great paper because it added contextual security based on process. Something I have longed to see but have never had the ammunition to consider.
There was one from Mark Little about distribution and scalability which was very enlightening and showed many of the issues that concern today's web based applications and what we need to focus on to describe and manage transactions in an unreliable context (see link to mark on my links).
There was one on Sock and Jolie from Claudio Guidi's and colleague. Sock being the formal model and Jolie and implementation that enables complex systems of services to be enacted using a curly brace language (Jolie). They gave a great demo too.
There were a couple on session-based languages that really stood out. The first was from on her work on OO Languages with session types and the second was from Ray Hu on Distributed Java. The latter, which I have seen before, added a few jars which abstract communication away. Coupled with what is akin to an interface in Java but is actually a session type documenting behavior between processes it provided really good session typing and checking to ensure things work correctly between processes. For me this fits the bill as regards language extensions to Java that make Java a good end-point language with a strng notion of contract.
One paper dealt with a topic very close to my heart which is how can we use a global model (aka WS-CDL) to find services that meet the necessary behavioral footprint expressed as roles in WS-CDL If we could do this then when we write down out SOA blueprint for both existing systems and extensions we wish to make we can ensure a higher degree of reuse, not just at a functional matching level but at a behavioral level. The work is by Mario Bravetti and I hope very much that we can get Mario involved in the Foundation to help us move this to a reality for many people.
On some more comerically oriented presentations there was one from Matthew Rawlings and one from Dave Frankel. These two dealt with the realities of modeling and documenting standards that are very complex. Matthew is well known as an Architect and deep thinker in financial services and Dave is well known as one of the key people behind UML
The final paper I wanted to mention was given by my long time colleague, Gary Brown. The Foundation which was started by Gary and I has moved on. WS-CDL is where it is but we embarked (well less me and much more Gary and Kohei Honda) on looking at how better to describe global models. And so Scribble was born. Gary presented Scribble and in particular showed a simple HelloWorld process and how it is represented in WS-CDL and in Scribble. Scribble was great! It is early days for Scribble and I am aware that Scribble will try to be compatible with WS-CDL (so don't wait) but it is so clearly the was to go and I look forward to using it when it has all been done.
Thanks to the organisers (Marco Carbone, Nobuko Yoshida and Kohei Honda). It was very stimulating indeed.
Wednesday 6 February 2008
Orchestration and Choreography, WS-BPEL and WS-CDL
I am somewhat compelled to write on the topic of WS-BPEL and WS-CDL. This is a topic that has surrounded the development of WS-CDL since it's inception and alas there has been a great deal of myth making in the telling of the story by large vendors and analysts alike. For those that are interested and of open mind I hope this helps position the two.
Rather than trawl back through history I shall focus forward and look at problems and solutions instead as I think these are much more important than the politics of standardisation and the great debate of orchestration vs choreography.
Fundamentally it is all about abstraction and expression. Since the days of Alan Turing and Alonso Church computer science has looked at higher and higher levels of abstraction in which all that went before can be incorporated in some way with what is on offer. We see the demise of assembler and the rise of structured programming languages. We see the demise of structured programming languages and the rise of object-oriented languages - now of course I egg it up and many of the older languages are still used and are very useful but I play to the main gallery in this particular blog.
Abstraction that is well founded (and so has some formal underpinnings) is a very useful concept in academia and one might be forgiven in thinking what benefit does this bring to business. Generally it boils down to two things. Firstly as the level of abstraction increases (and yet the expression remains the same) so the speed of delivery of an executable increases
This was the true with the move from C to C++ and then to Java and C#. As the level of abstraction rises so the gap between the requirements and the solution becomes smaller and in this way the alignment of solution to requirements or as is often said IT to business becomes cleaner and crisper. The message is that abstraction really does matter and really does impact business and is not just an academic nicety,
So where does this fit with WS-BPEL and WS-CDL. After all you probably think that they are the same. If you look at what they do and how they do it and how they describe things you will very quickly understand that the levels of abstraction they deal in are different. If you imagine wanting to build a car and you go out and select all of the tools and technology to do so it might at the high end look a little similar in abstraction to WS-BPEL. A bunch of parts that are delivered as units that are orchestrated into ever higher units which are orchestrated and delivered as a service. If you wanted to build a motorway (interstate highway) system you would not use the same tools and technologies that you use to build cars. Road systems are not orchestrated, rather they have some rules that govern them but they essentially acts as channels between peers (roads between cities or towns or villages). WS-CDL describes interactions between peers without describing how those peers do their business internally. It described a blueprint of communication. WS-BPEL simply does not describe what WS-CDL does and WS-CDL does n ot describe what WS-BPEL does. They are tools for different purposes. Just like cars and roads they are complimentary. Obviously you can drive a car off road. You can use WS-BPEL without WS-CDL. Obviously you can use a road without a car and so WS-CDL can be used without WS-BPEL. But magic stuff happens when roads and cars come together just like WS-CDL and WS-BPEL.
Now the tools we actually use for building cars can be used to build roads. We could use a spanner and hammer and a screw driver to help dig. But it makes more sense to use a spade or digger. And this is the point. We can all use assembler still but for the most part we choose not to because the level of abstraction does not match the problem we try to solve.
At this point I want to look to others to support the differences and the complementary nature of the WS-BPEL and WS-CDL. Here are two interesting takes on it.
A recent report from Burton group stated:
Rather than trawl back through history I shall focus forward and look at problems and solutions instead as I think these are much more important than the politics of standardisation and the great debate of orchestration vs choreography.
Fundamentally it is all about abstraction and expression. Since the days of Alan Turing and Alonso Church computer science has looked at higher and higher levels of abstraction in which all that went before can be incorporated in some way with what is on offer. We see the demise of assembler and the rise of structured programming languages. We see the demise of structured programming languages and the rise of object-oriented languages - now of course I egg it up and many of the older languages are still used and are very useful but I play to the main gallery in this particular blog.
Abstraction that is well founded (and so has some formal underpinnings) is a very useful concept in academia and one might be forgiven in thinking what benefit does this bring to business. Generally it boils down to two things. Firstly as the level of abstraction increases (and yet the expression remains the same) so the speed of delivery of an executable increases
This was the true with the move from C to C++ and then to Java and C#. As the level of abstraction rises so the gap between the requirements and the solution becomes smaller and in this way the alignment of solution to requirements or as is often said IT to business becomes cleaner and crisper. The message is that abstraction really does matter and really does impact business and is not just an academic nicety,
So where does this fit with WS-BPEL and WS-CDL. After all you probably think that they are the same. If you look at what they do and how they do it and how they describe things you will very quickly understand that the levels of abstraction they deal in are different. If you imagine wanting to build a car and you go out and select all of the tools and technology to do so it might at the high end look a little similar in abstraction to WS-BPEL. A bunch of parts that are delivered as units that are orchestrated into ever higher units which are orchestrated and delivered as a service. If you wanted to build a motorway (interstate highway) system you would not use the same tools and technologies that you use to build cars. Road systems are not orchestrated, rather they have some rules that govern them but they essentially acts as channels between peers (roads between cities or towns or villages). WS-CDL describes interactions between peers without describing how those peers do their business internally. It described a blueprint of communication. WS-BPEL simply does not describe what WS-CDL does and WS-CDL does n ot describe what WS-BPEL does. They are tools for different purposes. Just like cars and roads they are complimentary. Obviously you can drive a car off road. You can use WS-BPEL without WS-CDL. Obviously you can use a road without a car and so WS-CDL can be used without WS-BPEL. But magic stuff happens when roads and cars come together just like WS-CDL and WS-BPEL.
Now the tools we actually use for building cars can be used to build roads. We could use a spanner and hammer and a screw driver to help dig. But it makes more sense to use a spade or digger. And this is the point. We can all use assembler still but for the most part we choose not to because the level of abstraction does not match the problem we try to solve.
At this point I want to look to others to support the differences and the complementary nature of the WS-BPEL and WS-CDL. Here are two interesting takes on it.
A recent report from Burton group stated:
"Right now developers working on complex service-oriented architecture implementations face a Hobson's choice between an existing standard that doesn't meet their needs and an emerging standard that they can't use yet, according to a Burton Group report released this week."
and went on to say,...
"Despite its limitations, Howard sees BPEL with its vendor tools support continuing to play a role in SOA development. Eventually, however, BPEL sub-processes will play a subordinate role in the larger choreography and WS-CDL with vendor support will be the big picture standard."
Others, in response to the above said
"I think it is out of confusion that people get hung up on the equality of BPEL and WS-CDL. They address very different perspectives in a service-oriented approach (i.e. orchestration and choreography). Therefore to say BPEL is limited, is true if you are considering choreography but not so if you take what it aims to fulfil - orchestration, the executable process. Let us move on, and stick with the fact that they complement each other..."
So I am not alone in thinking that WS-CDL is important and I am not alone in thinking that WS-CDL worked or could work rather well with WS-BPEL and that they are in fact different beasts doing different jobs which themselves are complementary.
If you are still not convinced then let me point you to an example in WS-CDL and see if you can encode the same example in WS-BPEL as efficiently. You can certainly create systems using just WS-BPEL but the problem is that as soon as you need to deliver more than one service collaboration is needed and this is where WS-CDL works well. If you try to solve collaborative service problems using WS-BPEL you will find that the complexity and subsequent management starts to impinge on success. You will end up with many moving parts (one WS-BPEL per service and one set of partner links to each service that talks to another and so on) and many files. With WS-CDL you will end up with one file for the collaboration and can use this to generate the necessary WS-BPEL files ensuring that they all match up. Doing it without WS-CDL you will be forced to match all of the WS-BPEL files by hand - time consuming and error prone.
As one well known computational scientist once said (Jon Bentley's Programming Pearls) "I'd rather write programs to write programs", the very essence of abstraction.
And as John Koisch (HL7) told me today WS-BPEL is a very good white box service language and WS-CDL is a very good black box system language.
It really is akin to the difference between assembler and say Java. You can do it, but should you do it that way when better ways exist that will help you deliver faster and with a greater quality of result.
I would welcome further comments.
If you are still not convinced then let me point you to an example in WS-CDL and see if you can encode the same example in WS-BPEL as efficiently. You can certainly create systems using just WS-BPEL but the problem is that as soon as you need to deliver more than one service collaboration is needed and this is where WS-CDL works well. If you try to solve collaborative service problems using WS-BPEL you will find that the complexity and subsequent management starts to impinge on success. You will end up with many moving parts (one WS-BPEL per service and one set of partner links to each service that talks to another and so on) and many files. With WS-CDL you will end up with one file for the collaboration and can use this to generate the necessary WS-BPEL files ensuring that they all match up. Doing it without WS-CDL you will be forced to match all of the WS-BPEL files by hand - time consuming and error prone.
As one well known computational scientist once said (Jon Bentley's Programming Pearls) "I'd rather write programs to write programs", the very essence of abstraction.
And as John Koisch (HL7) told me today WS-BPEL is a very good white box service language and WS-CDL is a very good black box system language.
It really is akin to the difference between assembler and say Java. You can do it, but should you do it that way when better ways exist that will help you deliver faster and with a greater quality of result.
I would welcome further comments.
Subscribe to:
Posts (Atom)