Goran:
I slightly disagree with your assertions,
probably based on semantics. For a service to “participate”
in a process, it would have to be aware of the process (which many will not
be). A better way to depict this may be to state “services may be
aggregated and used by processes” and “processes may be
represented/exposed as services”. There are really no limits to the
number of layers that can be present. Attached is a UML CVD depicting
such.
A key rationale of why process is not part
of SOA is that services cannot see process. They are not aware of whether
they are being called as part of a process vs. as an individual service. If
the “s” part of SOA cannot see or touch that, it cannot be part of
the RM.
The chicken and egg discussion you bring
forward is a requirement for those building services to strongly consider the
business process when designing their service infrastructure. Accordingly,
it is not really part of the RM for SOA yet I agree that it is a very important
consideration.
For your messages to get to the list, you
must join as a “applicant” rather than an “observer” as
per OASIS process.
Duane
*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************
From: Goran Zugic
[mailto:]
Sent: Monday, December 05, 2005
8:47 PM
To: Duane Nickull; Matt MacKenzie;
MATHEWS, Tim; Sally St. Amand;
Cc:
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
Duane,
Thanks for the response. Yes I would like to see the PPT. I
hope you do not mind if I add few more thoughts related to services and
business processes:
Services participate in a business process to add
some value to it. They can be governed and evaluated using business process
metrics. One service can participate in many business processes and provide
value to each of them according to the context within that process. As far as
SOA is concerned it is as important to know what the service does, how it can
be discovered, contacted, invoked, executed, etc. as it is to be able to
use it within the process context, measure it and assess its value from the
business process requirements point of view. SOA needs to avoid typical new
technology chicken and egg syndrome, e.g. companies not producing services
because there are no service friendly process definitions to use
them and not having SOA friendly process definitions because there
are no services to use. Services do not have to know if they will be involved
in the process upfront, they will be contacted on demand according to the
process script that is in effect, and they will be contacted, checked if available,
passed the arguments, collected the response and according to their procedure
left alone to wait for another call. The process execution engine however needs
to invoke the service according to both service specific information and the
process specific information.
Having just the service specific information in a model
covers only one part of the picture and I think it is fine as long as that
model is a pure service model. However I find it difficult to understand
that the SOA RM TC model is a SOA reference model when it does not
include other concepts of SOA. Unfortunately it seems that we cannot get to the
point where we could agree on a minimal set of supported SOA concepts by a
model to be the SOA
RM. We do not have
to and I do not want to argue with you or anybody else in SOA RM TC. I am just
trying to see how our works can fit together in a most efficient way. We
obviously need more time to better understand each others thoughts and ideas
and I strongly believe that a constructive respectable discussion is helpful
for everybody.
By the way, do you know what I am supposed to do to get
my messages to the SOA RM list. In spite of that I am the SOA RM TC
observer I get a faliure notice whenever I send a note to the SOA RM.
Goran
----- Original Message -----
From: Duane Nickull
To: Matt MacKenzie ;
; MATHEWS, Tim ;
Sally
St. Amand ;
Cc:
Sent: Monday, December
05, 2005 5:02 PM
Subject: RE: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
Goran:
The service layer enables the process
layer over top of it, however during runtime, services do not know if they are
part of a process or being called individually (it would generally be a bad
idea to try to maintain the overall state of a process within each service,
although it could be done). For maximum repurposing of services, it would
be better to have the service as a simple slave to the processes that may use
it.
Accordingly, we made a decision that BPM,
Orchestration, choreography is not a core part of the RM for SOA. We
generally seem to agree that many SOA implementations will include a layer of
BPM over top. We are only addressing the SOA model, not the model for the
underlying or overarching layers.
I have a PPT that explains this in more
detail if you are interested.
Duane
*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************
From: Matt MacKenzie
[mailto:]
Sent: Monday, December 05, 2005
12:51 PM
To: ;
MATHEWS, Tim; Sally St. Amand;
Cc:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
Process orientation is only one of
multiple potential integration with service oriented architecture. SOA-RM
is laying the foundation for durable architecture based on the core concept of
service orientation. We recognize that process oriented architecture is a
natural fit with service orientation…but so are things like event
orientation.
-matt
From:
[mailto:]
Sent: Monday, December 05, 2005
3:36 PM
To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand;
Cc:
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I think that SOA RM has done good job
documenting well-known service related concepts and defining some new ones.
I do not see other details besides
service and service-related concept definitions in the current SOA RM committee
draft right now. I look forward to seeing the completion of the model you
are working on with the bottom-up approach.
Business, business processes and collaboration aspects of business are
important to address in the model what is not the case with the current content
of the SOA RM committee draft. By a business process I mean a generic business
process entity which has common components (activities, decisions, etc) and
relationships between them that can be used to model a business process in
any environment regardless of what business we support and technology we use. I
agree with Sally that a link between business processes and services should be
one of key requirements any SOA reference model should try to meet.
I am not sure what SOA with services
brings to business when the link between the business processes and services
and overall business process semantics in the SOA context are not considered to
be important aspects in a SOA-based reference model.
Goran
-----Original Message-----
From: MATHEWS, Tim
[mailto:]
Sent: Monday, December 5, 2005
12:34 PM
To: 'Matt
MacKenzie', 'Sally St. Amand',
Cc:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better "Componentization"
Matt - I am not sure what point you
are trying to make by this? I agree with your premise of a bottom up
effort, as this was one of the operating assumptions that was made from the
beginning.
But, I am confident it is the
business environment that is independent from the reference model.
TM
From: Matt MacKenzie [mailto:]
Sent: Monday, December 05, 2005
11:58 AM
To: Sally St. Amand;
Cc:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better "Componentization"
Sally,
A reference model actually needs to be a bottom up effort. We
leave the ever so popular ?top-down? approach to folks like ebSOA J
We?re creating a vocabulary and general understanding of what I
hope we can call a discipline of computer science in the future. This
means, we need a durable reference model that is not dependent on the current
business environment.
-matt
From: Sally St. Amand [mailto:]
Sent: Monday, December 05, 2005
10:19 AM
To:
Cc:
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better "Componentization"
Frank
This is in
response to your request on last week?s conference call, if anyone has comments
speak now. I also think that the recent comments on clarifying sections are a
reflection of my issues with the specification.
I agree with the
majority of points made/described in ver 10. My issues are with what is not in
this draft. Based on Fig 1 the Refe! rence Model is guided by Reference
Architectures, Concrete Architectures, Profile & Related Models. They in
turn account for requirements, motivation & goals. This is creating a
Reference Model from the bottom up. I believe a Reference Model should reflect
a top down approach.
The Reference
Model needs to reflect the environment, the strategy and the priorities of the
business/mission/collaboration. This will impact the construction of
services. A service is a business task or activity that is realized through
technology. The draft does a good job of describing how that realization
happens. But it doesn?t provide a sufficient link between processes and
services. The draft makes the point that the central focus of! SOA is the
task of business function?getting something done. A business process is
made up of tasks and activities to achieve a goal (getting something done). The concept of creating the service from the
tasks and activities in a process is important. For example, where on the
continuum of fine grained to coarse grained should a particular service be;
this will affect interaction, reusability. The relationship between processes
and services needs to be in the Reference Model.
While I saw that
there is a note saying the glossary is still in flux, since one of the
objective of the Reference Model is a vocabulary, having less in the glossary
might be a better option. Is semantic integration a guiding principle of
SOA?
With respect to
conformance there needs to be business results. That is an SOA should provide
demonstrable mission accomplishments, e.g. ROI, match a competitors
distribution channel. SOA is not a technology. Conformance should provide
operational accomplishments, these should be measurable.
Sally
!
ServiceProcess.png
