[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]