[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
This sounds like something where an informational note (Concept Maps for Dummies?) would be useful but does that really require a TC? Sounds more like a blog entry. Ken On Dec 8, 2005, at 12:52 PM, Frank McCabe wrote: > Duane: > Did you send something out before? > In any case, I would be quite interested in taking a look. > > I wonder if there but be enough groundswell for an actual concept map > TC? As a modeling tool. > > Frank > > On Dec 8, 2005, at 9:44 AM, Duane Nickull wrote: > >> 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 >>> >>> >>> >>> >>> >>> ! >>> >>> >>> >>> >>> >>> >> > > ------------------------------------------------------------------------ ------------------ 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]