Understood. I just want to be the purity
a**hole, so you all don’t have to be J
-matt
From: Ken Laskey
[mailto:]
Sent: Wednesday, December 07, 2005
8:13 PM
To: Matt MacKenzie
Cc: ;
Duane Nickull; Sally St. Amand; ;
; MATHEWS, Tim; ;
;
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I agree we should not reference other specs that in the best of worlds
should derive from the RM, but I am interested in hearing opinions of other
concepts that someone might expect to be included. I expect to be
presenting this to sponsors and I see great value in practicing my arguments
with a friendly audience. If that audience uncovers something missing, we
are alerted what to add in. If we can justify a more limited RM scope and
show how those extra concepts can be derived from the smaller set, I have my
argument practiced.
A win-win either way.
Ken
On Dec 7, 2005, at 7:02 PM, Matt MacKenzie wrote:
Let[s
remember that SOA-RM is meant to be a foundational work. I am certainly
very interested to hear and absorb the ideas of our colleagues in ebSOA, and
OASIS as a whole…but I am just not interested in referencing other SOA
specs. We’re trying to define the first principles of SOA-RM, and to do
that I think we have to remain pure.
-matt
From:
[mailto:]
Sent:
Wednesday, December 07, 2005 6:43 PM
To:
Ken Laskey;
Cc:
Duane Nickull; Sally St. Amand; ;
;
Matt MacKenzie; MATHEWS, Tim; ;
;
Subject:
Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
Ken,
Thanks for the
response. I will send you specific additions and suggestions soon. I do not
want to interfere with the current finalization of your draft. You will
definitely have "a proposal" to discuss at your next week's FTF.
I look forward to
discussing a potential collaboration between SOA RM and ebSOA TC.
I believe that ebSOA editors think the same.
Goran
-----Original
Message-----
From:
Ken Laskey [mailto:]
Sent:
Wednesday, December 7, 2005 05:42 PM
To:
Cc:
'Duane Nickull', 'Sally St. Amand', ,
,
'Matt MacKenzie', 'MATHEWS, Tim'
Subject:
Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
Goran,
You are certainly much more familiar with the
specs you mention than I. Consider what specific additions you would suggest
for the RM spec and we can see exactly how this would affect the current draft.
Although time is short, it would be best to have something for consideration at
next week's ftf.
Ken
On Dec 7, 2005, at 5:30 PM, wrote:
Ken,
You raised some very interesting points here.
These are just some of architectural details we support in Federated
Enterprise Reference Architecture (FERA)-based SOA.
We already have a reference architecture and we
already model and use services in SOA Information Model (SOA IM) and SOA
Collaboration Semantics (SOA CS) and link them with business processes and
their components. I am not trying to interfere with SOA RM TC concept and
vision of SOA RM. I
expressed what my vision is and I respect and understand differences. However
it is not the reason that we cannot collaborate in supporting integration of
OASIS SOA related specs. SOA RM TC does not have to change its specs to do that
but some kind of link that provides the integration has to be formulated and
mutually referenced in our specs. Please keep in mind that this is my opinion.
Some kind of flexibility is needed to support OASIS standards convergence and
integration.
Our view and support of business processes is
generic (i.e., supply chain, logistics, data management, finance, and many
others). We also support infrastructural processes and IT management processes.
Any process that can be presented using standard generic process language
(activities, decisions, events, etc.) we support. Just to list very few
concepts from our model that match what you mentioned below:
- A service consumer can be a human or a system (
a software agent). We support and model both people and systems as participants
in collaborations.
- Each service has inputs and outputs. Outputs of
one service become inputs for others. In SOA IM, we even model them based on
versioning, timing and other constraints.
- FERA-based SOA reference architecture does not
change with processes. It is a generic architecture that supports many types of
processes. We support all SOA layers from message exchanges to complex services
orchestrations. For example, ESB is just one of the components in FERA-based
SOA architecture represented in a form of the Gateway and the Federation
Manager. We have a complete "service orchestration engine" that
semantically integrates SOA architectural components like registry and
repository, security provider, process flow controller and others. And all of
them are open standard-based components. We integrate and reference already
available standards for these components (i.e., Web Services, ebXML, etc.). SOA
Information Model and SOA Collaboration Semantics provide architectural
integration and management and maintenance of process context and content and
of course processes and their components are modeled and executed as services.
I just tought that this can save some time to SOA
RM TC if you start considering concepts and solutions ebSOA TC already have in
place for a while.
Goran
-----Original
Message-----
From:
Ken Laskey [mailto:]
Sent:
Tuesday,
December 6, 2005 01:38 PM
To:
'Duane
Nickull', 'Goran Zugic', 'Matt MacKenzie', 'MATHEWS, Tim', 'Sally St. Amand',
Cc:
Subject:
RE: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
I think we need to add some words to the RM to
capture this discussion. We cover part of this in the beginning of
Section 3.2.1 but need to be more specific that:
- a service consumer can be a human or a software
agent;
- a service consumer can invoke any number of
services (including a single service in isolation) and can chain the output of
some services to act as the input of others;
- from the perspective of a given service, the
occurrence of such chaining would not be visible;
- the service consumer can be implementing a
business process;
- the specific of a business process do not change
the basic SOA concepts as described in the RM; however, the specific
architecture that one designs and implements will reflect the business process
and make use of specific service instances that corresponds to the real world
effects that the business process hopes to realize.
Now that said, and in full appreciation that we
agreed earlier that mechanisms which combine services (e.g. choreography,
orchestration) are out of scope, is it sufficient for words, such as those
suggested above, to be included somewhere within the current discussion or do
we need to pull it out into a subsection on its own? As an example of the
former, we tried to deal with loose-coupling and coarse-grained with words at
the end of Section 2.1.
Ken
At 12:23 PM 12/6/2005, Duane Nickull wrote:
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. -
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. -
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
!
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
|
MITRE Corporation, M/S H305 phone:
703-983-7934 |
|
7515 Colshire Drive
fax: 703-983-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA
22102-7508
---
Ken Laskey
MITRE Corporation,
M/S H305 phone: 703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean
VA 22102-7508
