Just so, Barry, (01)
Ciao,
Rex (02)
At 8:48 AM +0100 12/13/05, Smith, Barry wrote:
>At 08:36 AM 12/13/2005, you wrote:
>>Joe:
>>Sorry, it might be that my brain's not awake yet but...what do you mean?!!
>>
>>What *I* meant was that the Topic Maps standard exists and defines a series
>>of concepts (topics == concepts in a concept map; associations ==
>>relationships; and occurrences == specific real world instances of a
>>topic/concept), and that as a model it is adequate for the job that Duane is
>>outlining. Furthermore, TM has a reference model, a constraint language and
>>its use of typed associations, the idea of scope, and its inherent
>>computability make it valuable.
>
>Are Topic Maps able to do justice to the fact that associations
>defined between concepts typically behave differently from
>associations defined between real-world instances?
>
>Thus on the instance level the relation of adjacency between
>cytoplasm and cell nucleus is always symmetric. (Adjacency must be
>symmetric, right?)
>
>But on the concept level, while we have
>
>cell nucleus adjacent_to cytoplasm
>
>we do not have
>
>cytoplasm adjacent_to cell nucleus
>
>because not every cell has a nucleus.
>BS
>
>
>>Peter
>>
>>-----Original Message-----
>>From: Chiusano Joseph [mailto:chiusano_joseph@xxxxxxx]
>>Sent: 12 December 2005 22:49
>>To: peter@xxxxxxxxxxxxx; [ontolog-forum] ; Duane Nickull;
>>soa-rm@xxxxxxxxxxxxxxxxxxxx
>>Subject: [soa-rm] 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@xxxxxxxxxxxxxxxx
>>> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Peter F
>>> Brown
>>> Sent: Monday, December 12, 2005 4:46 PM
>>> To: 'Duane Nickull'; '[ontolog-forum] '; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxx]
>>> Sent: 08 December 2005 19:10
>>> To: Frank McCabe; [ontolog-forum]
>>> Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxx]
>>> Sent: Thursday, December 08, 2005 9:53 AM
>>> To: Duane Nickull
>>> Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxx]
>>> > Sent: Thursday, December 08, 2005 9:28 AM
>>> > To: Duane Nickull
>>> > Cc: Metz Rebekah; Bashioum, Christopher D;
>>> soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> > 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@xxxxxxx]
>>> >> Sent: Wednesday, December 07, 2005 7:18 PM
>>> >> To: Bashioum, Christopher D; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> >> Better
>>> >>
>>> >>
>>> >>
>>> >> From: Bashioum, Christopher D [mailto:cbashioum@xxxxxxxxx]
>>> >> Sent: Wednesday, December 07, 2005 5:06 PM
>>> >> To: Metz Rebekah; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >> 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@xxxxxxx]
>>> >> Sent: Wednesday, December 07, 2005 4:37 PM
>>> >> To: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >> 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@xxxxxxxxx]
>>> >> Sent: Wednesday, December 07, 2005 4:19 PM
>>> >> To: Metz Rebekah
>>> >> Cc: Jones, Steve G; marchadr@xxxxxxxxxxxxxx; tmathews@xxxxxxx;
>>> >> mattm@xxxxxxxxx; soa-rm@xxxxxxxxxxxxxxxxxxxx;
>>> >> frank.mccabe@xxxxxxxxxxxxxx; goran.zugic@xxxxxxxxxxxxx;
>>> >> McGregor.Wesley@xxxxxxxxxxxxx; dnickull@xxxxxxxxx;
>>> >> sallystamand@xxxxxxxxx
>>> >> 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@xxxxxxxxx]
>>> >>
>>> >> Sent: Wednesday, December 07, 2005 3:43 PM
>>> >>
>>> >> To: Jones, Steve G
>>> >>
>>> >> Cc: marchadr@xxxxxxxxxxxxxx; tmathews@xxxxxxx;
>>> mattm@xxxxxxxxx; soa-
>>> >> rm@xxxxxxxxxxxxxxxxxxxx; frank.mccabe@xxxxxxxxxxxxxx;
>>> >> goran.zugic@xxxxxxxxxxxxx; McGregor.Wesley@xxxxxxxxxxxxx;
>>> >> dnickull@xxxxxxxxx; sallystamand@xxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxxxxxx
>>>[<mailto:McGregor.Wesley@tbs->mailto:McGregor.Wesley@tbs-
>>> >> sct.gc.ca]
>>> >>
>>> >> Sent: 06 December 2005 19:09
>>> >>
>>> >> To: klaskey@xxxxxxxxx; marchadr@xxxxxxxxxxxxxx;
>>> dnickull@xxxxxxxxx;
>>> >> goran.zugic@xxxxxxxxxxxxx; mattm@xxxxxxxxx; tmathews@xxxxxxx;
>>> >> sallystamand@xxxxxxxxx; frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxx]
>>> >>
>>> >> Sent: December 6, 2005 2:02 PM
>>> >>
>>> >> To: marchadr@xxxxxxxxxxxxxx; dnickull@xxxxxxxxx;
>>> >> goran.zugic@xxxxxxxxxxxxx; mattm@xxxxxxxxx; tmathews@xxxxxxx;
>>> >> sallystamand@xxxxxxxxx; frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxxxxxxx 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@xxxxxxxxx]
>>> >>
>>> >> Sent: Tuesday, December 06, 2005 10:39 AM
>>> >>
>>> >> To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS,
>>> Tim; Sally
>>> >> St. Amand; frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >>
>>> >>
>>> >> 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@xxxxxxxxxxxxx]
>>> >>
>>> >> Sent: Monday, December 05, 2005 8:47 PM
>>> >>
>>> >> To: Duane Nickull; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand;
>>> >> frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxxxxxx ; MATHEWS,
>>> Tim ; Sally
>>> >> St. Amand ; frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxx]
>>> >>
>>> >> Sent: Monday, December 05, 2005 12:51 PM
>>> >>
>>> >> To: goran.zugic@xxxxxxxxxxxxx; MATHEWS, Tim; Sally St. Amand;
>>> >> frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxxxxxx [ mailto:goran.zugic@xxxxxxxxxxxxx]
>>> >>
>>> >> Sent: Monday, December 05, 2005 3:36 PM
>>> >>
>>> >> To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand;
>>> >> frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxx]
>>> >>
>>> >> Sent: Monday, December 5, 2005 12:34 PM
>>> >>
>>> >> To: 'Matt MacKenzie', 'Sally St. Amand',
>>> frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxx]
>>> >>
>>> >> Sent: Monday, December 05, 2005 11:58 AM
>>> >>
>>> >> To: Sally St. Amand; frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxx]
>>> >>
>>> >> Sent: Monday, December 05, 2005 10:19 AM
>>> >>
>>> >> To: frank.mccabe@xxxxxxxxxxxxxx
>>> >>
>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> 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@xxxxxxxxxxxxxxxx
>>>
>>>
>>
>>
>>_________________________________________________________________
>>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@xxxxxxxxxxxxxxxx
>>
>
>
>_________________________________________________________________
>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@xxxxxxxxxxxxxxxx (03)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
_________________________________________________________________
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@xxxxxxxxxxxxxxxx (04)
|