From:
Duane Nickull [mailto:dnickull@adobe.com]
Sent: 05 December 2005 22:02
To: Matt MacKenzie;
goran.zugic@semantion.com; MATHEWS, Tim; Sally St. Amand;
frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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
From:
Matt MacKenzie [mailto:mattm@adobe.com]
Sent: Monday, December 05, 2005
12:51 PM
To: goran.zugic@semantion.com;
MATHEWS, Tim; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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:
goran.zugic@semantion.com [mailto:goran.zugic@semantion.com]
Sent: Monday, December 05, 2005
3:36 PM
To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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.
-----Original
Message-----
From: MATHEWS, Tim
[mailto:tmathews@lmi.org]
Sent: Monday, December 5, 2005
12:34 PM
To: 'Matt MacKenzie', 'Sally St.
Amand', frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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:mattm@adobe.com]
Sent: Monday, December 05, 2005
11:58 AM
To: Sally St. Amand;
frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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:sallystamand@yahoo.com]
Sent: Monday, December 05, 2005
10:19 AM
To: frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better "Componentization"
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.
!