OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] RE: [ontolog-forum] RE: [soa-rm] latest Draft of Concept Map / N-ary Documents specification?


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.

Peter

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent: 12 December 2005 22:49
To: peter@justbrown.net; [ontolog-forum] ; Duane Nickull;
soa-rm@lists.oasis-open.org
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@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]