Barry:
The simple answer is "Yes" (even if I suspect a trap here somewhere!):
Association types "InstanceOf", "is-a", are built into the standard with
well defined Published Subject Indicators (PSIs) already. Using those is
standard. (01)
TM allows to create whatever levels you wish. You would perhaps have a
different association type to connect 'types' from the association type to
connect 'instances'. i.e. Types may be explicitly typed themselves as a
'Topic Type', thus the allowed role players in the class level adjacent_to
would be only topics of type 'Topic Type'. (02)
(Thanks to Graham Moore from NetworkedPlanet for help on this) (03)
Peter (04)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Smith, Barry
Sent: 13 December 2005 15:22
To: [ontolog-forum] ; soa-rm@xxxxxxxxxxxxxxxxxxxx;
ontolog-forum@xxxxxxxxxxxxxxxx
Subject: RE: [soa-rm] RE: [ontolog-forum] RE: [soa-rm] latest Draft of
Concept Map / N-ary Documents specification? (05)
Does Topic Maps have a way to define logically the relation between (06)
A adjacent_to B (07)
on the level of concepts and (08)
a adjacent_to b (09)
on the level of instances, in terms of the (010)
a instance_of A (011)
relation?
BS (012)
At 02:57 PM 12/13/2005, peter@xxxxxxxxxxxxx wrote:
>I think Topic Maps does, yes. Both because you are able to define
>whatever association types you need (and none are pre-defined, so you
>have complete control there) and constrain their use; and the fact that
>the conceptual model of the standard makes the distinction between
>occurrences and topics as different classes of "thing", conceptual and
>real-world, something RDF singularly fails to do
>
>Peter
>
>-----Original Message-----
>From: Smith, Barry [mailto:phismith@xxxxxxxxxxx] <snip/> 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
> (013)
_________________________________________________________________
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 (014)
_________________________________________________________________
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 (015)
|