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] Types of Services (RE: [soa-rm] Definition of "Service Consumer")

Inevitably, there is still a notion of discovery within the dll as a
service example.  However, unlike a UDDI or RMI registry, this type of
service presupposes some type of OOB knowledge or exchange for that
discovery to occur.  I would ask then, whether our the RM should
identify the concept or act of discovery?





Rebekah Metz


Booz Allen Hamilton

Voice:  (703) 377-1471

Fax:     (703) 902-3457



From: Matthew MacKenzie [mailto:mattm@adobe.com] 
Sent: Monday, April 11, 2005 12:16 PM
To: Christopher Bashioum
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition of
"Service Consumer")


A dll is just an object library. It may look like this: 


UUIDGenerator { 




That looks like a service to me. You see, it doesn't matter how services
are offered, as long as they are offered in a way that is appropriate
for their environment. Some people will build SOAs that use Java classes
and rely on rmiregistry for advertisement, whilst others will use UDDI


An SOA is an SOA regardless of the physical boundaries it does or does
not cross. 




On 11-Apr-05, at 9:04 AM, Christopher Bashioum wrote: 


	But I thought we agreed earlier on that advertisement was an
important part of the SOA model - how would a dll advertise?  Through
the registry of a given OS, but is it available to handle requests from
outside the given OS?  (I'm obviously not an expert on dlls ; ) 


	Intuitively, I am bothered by the idea that a dll can be a
service within an SOA.  It is more of a gut thing.  Since there is no
definitive SOA RM (that's what we are in the process of creating), I
have no basis for my feeling other than that all of the SOA
implementations I have looked at span process and machine boundaries. 


	I thought Microsoft considered the .net environment to be SOA,
but I have not heard them talk about dlls as SOA.  Again, I am no expert
in .net, but I thought .net got into the cross-machine boundaries,
wherease .dlls are limited to the given OS. 


	From: Matthew MacKenzie [mailto:mattm@adobe.com] 

	Sent: Monday, April 11, 2005 11:47 AM 

	To: Christopher Bashioum 

	Cc: soa-rm@lists.oasis-open.org 

	Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition
of "Service Consumer") 


	A .so or .dll may actually be a service within an SOA, yes. 


	I am balking at the idea that a service requires a request
bearing a message for either input or output. I am worried that by doing
this we are just defining WSDL without an XML binding :-) 




	On 11-Apr-05, at 8:36 AM, Christopher Bashioum wrote: 


	But doesn't this leave open an SOA being just a form of OO?
Would a C++ library be an SOA?  Could you elaborate on your use case-
maybe that will help me understand better.  In particular, i'm wondering
about the "automatically perform" portion.  This may be a difficult
area, because we don't want to get too concrete, but at the same time we
shouldn't try to be so abstract that anything goes.  


	Maybe we can put in a placeholder for the message or bus
mechanism, and see if it can drop out of the RM later or if it begins to
show itself as an essential part of the RM (at which time we can decide
what to call it). 


	From: Matthew MacKenzie [mailto:mattm@adobe.com] 

	Sent: Monday, April 11, 2005 11:27 AM 

	To: Christopher Bashioum 

	Cc: soa-rm@lists.oasis-open.org 

	Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition
of "Service Consumer") 


	A service is merely something that performs some task(s) on
behalf of / for a consumer. Defining the mechanics of how the service
knows what or when to do is, to me, not in scope for SOA-RM. 


	I envision services residing within an SOA that automatically
perform services on behalf of a dynamic set of consumers based on their
own determination of the requirement for a service to be rendered. I
want this kind of use case to be recognized within the reference model
without needing to explicitly spell it out. 




	On 11-Apr-05, at 7:27 AM, Christopher Bashioum wrote: 


	Ken and Joe, 


	do all services have a 2-way communication mechanism, or is it
possible to have a service that just consumes messages (or just sends
messages)?  The reason I am asking, is that it looks like all the
interactions mentioned so far involve a request and a response, but I am
wondering about the idea of events or broadcasts.  




	From: Ken Laskey [mailto:klaskey@mitre.org] 

	Sent: Monday, April 11, 2005 12:34 AM 

	To: Chiusano Joseph 

	Cc: Christopher Bashioum; soa-rm@lists.oasis-open.org 

	Subject: Re: [soa-rm] Types of Services (RE: [soa-rm] Definition
of "Service Consumer") 


	Let me suggest the following: 


	A data resource is a source of content. It accepts a request and
returns a value or set of values in response. The return can be an
entity (such as a particular schema), an attribute of an entity (such as
when the schema was last modified), or any numerical or textual value or
set of values. The content can be static objects stored in some
repository or dynamically generated through the use of a processing
resource. Data about a missile that is stored in a database is content.
The weather forecast for tomorrow is content generated from a weather
simulation. In a net-centric environment, the requester does not know
the format from which the response is retrieved or how it is generated. 


	A processing resource is one that accepts a task and return a
status indicating the extent to which the task was completed and
information on how the state of entities changed as a result of the
processing. One or more processing resources may be invoked as part of a
process of submitting a query and being returned a response. From the
standpoint of a user (either human or machine), it is unimportant what
combination of data and processing resources are invoked as long as the
request is satisfied. 


	Services interact with (i.e. use, invoke, access, ...) these




	On Apr 10, 2005, at 2:00 PM, Chiusano Joseph wrote: 


	I wonder if the roles a service can play - or, perhaps one can
