Buna Ziua,
I could finally correct the problems with the animation in YouTube, then I can continue pouring the entries that were in the waiting queue. I promise I’ll update as quick as possible.
Having introduced the notion of orchestration in the last entry, we can get into deeper, fuzzier waters. Orchestration is as natural as vast, and many architects have created different solutions for the last 20 years. Nowadays there are standards, but so many and wrapped with so much marketing hype, that the subject is pervasive but remains dim, secluded. I illustrate here what I have succeeded to decode.
How to identify an orchestrator? it corresponds to the normal transfer of information that is present in the business process. This transfer is so fundamental that it is invisible in many organizations.
Let us imagine that your organization you has implemented paper-based processes 
. I know, I know. I don’t mean to abuse you but I am forced to create a horror scenario 
.
If this was the case, then customers (internal/external) should fill forms in order to ask for a service 
. Just imagine 
For example, if you as employee want a new 24″ screen 
, you may be forced to fill a form to ask for that new screen 
. This paper-form should pass through the desk of your boss 
for a signature. Let us dream that your boss is happy with your request 
because your screen is more than 6 months old
Once she happily accepts, this form should go to some budget office. Let us imagine –then– that yours & some other requests are put together in a package that corresponds to the IT purchasings. To make things worse, assume that there is some person in the organization that should look at your request, ask for a few providers and examine their proposals, check them out once more with your boss or you, and then put it on the binder of the accepted & budgeted purchases. 
Ufff! Let us suppose that this binder arrives to the financial department, and that they will do the actual transaction.
In order to finish the BP, imagine that the provider receives and order (whose copy goes to your file binder) and that once the screen is sent, the bill will arrive to the accounting dpt. Someone over there will eventually pass it to treasury, that will do an –imaginary– payment to the provider.
Let us even imagine 
that your request has steadily grown to become a pile of paper forms with signatures from each person that has seen it, checked it up, approved or rejected it + photocopies of specifications/ bids/ offers/ contracts. Of course, in a theoretical scenario like this, one could yet imagine that copies of documents should be produced & sent to different sections of the organization
Of course, this is only fiction. Things like those cannot occur in real life
In order to avoid this Dantesque scenario, the wise management guys introduce an orchestrator. The orchestrator should replace the paper forms & binders. Not every single document, as most documents should be stored in a file for compliance requirements; such archive should be now performed in a digital format via a DMS (Document Management System — in french: GED) .
The orchestrator will require only the data that should be stored in order to satisfy the needs of future stages of the business process.
- For instance, the requester ID should be kept from the beginning because @ the end, the screen should be delivered to the requester (you
). - Another example are the price and quantity of items that will be purchased, since this information will affect the financial information that is used for creating a budget, then to place the order, and finally to check the bill before issuing the corresponding payment.
Seen like this, any solution that can help us retransmit the informations to the services is good for the work. Be cautious with this kind of wild-, first-hand-, easily-sold, profusely-documented perspective of SOA. If you follow this simplistic analysis, then there is the danger to consider that workflow systems, ESB, Web-Services, CORBA, and any other EAI approach and technique are almost synonymous. They are very different things, specially when considering how the CRUD is split among the layers and the process’ stages, and when the persistence and the use of XML are analyzed in detail. Not to talk about BPM.
We will discuss those differences later on. Please try to think of what are the differences when:
- the orchestrator is implemented in such a way that all the information should pass through every process down the stream, against
- an orchestrator that sends to each process only the information that the specific process needs to perform its work
This reflection time will give you the first hints towards a classification. Please consider also the fact that most approaches mentioned above do not take into consideration the interactions of people during the process 
They assume that most information processing (transfers + services) is done automatically
This cannot be realistic in our scenario . Just give it a last thought. Then, try to sleep… if you can 
Hasta luego!
