[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
I agree with Ken. If we return to the definition
of service again; there is some <entity> that provides the service. Say my
brother Isaac has a falafel stand and offer a falafel service. There are
several ways to define the ‘falafel service,’ but they are
ancillary to the point I am trying to make here. Isaac is the service provider.
If I want to avail myself of a falafel, I consume the service. If I don’t
really want to get up off the couch and walk to the falafel stand, I could
choose instead to use a delivery service like ‘Dr. Delivery’ to
provide the falafel instead. I am still a consumer. However, I am a consumer
of the delivery service which provides its own unique service. From my
perspective, the delivery service does in fact function as a broker to multiple
services – say to falafel, pizza, Chinese, Thai, Indian, and burgers but
that is the service I wanted. Nonetheless, that function does not negate the
role that the delivery played when interacting with the falafel service –
that of a service consumer. Essentially, a broker is a compilation of at
least two distinct interactions – one in which it plays the consumer and
one in which it plays the provider. Rebekah Rebekah Associate Booz Allen Hamilton Voice: (703) 377-1471 Fax: (703) 902-3457 From: Ken
Laskey [mailto:klaskey@mitre.org] 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. I hate to stir
things up a bit, but can you change the service consumer term to service actor? -----Original Message----- From: Ken Laskey [ mailto:klaskey@mitre.org] Sent: Tuesday, December 06, 2005
10:39 AM To: Duane Nickull; Goran Zugic;
Matt MacKenzie; 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 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:goran.zugic@semantion.com]
Sent: Monday, December 05, 2005
8:47 PM To: Duane Nickull; Matt MacKenzie;
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 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 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 Goran ----- Original Message ----- From: Duane
Nickull To: Matt MacKenzie
; goran.zugic@semantion.com ; MATHEWS, Tim ; Sally St. Amand ; frank.mccabe@us.fujitsu.com Cc: soa-rm@lists.oasis-open.org
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: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. Goran
-----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"
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 | | \
----------------------------------------------------------------------------------
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]