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
*
@
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:]
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
**********************************************************************
