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. -
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
!
--
---------------------------------------------------------------------------------
/ 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
