Recently Steve Jones has published an article on his blog in which he states that "SOA makes great BPM, BPM makes crappy SOA". He argues that "BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective". This procedural and process view is a bad starting point, in his opinion, because it tends to see services equal to process steps, which results in "doing VISUAL Cobol and replacing function calls with service".
I agree with him that, if you just make each process step a service, you haven't got any clue about the meaning of a service. But in my opinion BPM can be a very good starting point for implementing a SOA! Of course some basic conditions are needed to make the process successful.
In a previous article, SOA and Human Interaction, I talked about BPEL4People and how it can support human interaction in SOA compliant systems. Now the specification v1.0 is presented. It consist of
Service-Oriented Architecture (SOA) has a lot of definitions. Some call it a management vision, others see it more as a system architecture concept. In the second one, a movement is seen pushed by technology vendors. In 2003 they talked just of web services, while by now the talk is of events and process engines. In this article I want to review a couple of the existing definitions and categorize them into one of the steps of the system realization process. I will conclude with a formal definition of how I see SOA.
In a previous post (Architecture, a definition) the key terms in the system realization process were clearly defined. We've seen that an Architecture is a set P of design principles, conforming to some Architecture Framework. Every p Î P
- concerns one system type s Î S.
- is a restriction of design freedom in one domain d Î D.
- accommodates one or more areas a Î A.
An Architecture Framework is defined as a tuple where:
- S is a set of system types.
- D is a set of design domains.
- A is a set of areas of concern.
So, an architecture framework defines categories in which principles should be defined. Each category is a tuple with s Î S, d Î D and a Î A. For each category a set of principles can be devised. The resulting set of principles is called an architecture. Now a couple of important issues arise including the following questions:
- What exactly are principles?
- How to define principles in a formal, unambiguous way?
In this article both questions will be answered.
For me (most of the time) SOA is a serious subject. Listening to vendor speeches and reading websites and white-papers often changes that for a moment (sorry, I can't help it). However, I stumbled upon something a lot more funny!
