[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 have an initial submission for this TC if anyone is interested. I have kind of stopped working on it due to time constraints but would welcome anyone else who wants to work on it. I have not yet contributed it to the TC but will if there is consensus. D ******************************* 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/ ******************************* -----Original Message----- From: Francis McCabe [mailto:fgm@fla.fujitsu.com] Sent: Thursday, December 08, 2005 9:28 AM To: Duane Nickull Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@lists.oasis-open.org Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better Perhaps we need an OASIS spec on concept maps .... On Dec 7, 2005, at 10:40 PM, Duane Nickull wrote: > I believe that the problem, with is largely due to the fact there > is no normative reference for how to interpret concept maps. In > this case, a service is neither an action nor an object. It is > imply an abstract concept. > > > > D > > > > ******************************* > 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: Metz Rebekah [mailto:metz_rebekah@bah.com] > Sent: Wednesday, December 07, 2005 7:18 PM > To: Bashioum, Christopher D; soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for > Better > > > > From: Bashioum, Christopher D [mailto:cbashioum@mitre.org] > Sent: Wednesday, December 07, 2005 5:06 PM > To: Metz Rebekah; soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for > Better > > > > Rebekah, > > > > what about the potential of an act? > > > > [->] The potential of service is an offer. > > > > I have a problem with the following > > > > <Snip> > > The actual invocation and performance of the capability is the > service; i.e. the action. > > </Snip> > > > > if I understand what you are saying here, it would imply that a > service is not a service until it is actually performing an > action. During the time that it is "waiting" to perform an action > it is not a service, nor is it after it has completed the action it > was created to do. > > > > [->] yes, you are right. That is exactly what I'm implying. The > service isn't performing the action, the implementation of the > action is. The service is the performance. > > > > > > In Duane's diagram, the service exists independent of the > interaction. However, the interaction is what causes the real- > world effect. > > > > I'm not sure I buy the other statement that a service is an act as > opposed to an object. Isn't it an object (in that it exists) who's > purpose is to perform an act? > > [->] So I'll ask a question in return. Let's assume the statement > is true. If a service exists as an object that is independent of > the capability who's purpose it is to perform; what differentiates > the service from the capability? > > > > For that matter, is the capability what is actually providing the > "action" and the service is the means to access that action? > > [->] From this perspective, what differentiates the service from > the service access point? > > > > [->] My point is that the conceptualization of service as an object > doesn't provide resolution to these questions. It is for this > reason that I started examining service as a verb rather than a > noun. From that perspective, the concepts and the relationships > between them clarified. > > > > Rebekah > > > > From: Metz Rebekah [mailto:metz_rebekah@bah.com] > Sent: Wednesday, December 07, 2005 4:37 PM > To: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for > Better > > Gosh - if this email came through in some weird format for everyone > else, I am terribly sorry about the wacky formatting of this email > thread. Not sure if everyone saw it as I did, but at least my > outlook client puked =) > > > > Uh-oh. We seem to be starting to head back to the service as an > object as opposed to an act. I still do not believe that a service > is an 'object.' In fact, I believe that assumption has caused > much of the difficulty in figuring out what a service actually is. > > > > What is invoked is a capability, consistent with the execution > context and so to produce real world effects. The actual > invocation and performance of the capability is the service; i.e. > the action. Hence I maintain that visibility, interaction and > effect are the interrelated concepts often (yet confusingly) > referred to with a shorthand nomenclature of 'service.' > > > > As far as roles go, the very essence of the word service is the > recognition that <someone> does <something> for <someone else>. I > would agree that any other specification of this generalization (uh... > isn't that an ontology) belongs in something other than the RM. > > > > Rebekah > > > > Rebekah Metz > > Associate > > Booz Allen Hamilton > > Voice: (703) 377-1471 > > Fax: (703) 902-3457 > > > > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Wednesday, December 07, 2005 4:19 PM > To: Metz Rebekah > Cc: Jones, Steve G; marchadr@wellsfargo.com; tmathews@lmi.org; > mattm@adobe.com; soa-rm@lists.oasis-open.org; > frank.mccabe@us.fujitsu.com; goran.zugic@semantion.com; > McGregor.Wesley@tbs-sct.gc.ca; dnickull@adobe.com; > sallystamand@yahoo.com > Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for > Better > > > > inline > > > > On Dec 7, 2005, at 4:00 PM, Metz Rebekah wrote: > > > > Comments inline... > > > > From: Ken Laskey [mailto:klaskey@mitre.org] > > Sent: Wednesday, December 07, 2005 3:43 PM > > To: Jones, Steve G > > Cc: marchadr@wellsfargo.com; tmathews@lmi.org; mattm@adobe.com; soa- > rm@lists.oasis-open.org; frank.mccabe@us.fujitsu.com; > goran.zugic@semantion.com; McGregor.Wesley@tbs-sct.gc.ca; > dnickull@adobe.com; sallystamand@yahoo.com > > 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. > > > > I think it is easy to start naming roles but difficult to stop, and > the roles will get more use-specific. > > > > Luckily, from the RM standpoint, we don't care. > > [->] or do we just delegate =) > > > > ... to someone who has no choice but to care ;-) > > 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...? > > > > Isn't the service an active player? I invoke it to get its real > world effect, so it certainly sounds like it does something. > > > > (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 =) > > > > ... at which point you initially choose RA cases that you can more > cleanly defined. You eventually get to the tougher ones, but we > should learn to ride a bicycle before we get a motorcycle (unless > Duane has a different perspective) > > > > Ken > > [->] Rebekah > > > > Ken > > > > > > 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: McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs- > sct.gc.ca] > > Sent: 06 December 2005 19:09 > > To: klaskey@mitre.org; 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 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:klaskey@mitre.org] > > Sent: December 6, 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 > > 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 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 ; 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 > > > > > > ! > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]