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] Service Consumer in RM or not?


All,

I was the guilty party that raised the concept of multiple RM documents
at the last telecom.  I did not mention any firm format for the second
document, specifically, I did not raise the issue of Service Consumer.
What I suggested was that there be a "core" document that concentrates
on a single service, as we have been doing.  Then there be a second RM
document that expands on the "core" to include multiple services and the
abstract implications of having multiple cooperating services.  It was
further suggested (I don't remember who) that those who favor a second
document conceive and send to the list a TOC and/or content description.

This structure of multiple documents for a specification is not unusual
as a number of TCs have taken this approach.  

I believe that there is a consensus that the primary purpose of this RM
is to give developers of SOA specifications a model to guide them in
writing specific SOA specifications.  Additionally, there is a secondary
purpose, expressed in the early days of this TC that we would give a
definitive exposition or at least, a definition, of an SOA, since there
is confusion in the outside world on what an SOA is.  

There seems to be a genuine and legitimate difference of opinion on what
the model contained within this RM should address to support these
future specification writers.  I don't think that any would argue that
multiple services and the consequences for an SOA are not important to
the writers of SOA specifications beyond the simplest of specifications.
The question is whether an RM that concentrates on a single service
satisfies the goal of providing a reference model for the writers of
specifications for complex SOA scenarios.

Don

On Tue, 2005-06-07 at 06:59 -0400, Chiusano Joseph wrote:
> Sorry Matt - I thought we had reached this decision. No
> problem...looking forward to exploring them on our next call.
>  
> (Hoping we can release a spec sometime before the year 2010 haha:)
>  
> Joe
> 
> 
> ______________________________________________________________________
> From: Matthew MacKenzie [mailto:mattm@adobe.com]
> Sent: Mon 6/6/2005 10:59 PM
> To: Chiusano Joseph
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Service Consumer in RM or not?
> 
> 
> I do not recall these decisions being made, I only recall that we
> agreed to explore them on our next conference call. 
> 
> 
> -Matt
> On 6-Jun-05, at 8:12 PM, Chiusano Joseph wrote:
> 
> > To clarify: We already achieved consensus on the service consumer
> > aspect of this on our last conference call. 
> >  
> > That is, we decided that:
> >  
> > (1) Although a service orientation RM (which we decided Figure 2-1
> > represents) does not require a service consumer, a service-oriented
> > architecture RM does.
> >  
> > (2) We would develop a SOA RM that extends the current service
> > orientation RM as part of our work, and that SOA RM would include
> > (at a minimum) a service consumer in addition to the service
> > orientation RM.
> >  
> > (3) This inclusion of a service consumer would not be a reference
> > architecture, but rather a reference model - namely, a SOA reference
> > model.
> >  
> > Thanks,
> > Joe
> > 
> > 
> > ____________________________________________________________________
> > From: Duane Nickull [mailto:dnickull@adobe.com]
> > Sent: Mon 6/6/2005 7:39 PM
> > To: peter@justbrown.net
> > Cc: 'SOA-RM'
> > Subject: Re: [soa-rm] Service Consumer in RM or not?
> > 
> > 
> > 
> > Hi - I'm back!!
> > 
> > Comments inline:
> > 
> > Peter F Brown wrote:
> > 
> > >1) A service is an event
> > >
> > DN - a "service invocation" is an event. The "service" itself is not
> > an
> > event IMO, it is an invoke able entity..
> > 
> > >representing a collaboration between two parties
> > >for the use of defined resources: a "service RM" would be concerned
> > with
> > >representing both parties (provider and consumer), the duality of
> > their
> > >interaction through the event and the use of resources...
> > >In this approach:
> > >- service consumer would definitely be in, as one side of the
> > event-based
> > >duality (provider<>consumer);
> > >- a further level of abstraction can be modelled, that of "agent",
> > to
> > >highlight the shared properties of both provider and consumer. In
> > this
> > >manner, it would be easier to answer the problem "how do we model
> > the
> > >situation where a service provider can also be a consumer, and
> > vice-versa?".
> > >They are both agents. Whether they are consumers or providers would
> > >therefore be modelled as a "role" in agent.
> > >
> > >2) A service is a "directed collaboration" between two parties:
> > directed in
> > >the sense that one party provides a service to another: a "service
> > provision
> > >RM" would only be concerned with one side of the duality,
> > representing the
> > >service provider, irrespective of whether the service is used, or
> > whether
> > >there is a consumer at the end of the "pipe"...
> > > 
> > >
> > I would like to call for a vote on this too to put it to bed for
> > once an
> > all.  My assertion = If I architect something with a service, a
> > consumer
> > does not have to be present for it to be "service oriented".   Nor
> > do
> > messages, networks, signals, pings, security, encryption etc etc.
> > This
> > is much the same as stating that a "message" does not have to be
> > sent in
> > order for it to be a "message".  It can exist with or without being
> > transmitted.
> > 
> > If we do go the way of the service provider and service consumer,
> > this
> > could be done in an illustrative (non-normative) manner in the RM or
> > (and I favor this idea) as part of a reference architecture.  If we
> > do
> > vote to include the SC, we then have to open up the RM to everything
> > else that follows which means that it won't be a RM, it will be
> > architecture.
> > 
> > I had hoped we could gain consensus on this and avoid a vote however
> > I
> > feel a vote may be inevitable.
> > 
> > BTW - has anyone else noticed that the list is very slow today? It
> > took
> > 5 hours for my last message to come back to me via this list?
> > 
> > Duane
> > 
> > 
> > 
> > 
> 
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com



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