[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ontolog-forum] RE: [soa-rm] latest Draft of Concept Map / N-ary Documents specification?
I see concept maps and topic maps as 2 distinct things, each having value in different situations - with the understanding that there may be situations in which both have value. Joe Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: ontolog-forum-bounces@ontolog.cim3.net > [mailto:ontolog-forum-bounces@ontolog.cim3.net] On Behalf Of > Peter F Brown > Sent: Monday, December 12, 2005 4:46 PM > To: 'Duane Nickull'; '[ontolog-forum] '; soa-rm@lists.oasis-open.org > Subject: [ontolog-forum] RE: [soa-rm] latest Draft of Concept > Map / N-ary Documents specification? > > All: > I might be somewhat late on this thread, but trying to play > catch up between the daytime F2F this week and my day-job > work in the evening... > > I'm wondering if the proposal is not actually redundant: > there is a standard out there for handling N-ary > relationships in the way you want (or at least in the way > I've understood it): ISO 13250:2000 Topic Maps. What's more > the relationships (or "associations") are typed, giving a > further level of control that something like RDF doesn't offer. > > You can find a useful summary of this particular aspect of TM > at http://www.w3.org/2002/06/09-RDF-topic-maps/ > > Peter > > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: 08 December 2005 19:10 > To: Frank McCabe; [ontolog-forum] > Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@lists.oasis-open.org > Subject: [soa-rm] latest Draft of Concept Map / N-ary > Documents specification? > > All: > > Here it is. I stopped when I started asking some rather > detailed questions that may best be left vague. The fear is > that the concept map notation may become just as complex as > UML CVD's. Interpret the logic using KIF. > > Several people from the Ontolog Forum have looked at it and > also expressed interest in continuing the work. > > Do you guys think this might be the basis for a TC? If not - > where might this find a nice home to be completed? > > 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/ > ******************************* > > > -----Original Message----- > From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] > Sent: Thursday, December 08, 2005 9:53 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 > > 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 > >> > >> > >> > >> > >> > >> ! > >> > >> > >> > >> > >> > >> > > > > > > _________________________________________________________________ > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ > Subscribe/Unsubscribe/Config: > http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ > Shared Files: http://ontolog.cim3.net/file/ Community Wiki: > http://ontolog.cim3.net/wiki/ To Post: > mailto:ontolog-forum@ontolog.cim3.net > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]