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


In keeping with the previous discussion, we didn't go out of our way 
to define the service consumer (or service provider) as a key concept 
but the term enters the discussion in Section 2.1 and is used as 
appropriate throughout the document.  In keeping with KISS, I think 
it works well that way :-)

Ken

At 03:32 PM 12/6/2005, Rex Brooks wrote:
>I've always contended that service consumer was necessary, but in 
>terms of this particular discussion, if the object is to avoid 
>adding a Service Consumer to the equation of the RM, we could call 
>this Role "Intermediary," if "Broker" is also verboten. However, in 
>terms of keeping it simple, sweetheart, it's still a consumer. I 
>don't expect to see a consumer in the RM, nor am I arguing to open 
>up the issue. I have accepted it and prefer moving on to deliver a 
>spec sooner rather than later.
>
>Ciao,
>Rex
>
>At 2:36 PM -0500 12/6/05, Metz Rebekah wrote:
>>I agree with Ken.  If we return to the definition of service again; 
>>there is some <entity> that provides the service.  Say my brother 
>>Isaac has a falafel stand and offer a falafel service.  There are 
>>several ways to define the 'falafel service,' but they are 
>>ancillary to the point I am trying to make here.  Isaac is the 
>>service provider.  If I want to avail myself of a falafel, I 
>>consume the service.  If I don't really want to get up off the 
>>couch and walk to the falafel stand, I could choose instead to use 
>>a delivery service like 'Dr. Delivery' to provide the falafel 
>>instead. I am still a consumer.  However, I am a consumer of the 
>>delivery service which provides its own unique service.  >From my 
>>perspective, the delivery service does in fact function as a broker 
>>to multiple services - say to falafel, pizza, Chinese, Thai, 
>>Indian, and burgers but that is the service I wanted.  Nonetheless, 
>>that function does not negate the role that the delivery played 
>>when interacting with the falafel service - that of a service consumer.
>>Essentially, a broker is a compilation of at least two distinct 
>>interactions - one in which it plays the consumer and one in which 
>>it plays the provider.
>>Rebekah
>>
>>Rebekah Metz
>>Associate
>>Booz Allen Hamilton
>>Voice:  (703) 377-1471
>>Fax:     (703) 902-3457
>>
>>
>>From: Ken Laskey [mailto:klaskey@mitre.org]
>>Sent: Tuesday, December 06, 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/>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/>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: <mailto:dnickull@adobe.com>Duane Nickull
>>To: <mailto:mattm@adobe.com>Matt MacKenzie ; 
>><mailto:goran.zugic@semantion.com>goran.zugic@semantion.com ; 
>><mailto:tmathews@lmi.org>MATHEWS, Tim ; 
>><mailto:sallystamand@yahoo.com>Sally St. Amand ; 
>><mailto:frank.mccabe@us.fujitsu.com>frank.mccabe@us.fujitsu.com
>>Cc: <mailto:soa-rm@lists.oasis-open.org>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/>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/>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                                              /
>>----------------------------------------------------------------------------------
>>--
>>---------------------------------------------------------------------------------
>>   /   Ken Laskey \
>>  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
>>  |    7515 Colshire Drive                    fax:      703-983-1379   |
>>   \   McLean VA 22102-7508                                              /
>>----------------------------------------------------------------------------------
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309

--
      ---------------------------------------------------------------------------------
   /   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]