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


Title: RE: [soa-rm] Identity
<Quote>
A service definition/specification defines the service Type (design/development time). It defines an encapsulated piece of software that offers its functionality through well defined end-points.
</Quote>
 
Could you please relate this more closely to the notion of identity? (since you jump into runtime in the next paragraph, and appear to be finished with the design-time aspect at this point) I don't believe a service has any type of identity at design time, in the traditional sense of the term (who is executing/invoking the service)
 
<Quote>
At runtime we should also consider the existence of state associated with the service (NOTE: state here refers to the information that the service is managing at runtime, not the requester-provider conversation state).
</Quote>
 
Could you please relate this more closely to the notion of identity?
 
Same for examples.
 
Thanks,
Joe
 

Joseph Chiusano

Booz Allen Hamilton

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


 

From: George Ntinolazos [mailto:georgios.ntinolazos@stratasoftware.com]
Sent: Wed 5/11/2005 9:36 AM
To: 'Duane Nickull'
Cc: 'SOA-RM'
Subject: RE: [soa-rm] Identity

To understand better the concept of identity, I think we need to make a
distinction between design-time and runtime.

A service definition/specification defines the service Type
(design/development time). It defines an encapsulated piece of software that
offers its functionality through well defined end-points.

At runtime we should also consider the existence of state associated with
the service (NOTE: state here refers to the information that the service is
managing at runtime, not the requester-provider conversation state).

To use an example, image a bookTicket service. This service has a service
definition expressed as a service contract (syntax, semantics etc). We can
deploy this same service (definition + implementation) and configure it to
manage different set of data. One service to manage the US tickets and one
to manage Europe/Asia. Looking at just the service description these
services seem to be equivalent. 

While the service description is important, so is the information/data
managed by the service at runtime. The key difference between development
time and runtime is that the runtime service has state. Since we can refer
to the service and the state together, we could call the runtime service, a
service object or service instance. It is these service objects that
actually have an identity.

George

-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: 10 May 2005 16:17
Cc: SOA-RM
Subject: Re: [soa-rm] Identity

What about from the Service providers point of view?  I definitely think
that identifying service consumers is not required in all cases, however
service providers have some form of implied identity.

The expedia example however does raise the question of would you use the
site to book a trip if you could not identify it was Expedia's site? If
just before you were going to give them your credit card, it jumped to a
different domain name?   Identity is implied by the URL resolution
process, which in itself places a great deal of security requirements on
the entire DNS process.

I am not thinking so much in terms of a service consumer as I am the
service provider.  Ajay made the point in his presentation that it would
be mandatory to be able to ascertain to some degree that the service you
are going to use is the one you want to use.

I would at least like to mention it in the RM as an aspect (perhaps just
in passing).  To me, the Service description is probably where a service
provider could make a statement of claim regarding their identity and
perhaps supply a token, even as simple as a URI, to provide proof.

anyone else?

Duane

--
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Chair - OASIS Service Oriented Architecture Reference Model Technical
Committee -
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  -
http://www.adobe.com/enterprise/developer/main.html
***********






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