say, the 

	general types of services that can exist - have any bearing on
our RM at 

	all, in an indirect way. 


	Put in simple terms, one may say that there are - in general - 3

	overarching "types" of services. These correspond to 3 of the
layers of 

	the general "integration stack" (data, application, and


	(1) Data-Oriented Service: Primary role is to accept and process

	or provide data based upon a request. 


	Two general types: 


	(a) Data Processor*: Accepts as input a set of data, processes

	data, and (optionally) sends a response. The response may simply
be an 

	acknowledgement, or another set of data to be processed by the



	Ex: Simple form acceptance service, such as a loan application

	service acting on behalf of multiple banks (routes to proper
bank and 

	sends back acknowledgement to form submitter) 


	(b) Data Provider: Provides streaming data, or a set of data



	Ex's: RSS news feed (streaming data), stock quote (set of data

	request - given stock ticker symbol) 


	*need better term - using this for illustration purposes only 

	**using term "requester" for now since we have not established

	perferred term 


	(2) Application-Oriented Service (aka "Function-Oriented

	Primary role is to accept a command and carry out processing
based on 

	that command, in a singular fashion (i.e. does not invoke other 



	Ex's: Inventory verification service (accepts item #, responds

	whether or not it is in inventory), shipment cost calculation


	(3) Process-Oriented Service: Similar to Application-Oriented

	but invokes other services in carrying out its processing (i.e.

	embodies the definition of an overarching process). 


	Ex: Order processing service (checks customer credit, checks

	does shipment cost calculation, etc.) 






	Joseph Chiusano 

	Booz Allen Hamilton 

	Visit us online@ http://www.boozallen.com 


	-----Original Message----- 

	From: Christopher Bashioum [mailto:cbashioum@mitre.org] 

	Sent: Thursday, April 07, 2005 12:49 PM 

	To: soa-rm@lists.oasis-open.org 

	Subject: RE: [soa-rm] Definition of "Service Consumer" 


	When we talk about service consumer vs. provider in this 

	sense, I think we need to separate the "static" entity from 

	the dynamic role that said entity plays. A given entity can 

	be both service provider (in which case it publishes it's 

	service description) and service consumer (in which case it 

	binds to another service provider in order to accomplish its 

	own service). 


	So...to re-word your statement a little: An entity that binds 

	with a service is playing the role of service consumer. 


	-----Original Message----- 

	From: Vikas Deolaliker [mailto:vikas@sonoasystems.com] 

	Sent: Thursday, April 07, 2005 12:21 PM 

	To: 'Frank McCabe'; soa-rm@lists.oasis-open.org 

	Subject: RE: [soa-rm] Definition of "Service Consumer" 


	Using the publish/find/bind framework of SOA... 


	The entity that publishes is certainly not the consumer. The 

	entity that 

	finds may or may not be the consumer but the entity that 

	binds is certainly 

	the consumer. 


	So an entity that "binds" with a service would be the closest 

	to a service 





	-----Original Message----- 

	From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] 

	Sent: Thursday, April 07, 2005 9:00 AM 

	To: soa-rm@lists.oasis-open.org 

	Subject: Re: [soa-rm] Definition of "Service Consumer" 


	There is a distinction between the software *entity* 

	(agent/component/J2EE bean/.../) that interacts with a 

	service in order 

	to achieve some goal, and the person or persons for whom that 

	interaction is taking place. 


	The reason that this distinction is important is similar to the 

	distinction between a service interface and the service itself: 

	accessing your bank account from an ATM or on-line will use

	interfaces but ultimately all use the same service. 


	Here is an example of why its important: the appropriate 

	business logic 

	to apply to a service request will depend on many factors: 

	the means by 

	which the request was delivered, the request itself and the 

	person (or 

	persons) for whom the request was made. This last aspect is 


	independent of mode of requesting and is purely



	Incidentally, the above definition: "an agent that interacts
with a 

	service in order to achieve a goal" seems to be a reasonable 


	of a service requester. 


	On Apr 7, 2005, at 7:23 AM, Gregory A. Kohring wrote: 




	OK, here a fewer other choices which might be deemed more 



	Service Consumer: 


	1) End-user of a service. 


	2) An agent which, acting on behalf of its owner, uses a


	3) An entity which utilizes a service 


	4) An entity which consumes the product or information produced
by a 



	Note all of these definitions depend upon the definition of the 

	term "service". Have we agreed on this already? Perhaps we

	start there first... 


	-- Greg 


	Matthew MacKenzie wrote: 


	I think services deserve respect, lets try not to exploit them

	Gregory A. Kohring wrote: 




	Perhaps one should use a somewhat broader definition 

	which captures 


	the human user as well: 


	Service Consumer: An entity which exploits a service. 


	-- Greg 


	Thomas Erl wrote: 


	Now that we've decided on the term "service consumer" it may be 

	useful to formally define it. The term "consumer" is used by the

	WS-I Basic Profile wherein it is simply defined as 

	"Software that 


	invokes an instance." 








	G.A. Kohring 

	C&C Research Laboratories, NEC Europe Ltd. 





	Ken Laskey 

	MITRE Corporation, M/S H305 phone: 703-883-7934 

	7515 Colshire Drive fax: 703-883-1379 

	McLean VA 22102-7508 

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