Re: [soa-rm] Identity

[Duane Nickull <dnickull@adobe.com>]

Ajay:

Did you read the requests from members for the presentation you gave in 
NO?  We wish for you to please submit it to the Kavi under the member 
submissions folder.

Thanks

Duane

Ajay Madhok wrote:

>Thank you, George for bringing this up.
>
>I will mail you my considered view on this over the weekend as the I am on
>the road the next two days.
>
>But location or a concrete identifier (such as a URI or a phone number) can
>no longer be a proxy for an Identity. Having an abstract, persistent
>identifier is the key and I will put forth my view for your consideration.
>
>       Cheers,
> 
> 
>=ajay
>
>-----Original Message-----
>From: George Ntinolazos [mailto:georgios.ntinolazos@stratasoftware.com] 
>Sent: Wednesday, May 11, 2005 3:36 PM
>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
***********