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] Proposal: Reorganization of SOA-RM Draft for Better


This sounds like something where an informational note (Concept Maps  
for Dummies?) would be useful but does that really require a TC?   
Sounds more like a blog entry.

Ken

On Dec 8, 2005, at 12:52 PM, Frank McCabe wrote:

> Duane:
>  Did you send something out before?
>  In any case, I would be quite interested in taking a look.
>
>  I wonder if there but be enough groundswell for an actual concept map  
> TC? As a modeling tool.
>
>  Frank
>
> On Dec 8, 2005, at 9:44 AM, Duane Nickull wrote:
>
>> I have an initial submission for this TC if anyone is interested.  I
>> have kind of stopped working on it due to time constraints but would
>> welcome anyone else who wants to work on it.  I have not yet  
>> contributed
>> it to the TC but will if there is consensus.
>>
>> D
>>
>> *******************************
>> Adobe Systems, Inc. - http://www.adobe.com
>> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>> Chair - OASIS SOA Reference Model Technical Committee
>> Personal Blog - http://technoracle.blogspot.com/
>> *******************************
>>
>>
>> -----Original Message-----
>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
>> Sent: Thursday, December 08, 2005 9:28 AM
>> To: Duane Nickull
>> Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@lists.oasis-open.org
>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>> Better
>>
>> Perhaps we need an OASIS spec on concept maps ....
>>
>> On Dec 7, 2005, at 10:40 PM, Duane Nickull wrote:
>>
>>> I believe that the problem, with is largely due to the fact there
>>> is no normative reference for how to interpret concept maps.  In
>>> this case, a service is neither an action nor an object.  It is
>>> imply an abstract concept.
>>>
>>>
>>>
>>> D
>>>
>>>
>>>
>>> *******************************
>>> Adobe Systems, Inc. - http://www.adobe.com
>>> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>>> Chair - OASIS SOA Reference Model Technical Committee
>>> Personal Blog - http://technoracle.blogspot.com/
>>> *******************************
>>>
>>>
>>>
>>> From: Metz Rebekah [mailto:metz_rebekah@bah.com]
>>> Sent: Wednesday, December 07, 2005 7:18 PM
>>> To: Bashioum, Christopher D; soa-rm@lists.oasis-open.org
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> From: Bashioum, Christopher D [mailto:cbashioum@mitre.org]
>>> Sent: Wednesday, December 07, 2005 5:06 PM
>>> To: Metz Rebekah; soa-rm@lists.oasis-open.org
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> Rebekah,
>>>
>>>
>>>
>>> what about the potential of an act?
>>>
>>>
>>>
>>> [->] The potential of service is an offer.
>>>
>>>
>>>
>>> I have a problem with the following
>>>
>>>
>>>
>>> <Snip>
>>>
>>> The actual invocation and performance of the capability is the
>>> service; i.e. the action.
>>>
>>> </Snip>
>>>
>>>
>>>
>>> if I understand what you are saying here, it would imply that a
>>> service is not a service until it is actually performing an
>>> action.  During the time that it is "waiting" to perform an action
>>> it is not a service, nor is it after it has completed the action it
>>> was created to do.
>>>
>>>
>>>
>>> [->] yes, you are right.  That is exactly what I'm implying.  The
>>> service isn't performing the action, the implementation of the
>>> action is.  The service is the performance.
>>>
>>>
>>>
>>>
>>>
>>> In Duane's diagram, the service exists independent of the
>>> interaction.  However, the interaction is what causes the real-
>>> world effect.
>>>
>>>
>>>
>>> I'm not sure I buy the other statement that a service is an act as
>>> opposed to an object.  Isn't it an object (in that it exists) who's
>>> purpose is to perform an act?
>>>
>>> [->] So I'll ask a question in return.  Let's assume the statement
>>> is true.  If a service exists as an object that is independent of
>>> the capability who's purpose it is to perform; what differentiates
>>> the service from the capability?
>>>
>>>
>>>
>>>   For that matter, is the capability what is actually providing the
>>> "action" and the service is the means to access that action?
>>>
>>> [->] From this perspective, what differentiates the service from
>>> the service access point?
>>>
>>>
>>>
>>> [->] My point is that the conceptualization of service as an object
>>> doesn't provide resolution to these questions.  It is for this
>>> reason that I started examining service as a verb rather than a
>>> noun.  From that perspective, the concepts and the relationships
>>> between them clarified.
>>>
>>>
>>>
>>> Rebekah
>>>
>>>
>>>
>>> From: Metz Rebekah [mailto:metz_rebekah@bah.com]
>>> Sent: Wednesday, December 07, 2005 4:37 PM
>>> To: soa-rm@lists.oasis-open.org
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>> Gosh - if this email came through in some weird format for everyone
>>> else, I am terribly sorry about the wacky formatting of this email
>>> thread.  Not sure if everyone saw it as I did, but at least my
>>> outlook client puked =)
>>>
>>>
>>>
>>> Uh-oh.  We seem to be starting to head back to the service as an
>>> object as opposed to an act.  I still do not believe that a service
>>> is an 'object.'   In fact, I believe that assumption has caused
>>> much of the difficulty in figuring out what a service actually is.
>>>
>>>
>>>
>>> What is invoked is a capability, consistent with the execution
>>> context and so to produce real world effects.  The actual
>>> invocation and performance of the capability is the service; i.e.
>>> the action.  Hence I maintain that visibility, interaction and
>>> effect are the interrelated concepts often (yet confusingly)
>>> referred to with a shorthand nomenclature of 'service.'
>>>
>>>
>>>
>>> As far as roles go, the very essence of the word service is the
>>> recognition that <someone> does <something> for <someone else>.  I
>>> would agree that any other specification of this generalization  
>>> (uh...
>>
>>> isn't that an ontology) belongs in something other than the RM.
>>>
>>>
>>>
>>> Rebekah
>>>
>>>
>>>
>>> Rebekah Metz
>>>
>>> Associate
>>>
>>> Booz Allen Hamilton
>>>
>>> Voice:  (703) 377-1471
>>>
>>> Fax:     (703) 902-3457
>>>
>>>
>>>
>>> From: Ken Laskey [mailto:klaskey@mitre.org]
>>> Sent: Wednesday, December 07, 2005 4:19 PM
>>> To: Metz Rebekah
>>> Cc: Jones, Steve G; marchadr@wellsfargo.com; tmathews@lmi.org;
>>> mattm@adobe.com; soa-rm@lists.oasis-open.org;
>>> frank.mccabe@us.fujitsu.com; goran.zugic@semantion.com;
>>> McGregor.Wesley@tbs-sct.gc.ca; dnickull@adobe.com;
>>> sallystamand@yahoo.com
>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> inline
>>>
>>>
>>>
>>> On Dec 7, 2005, at 4:00 PM, Metz Rebekah wrote:
>>>
>>>
>>>
>>> Comments inline...
>>>
>>>
>>>
>>> From: Ken Laskey [mailto:klaskey@mitre.org]
>>>
>>> Sent: Wednesday, December 07, 2005 3:43 PM
>>>
>>> To: Jones, Steve G
>>>
>>> Cc: marchadr@wellsfargo.com; tmathews@lmi.org; mattm@adobe.com; soa-
>>> rm@lists.oasis-open.org; frank.mccabe@us.fujitsu.com;
>>> goran.zugic@semantion.com; McGregor.Wesley@tbs-sct.gc.ca;
>>> dnickull@adobe.com; sallystamand@yahoo.com
>>>
>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> If I invoke a service, I am a service consumer. It does not matter
>>> if I invoke the service on my own initiative or am told to do it
>>> (through a targeted instruction or as part of a more complex set of
>>> instructions), I am still the service consumer.
>>>
>>>
>>>
>>> [->] Agreed.
>>>
>>>
>>>
>>> I could glibly say that if I "provide" a service, I'm a service
>>> provider, but I fear things are not that simple. Is the entity that
>>> created the service its provider, or the one who maintains it, or
>>> the one who hosts it, or the one who pays for it, or ...?
>>>
>>> [->] I see this being a question of 'what are the roles' versus
>>> 'who plays the roles'.   At first pass, it seems right that we
>>> recognize the roles @ the RM level and leave the details of
>>> determining the best way to decide how to assign some entity into
>>> that role to the RA.
>>>
>>>
>>>
>>> I think it is easy to start naming roles but difficult to stop, and
>>> the roles will get more use-specific.
>>>
>>>
>>>
>>> Luckily, from the RM standpoint, we don't care.
>>>
>>> [->] or do we just delegate =)
>>>
>>>
>>>
>>> ... to someone who has no choice but to care ;-)
>>>
>>> To be used within the context of SOA, the service must be visible,
>>> must be able to take part in an interaction
>>>
>>> [->] Here it sounds like the service is an active player in an
>>> interaction.  Isn't it that the service consumer and provider
>>> interact (as specified...?
>>>
>>>
>>>
>>> Isn't the service an active player? I invoke it to get its real
>>> world effect, so it certainly sounds like it does something.
>>>
>>>
>>>
>>> (as specified by the established execution context), and must
>>> produce a real world effect (which I assume may in some
>>> circumstances be null). It has been "provided" but we don't care
>>> how or by whom.
>>>
>>>
>>>
>>> So, in summary, there's a lot of muddy water but sometimes we can
>>> avoid playing in it. :-)
>>>
>>> [->] Or we can draw a circle around it and leave that to the RA =)
>>>
>>>
>>>
>>> ... at which point you initially choose RA cases that you can more
>>> cleanly defined. You eventually get to the tougher ones, but we
>>> should learn to ride a bicycle before we get a motorcycle (unless
>>> Duane has a different perspective)
>>>
>>>
>>>
>>> Ken
>>>
>>> [->] Rebekah
>>>
>>>
>>>
>>> Ken
>>>
>>>
>>>
>>>
>>>
>>> If I make a service available for someone to invoke (and here I
>>> would say that "make available"
>>>
>>> On Dec 7, 2005, at 4:47 AM, Jones, Steve G wrote:
>>>
>>>
>>>
>>>
>>>
>>> To add some mud into the water...
>>>
>>>
>>>
>>> Many Bus architectures do "enrichment" of messages between consumer
>>> and producer, including the invocation of other services to perform
>>> that enrichment (e.g stock quote returns current price, enrichment
>>> provides the last ten days closing price).  They may also do
>>> calculations that result in the non-connection or "empty" return
>>> from the service (e.g. if you call for "last five minutes trades"
>>> after the market has closed... its an empty set).  So while I agree
>>> that the service consumer is key it's sometimes hard to identify
>>> the true consumer and the true producer of a service within a
>>> virtualised bus.
>>>
>>>
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-
>>> sct.gc.ca]
>>>
>>> Sent: 06 December 2005 19:09
>>>
>>> To: klaskey@mitre.org; marchadr@wellsfargo.com; dnickull@adobe.com;
>>> goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;
>>> sallystamand@yahoo.com; frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> I agree with Ken.
>>>
>>>
>>>
>>> The service consumer is the key concept that indicates the entity
>>> that invoked the service in the first place.
>>>
>>>
>>>
>>> A brokering service or service actor is merely a middle-man.
>>>
>>>
>>>
>>> Wes
>>>
>>> -----Original Message-----
>>>
>>> From: Ken Laskey [mailto:klaskey@mitre.org]
>>>
>>> Sent: December 6, 2005 2:02 PM
>>>
>>> To: marchadr@wellsfargo.com; dnickull@adobe.com;
>>> goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;
>>> sallystamand@yahoo.com; frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> I could argue that a broker consumes the service on someone else's
>>> behalf.  In reality, service actor seems too nondescriptive because
>>> either the consumer or the provider can be thought of as an actor.
>>>
>>>
>>>
>>> Ken
>>>
>>>
>>>
>>> At 01:45 PM 12/6/2005, marchadr@wellsfargo.com wrote:
>>>
>>>
>>>
>>> I hate to stir things up a bit, but can you change the service
>>> consumer term to service actor?
>>>
>>> Since in the case of brokering the service actor is not consuming
>>> but brokering a request to another service.
>>>
>>> The broker service can be a service actor upon the service but
>>> might not really consume any part of the service since it is a pass
>>> through.
>>>
>>>
>>>
>>> But I guess this is a matter of opinion.
>>>
>>>
>>>
>>> - Dan
>>>
>>> -----Original Message-----
>>>
>>> From: Ken Laskey [ mailto:klaskey@mitre.org]
>>>
>>> Sent: Tuesday, December 06, 2005 10:39 AM
>>>
>>> To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS, Tim; Sally
>>> St. Amand; frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>>
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> I think we need to add some words to the RM to capture this
>>> discussion.  We cover part of this in the beginning of Section
>>> 3.2.1 but need to be more specific that:
>>>
>>>
>>>
>>> - a service consumer can be a human or a software agent;
>>>
>>>
>>>
>>> - a service consumer can invoke any number of services (including a
>>> single service in isolation) and can chain the output of some
>>> services to act as the input of others;
>>>
>>>
>>>
>>> - from the perspective of a given service, the occurrence of such
>>> chaining would not be visible;
>>>
>>>
>>>
>>> - the service consumer can be implementing a business process;
>>>
>>>
>>>
>>> - the specific of a business process do not change the basic SOA
>>> concepts as described in the RM; however, the specific architecture
>>> that one designs and implements will reflect the business process
>>> and make use of specific service instances that corresponds to the
>>> real world effects that the business process hopes to realize.
>>>
>>>
>>>
>>> Now that said, and in full appreciation that we agreed earlier that
>>> mechanisms which combine services (e.g. choreography,
>>> orchestration) are out of scope, is it sufficient for words, such
>>> as those suggested above, to be included somewhere within the
>>> current discussion or do we need to pull it out into a subsection
>>> on its own?  As an example of the former, we tried to deal with
>>> loose-coupling and coarse-grained with words at the end of Section
>>> 2.1.
>>>
>>>
>>>
>>> Ken
>>>
>>> At 12:23 PM 12/6/2005, Duane Nickull wrote:
>>>
>>>
>>>
>>> Goran:
>>>
>>>
>>>
>>> I slightly disagree with your assertions, probably based on
>>> semantics.  For a service to "participate" in a process, it would
>>> have to be aware of the process (which many will not be).  A better
>>> way to depict this may be to state "services may be aggregated and
>>> used by processes" and "processes may be represented/exposed as
>>> services".  There are really no limits to the number of layers that
>>> can be present.  Attached is a UML CVD depicting such.
>>>
>>>
>>>
>>> A key rationale of why process is not part of SOA is that services
>>> cannot see process.  They are not aware of whether they are being
>>> called as part of a process vs. as an individual service.  If the
>>> "s" part of SOA cannot see or touch that, it cannot be part of the  
>>> RM.
>>>
>>>
>>>
>>> The chicken and egg discussion you bring forward is a requirement
>>> for those building services to strongly consider the business
>>> process when designing their service infrastructure.  Accordingly,
>>> it is not really part of the RM for SOA yet I agree that it is a
>>> very important consideration.
>>>
>>>
>>>
>>> For your messages to get to the list, you must join as a
>>> "applicant" rather than an "observer" as per OASIS process.
>>>
>>>
>>>
>>> Duane
>>>
>>>
>>>
>>> *******************************
>>>
>>> Adobe Systems, Inc. - http://www.adobe.com
>>>
>>> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>>>
>>> Chair - OASIS SOA Reference Model Technical Committee
>>>
>>> Personal Blog - http://technoracle.blogspot.com/
>>>
>>> *******************************
>>>
>>>
>>>
>>>
>>>
>>> From: Goran Zugic [ mailto:goran.zugic@semantion.com]
>>>
>>> Sent: Monday, December 05, 2005 8:47 PM
>>>
>>> To: Duane Nickull; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand;
>>> frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> Duane,
>>>
>>>
>>>
>>> Thanks for the response. Yes I would like to see the PPT. I hope
>>> you do not mind if I add few more thoughts related to services and
>>> business processes:
>>>
>>>
>>>
>>> Services participate in a business process to add some value to it.
>>> They can be governed and evaluated using business process metrics.
>>> One service can participate in many business processes and provide
>>> value to each of them according to the context within that process.
>>> As far as SOA is concerned it is as important to know what the
>>> service does, how it can be discovered, contacted, invoked,
>>> executed, etc. as it is to be able to use it within the process
>>> context, measure it and assess its value from the business process
>>> requirements point of view. SOA needs to avoid typical new
>>> technology chicken and egg syndrome, e.g. companies not producing
>>> services because there are no service friendly process definitions
>>> to use them and not having SOA friendly process definitions because
>>> there are no services to use. Services do not have to know if they
>>> will be involved in the process upfront, they will be contacted on
>>> demand according to the process script that is in effect, and they
>>> will be contacted, checked if available, passed the arguments,
>>> collected the response and according to their procedure left alone
>>> to wait for another call. The process execution engine however
>>> needs to invoke the service according to both service specific
>>> information and the process specific information.
>>>
>>>
>>>
>>> Having just the service specific information in a model covers only
>>> one part of the picture and I think it is fine as long as that
>>> model is a pure service model. However I find it difficult to
>>> understand that the SOA RM TC model is a SOA reference model when
>>> it does not include other concepts of SOA. Unfortunately it seems
>>> that we cannot get to the point where we could agree on a minimal
>>> set of supported SOA concepts by a model to be the SOA RM.  We do
>>> not have to and I do not want to argue with you or anybody else in
>>> SOA RM TC. I am just trying to see how our works can fit together
>>> in a most efficient way. We obviously need more time to better
>>> understand each others thoughts and ideas and I strongly believe
>>> that a constructive respectable discussion is helpful for everybody.
>>>
>>>
>>>
>>> By the way, do you know what I am supposed to do to get my messages
>>> to the SOA RM list. In spite of that I am the SOA RM TC observer I
>>> get a faliure notice whenever I send a note to the SOA RM.
>>>
>>>
>>>
>>> Goran
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>> From: Duane Nickull
>>>
>>> To: Matt MacKenzie ; goran.zugic@semantion.com ; MATHEWS, Tim ;
>>> Sally St. Amand ; frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Sent: Monday, December 05, 2005 5:02 PM
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> Goran:
>>>
>>>
>>>
>>> The service layer enables the process layer over top of it, however
>>> during runtime, services do not know if they are part of a process
>>> or being called individually (it would generally be a bad idea to
>>> try to maintain the overall state of a process within each service,
>>> although it could be done).  For maximum repurposing of services,
>>> it would be better to have the service as a simple slave to the
>>> processes that may use it.
>>>
>>>
>>>
>>> Accordingly, we made a decision that BPM, Orchestration,
>>> choreography is not a core part of the RM for SOA.  We generally
>>> seem to agree that many SOA implementations will include a layer of
>>> BPM over top.  We are only addressing the SOA model, not the model
>>> for the underlying or overarching layers.
>>>
>>>
>>>
>>> I have a PPT that explains this in more detail if you are interested.
>>>
>>>
>>>
>>>
>>>
>>> Duane
>>>
>>>
>>>
>>> *******************************
>>>
>>> Adobe Systems, Inc. - http://www.adobe.com
>>>
>>> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>>>
>>> Chair - OASIS SOA Reference Model Technical Committee
>>>
>>> Personal Blog - http://technoracle.blogspot.com/
>>>
>>> *******************************
>>>
>>>
>>>
>>> From: Matt MacKenzie [ mailto:mattm@adobe.com]
>>>
>>> Sent: Monday, December 05, 2005 12:51 PM
>>>
>>> To: goran.zugic@semantion.com; MATHEWS, Tim; Sally St. Amand;
>>> frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> Process orientation is only one of multiple potential integration
>>> with service oriented architecture.  SOA-RM is laying the
>>> foundation for durable architecture based on the core concept of
>>> service orientation.  We recognize that process oriented
>>> architecture is a natural fit with service orientation...but so are
>>> things like event orientation.
>>>
>>>
>>>
>>>
>>>
>>> -matt
>>>
>>>
>>>
>>> From: goran.zugic@semantion.com [ mailto:goran.zugic@semantion.com]
>>>
>>> Sent: Monday, December 05, 2005 3:36 PM
>>>
>>> To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand;
>>> frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better
>>>
>>>
>>>
>>> I think that SOA RM has done good job documenting well-known
>>> service related concepts and defining some new ones.
>>>
>>>
>>>
>>> I do not see other details besides service and service-related
>>> concept definitions in the current SOA RM committee draft right
>>> now. I look forward to seeing the completion of the model you are
>>> working on with the bottom-up approach.
>>>
>>> Business, business processes and collaboration aspects of business
>>> are important to address in the model what is not the case with the
>>> current content of the SOA RM committee draft. By a business
>>> process I mean a generic business process entity which has common
>>> components (activities, decisions, etc) and relationships between
>>> them that can be used to model a business process in any
>>> environment regardless of what business we support and technology
>>> we use. I agree with Sally that a link between business processes
>>> and services should be one of key requirements any SOA reference
>>> model should try to meet.
>>>
>>>
>>>
>>> I am not sure what SOA with services brings to business when the
>>> link between the business processes and services and overall
>>> business process semantics in the SOA context are not considered to
>>> be important aspects in a SOA-based reference model.
>>>
>>>
>>>
>>> Goran
>>>
>>> -----Original Message-----
>>>
>>> From: MATHEWS, Tim [ mailto:tmathews@lmi.org]
>>>
>>> Sent: Monday, December 5, 2005 12:34 PM
>>>
>>> To: 'Matt MacKenzie', 'Sally St. Amand', frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better "Componentization"
>>>
>>> Matt - I am not sure what point you are trying to make by this?  I
>>> agree with your premise of a bottom up effort, as this was one of
>>> the operating assumptions that was made from the beginning.
>>>
>>>
>>>
>>> But, I am confident it is the business environment that is
>>> independent from the reference model.
>>>
>>>
>>>
>>> TM
>>>
>>>
>>>
>>> From: Matt MacKenzie [ mailto:mattm@adobe.com]
>>>
>>> Sent: Monday, December 05, 2005 11:58 AM
>>>
>>> To: Sally St. Amand; frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better "Componentization"
>>>
>>> Sally,
>>>
>>>
>>>
>>> A reference model actually needs to be a bottom up effort.  We
>>> leave the ever so popular ?top-down? approach to folks like ebSOA J
>>>
>>>
>>>
>>> We?re creating a vocabulary and general understanding of what I
>>> hope we can call a discipline of computer science in the future.
>>> This means, we need a durable reference model that is not dependent
>>> on the current business environment.
>>>
>>>
>>>
>>> -matt
>>>
>>>
>>>
>>> From: Sally St. Amand [ mailto:sallystamand@yahoo.com]
>>>
>>> Sent: Monday, December 05, 2005 10:19 AM
>>>
>>> To: frank.mccabe@us.fujitsu.com
>>>
>>> Cc: soa-rm@lists.oasis-open.org
>>>
>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
>>> Better "Componentization"
>>>
>>>
>>>
>>> Frank
>>>
>>>
>>>
>>> This is in response to your request on last week?s conference call,
>>> if anyone has comments speak now. I also think that the recent
>>> comments on clarifying sections are a reflection of my issues with
>>> the specification.
>>>
>>>
>>>
>>> I agree with the majority of points made/described in ver 10. My
>>> issues are with what is not in this draft. Based on Fig 1 the Refe!
>>> rence Model is guided by Reference Architectures, Concrete
>>> Architectures, Profile & Related Models. They in turn account for
>>> requirements, motivation & goals. This is creating a Reference
>>> Model from the bottom up. I believe a Reference Model should
>>> reflect a top down approach.
>>>
>>>
>>>
>>>
>>>
>>> The Reference Model needs to reflect the environment, the strategy
>>> and the priorities of the business/mission/collaboration.  This
>>> will impact the construction of services. A service is a business
>>> task or activity that is realized through technology. The draft
>>> does a good job of describing how that realization happens. But it
>>> doesn?t provide a sufficient link between processes and services.
>>> The draft makes the point that the central focus of! SOA is the
>>> task of business function?getting something done. A business
>>> process is made up of tasks and activities to achieve a goal
>>> (getting something done). The concept of creating the service from
>>> the tasks and activities in a process is important. For example,
>>> where on the continuum of fine grained to coarse grained should a
>>> particular service be; this will affect interaction, reusability.
>>> The relationship between processes and services needs to be in the
>>> Reference Model.
>>>
>>>
>>>
>>> While I saw that there is a note saying the glossary is still in
>>> flux, since one of the objective of the Reference Model is a
>>> vocabulary, having less in the glossary might be a better option.
>>> Is semantic integration a guiding principle of SOA?
>>>
>>>
>>>
>>> With respect to conformance there needs to be business results.
>>> That is an SOA should provide demonstrable mission accomplishments,
>>> e.g. ROI, match a competitors distribution channel. SOA is not a
>>> technology. Conformance should provide operational accomplishments,
>>> these should be measurable.
>>>
>>>
>>>
>>> Sally
>>>
>>>
>>>
>>>
>>>
>>> !
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>

------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508



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