[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
In keeping with the previous discussion, we didn't go out of our way
to define the service consumer (or service provider) as a key concept
but the term enters the discussion in Section 2.1 and is used as
appropriate throughout the document. In keeping with KISS, I think
it works well that way :-)
Ken
At 03:32 PM 12/6/2005, Rex Brooks wrote:
>I've always contended that service consumer was necessary, but in
>terms of this particular discussion, if the object is to avoid
>adding a Service Consumer to the equation of the RM, we could call
>this Role "Intermediary," if "Broker" is also verboten. However, in
>terms of keeping it simple, sweetheart, it's still a consumer. I
>don't expect to see a consumer in the RM, nor am I arguing to open
>up the issue. I have accepted it and prefer moving on to deliver a
>spec sooner rather than later.
>
>Ciao,
>Rex
>
>At 2:36 PM -0500 12/6/05, Metz Rebekah wrote:
>>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 Metz
>>Associate
>>Booz Allen Hamilton
>>Voice: (703) 377-1471
>>Fax: (703) 902-3457
>>
>>
>>From: Ken Laskey [mailto:klaskey@mitre.org]
>>Sent: Tuesday, December 06, 2005 2:02 PM
>>To: marchadr@wellsfargo.com; dnickull@adobe.com;
>>goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;
>>sallystamand@yahoo.com; 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 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, marchadr@wellsfargo.com 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: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/>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/>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 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: <mailto:dnickull@adobe.com>Duane Nickull
>>To: <mailto:mattm@adobe.com>Matt MacKenzie ;
>><mailto:goran.zugic@semantion.com>goran.zugic@semantion.com ;
>><mailto:tmathews@lmi.org>MATHEWS, Tim ;
>><mailto:sallystamand@yahoo.com>Sally St. Amand ;
>><mailto:frank.mccabe@us.fujitsu.com>frank.mccabe@us.fujitsu.com
>>Cc: <mailto:soa-rm@lists.oasis-open.org>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/>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/>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 |
>> | 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 /
>>----------------------------------------------------------------------------------
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309
--
---------------------------------------------------------------------------------
/ Ken
Laskey \
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax: 703-983-1379 |
\ McLean VA 22102-7508 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]