[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'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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]