Comments inline…
From: Ken
Laskey [mailto:]
Sent: Wednesday, December 07, 2005
3:43 PM
To: Jones, Steve G
Cc: ;
; ; ;
; ;
; ;
Subject: Re: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
If I invoke a service, I am a service consumer. It
does not matter if I invoke the service on my own initiative or am told to do
it (through a targeted instruction or as part of a more complex set of
instructions), I am still the service consumer.
[->] Agreed.
I could glibly say that if I "provide" a
service, I'm a service provider, but I fear things are not that simple. Is the
entity that created the service its provider, or the one who maintains it, or
the one who hosts it, or the one who pays for it, or ...?
[->] I see this being a question of ‘what are the roles’
versus ‘who plays the roles’. At first pass, it seems right that we recognize
the roles @ the RM level and leave the details of determining the best way to
decide how to assign some entity into that role to the RA.
Luckily, from the RM standpoint, we don't care.
[->] or do we just delegate =)
To be used within the context of SOA, the service must
be visible, must be able to take part in an interaction
[->] Here it sounds like the service is an active player
in an interaction. Isn’t it that the service consumer and provider interact
(as specified…?
(as specified by the established execution context),
and must produce a real world effect (which I assume may in some circumstances
be null). It has been "provided" but we don't care how or by whom.
So, in summary, there's a lot of muddy water but
sometimes we can avoid playing in it. :-)
[->] Or we can draw a circle around it and leave that to
the RA =)
Ken
[->] Rebekah
If I make a service available for someone to invoke
(and here I would say that "make available"
On Dec 7, 2005, at 4:47 AM, Jones, Steve G wrote:
To add some mud into the
water…
Many Bus architectures do
“enrichment” of messages between consumer and producer, including the
invocation of other services to perform that enrichment (e.g stock quote
returns current price, enrichment provides the last ten days closing price).
They may also do calculations that result in the non-connection or
“empty” return from the service (e.g. if you call for “last five minutes
trades” after the market has closed… its an empty set). So while I agree
that the service consumer is key it’s sometimes hard to identify the true
consumer and the true producer of a service within a virtualised bus.
Steve
From:
[mailto:]
Sent: 06 December 2005 19:09
To: ;
; ; ;
; ; ;
Cc:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I agree with Ken.
The service consumer is
the key concept that indicates the entity that invoked the service in the first
place.
A brokering service or
service actor is merely a middle-man.
Wes
-----Original Message-----
From: Ken Laskey
[mailto:]
Sent: December 6, 2005 2:02 PM
To: ;
; ; ;
; ;
Cc:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I could argue that a broker consumes the service on
someone else's behalf. In reality, service actor seems too nondescriptive
because either the consumer or the provider can be thought of as an actor.
Ken
At 01:45 PM 12/6/2005, wrote:
I hate to stir
things up a bit, but can you change the service consumer term to service actor?
Since in the
case of brokering the service actor is not consuming but brokering a request to
another service.
The broker
service can be a service actor upon the service but might not really consume
any part of the service since it is a pass through.
But I guess
this is a matter of opinion.
- Dan
-----Original Message-----
From: Ken Laskey [ mailto:]
Sent: Tuesday, December 06, 2005
10:39 AM
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
/
----------------------------------------------------------------------------------
This message contains information that may be
privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to read, print, retain, copy,
disseminate, distribute, or use this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete
all copies of this message.
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515
Colshire Drive fax: 703-983-1379
McLean
VA 22102-7508
