RE: [soa-rm] Status and Review

["Poulin, Michael" <Michael.Poulin@uk.fid-intl.com>]

Title: Status and Review

Hi Folks,

 

as I learnt from the last tele-conference call, not all section of version 0.3 are complete yet before April 23. I would like to comment on section 3 Business via Service View.

 

#1. Section 3.1, definition of Service mediator:

if accept mediator definition as a "participant", then given examples do confuse me. Based on the definition, a mediator (as a stakeholder) has to have an interest in the service state or in the outcome of service interaction.

 

In the example, service registry does not have an interest in the service state because registry concerns of meta-information, not of the state, and does not have an interest in the service interaction - obviously.

 

Then, it is unclear why an encrypting/filter service is a mediator - it is just a normal infrastructure service. BTW, we doe not address Service Infrastructure in the document (my initial guess was that mediator has to play such role. However, in this case it is, probably, an entity, not a participant).

 

Finally, a proxy broker is not a mediator even if it "actively stands" for a party, e.g. transforms messages - no interest in the service state, and it does not interest in the outcome of service interaction but rather in the transition in between services.

 

I think, that all examples are about Service Infrastructure while we need an example of participant that facilitates offering or the service itself. Registry do facilitate service offering, but due to our chain of definitions, it cannot be a participant. 

 

My proposal is to replace only one word in the definition - participant by entity  - in the definition, and all examples stay as are. 

 

 

#2. Section 3.5.3 Interactions as Joint Action & Section 3.5.5 Transactions and Exchanges Model: 

if a simple interaction between a service consumer and a service IS a joint action, then the definition of the Joint Action, which talks about two or more participants, leads to a confusion and mixture with a transaction.

 

If a Joint Action would be defined as an action involving the efforts of ONLY two participants, then a business transaction becomes a quite clear "chain" of joint actions. Otherwise, joint action allows for multiple participants and can easily replace a transaction - there is no differences between them any more.

 

Since we have a business transaction already, we do not need "more participants" in the definition of a Joint Action and can go with just two participants.

 

 

#3. Section 3.5.5 Transactions and Exchanges Model:

for the Business Process definition, I would like to propose to insert one word  - 'ordered' - and have: "... is a description of the"+ ordered +"tasks," because just 'tasks' do not constitute a process.

 

Since we have a Business Process, what prevents us from defining Business Service?

 

For last several years, known to me SOA community used to distinguish between process choreography and process orchestration. Why we promote one over another? The major differences between them is based on the principle of separation of concerns: order of possible interactions between participants is described in the orchestration while the means of each single interaction is described in the choreography.

 

In our definition of Process Choreography, the part "may take place between two [participants]" belongs to the commonly accepted meaning of choreography while the part "or more participants" belongs to the meaning of orchestration. In other words, none of the participants should know what next action to take (orchestration) neither how to participate in an action (choreography); they have to know their needs and capabilities only.

 

Thus, I propose to either define Process Orchestration ( scenario ) in addition to the Process Choreography, or remove the latter in full - in the same way as SOA RM did.

 

 

Kind regards,

Michael Poulin

Senior Solution Architect, EMF Solution Management

Fidelity Investments International

' +44-173-783-6038
* michael.poulin@uk.fid-intl.com 
@    http://www.fidelity.co.uk/

Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html

---

From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: 27 February 2008 18:48
To: soa-rm
Subject: [soa-rm] Status and Review

TC:

As many of you are aware, the SOA Reference Architecture Subcommittee has been working diligently for well over 18 months on developing a Reference Architecture based on the OASIS Reference Model for SOA.   I am happy to report that this work is nearing a 1.0 status as a Committee Draft (CD).  The Sub Committee will likely be ready to present this work to the larger RM list in order to submit it for a vote to become a CD, an important step on the road to becoming a full blown OASIS standard.

It is anticipated that the SOA RM TC will convene a meeting somewhere around April 23, 2008 to call for such a vote.  

If you wish to review the status of the work, please note that there is a lot of work outstanding on it (no comments requested at this time as the comment hopper is full).

ISO

There has also been a discussion about submitting the Reference Model for SOA to ISO.  There are steps and important things we all have to understand to complete this task.  This discussion needs to happen during a formal TC meeting.

We anticipate that a formal SOA RM call is required to meet the needs of the TC and SC.  I also want to ask, as Chair, for any other agenda items people might wish for such a meeting.

Duane

--
**********************************************************************
"Speaking only for myself"
Senior Technical Evangelist - Adobe Systems, Inc.
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************