[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Service Consumer in RM or not?
Duane: I'm not actually advocating one or the other approach (I might even own up to being a little confused), with or without "service consumer", but tried only to encapsulate the different views that came out of the meeting. Running the whole through my sluggish brain, I suppose I do have to come down one side or another, and I come up with: I agree with your refinement that a service is an invokable event, rather than an event per se. Invokable, not invoked - I think that is your point. It underlines intent. [Careful with your analogy with "message" however: There does need to be an intention for a content to be transmitted to another entity for it to be considered as a message, otherwise it is simply a document: I would agree however that it does not need to have been successfully transmitted or received, for it to be a message. Again, it underlines intent.] Equally, and by analogy, a service does not require for there to be a consumer, in order to be considered as a service. We need therefore to establish only an intention and capability to provide a service (implicitly, providing it to another entity, the consumer): hence service-oriented. The RM should thus be the model from which any service-oriented architecture can be derived, no more. I would still argue that service consumer and service provider are two roles of the same abstract entity, "agent"; BUT accept that this is not within scope of the SOA-RM. I think your suggestion of including this as another non-normative text might help to satisfy those who wish nonetheless to answer the concern about situations in which a provider may in some situations be a consumer or vice-versa. -Peter -----Original Message----- From: Duane Nickull [mailto:firstname.lastname@example.org] Sent: 07 June 2005 01:40 To: email@example.com 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