OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

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

Subject: Re: [wsdm] [UPlat] definitions


More thoughts from the OGSI world.

On 16/10/03 22:41, "Sedukhin, Igor S" <Igor.Sedukhin@ca.com> wrote:

> Identification/Identity
> Identification is a way to represent that one element is same or different
> than the other without necessarily looking at the contents or definition of
> the element. Applied to Web resources in general, as defined by W3C, a Uniform
> Resource Identifier (URI) can be used to represent the identity of a Web
> resource. Applied to Web services, every element which Web service description
> is composed of (service, interface, endpoint, location, etc.), is required to
> be identifiable by a URI. Such URI must be unique by definition. Identity is
> not required to be an addressable location, so a dereferencing mechanism may
> be required to actually locate the corresponding resource.
> Manageable resources need to be uniquely identified for the manager to tell
> one from the other and also to consistently refer to. Therefore a standard
> representation of a unique identity is required.

In OGSI a Grid Service Handle (GSH) is a URI and for all time refers to
exactly one service instance. However, if I have two different GSH's they
MAY refer to the same service instance or different instances. We spent a
lot of time coming to this position with several use cases for not requiring
an isomorphic mapping.

OGSI does not mandate a particular handle scheme, only defines a set of
properties, like above. Any handle scheme you devise would need to add
isomorphic properties. The challenge then becomes defining "sameness". With
physical resources, it is relatively easy, but with services things become
more fun.

> Registration/Discovery/Location
> Registration is a method of advertising an existence of an element so that it
> can be discovered. Discovery is a method of locating an existing element so
> that it can be used or operated. Discovery can be based on a selection
> criteria or simply a name or identity of an element. Location is a method of
> obtaining an address of an element. For example, location may mean translating
> an identity of an element into an address of an existing useable element. In
> the Web services sense, registration, discovery and location can be
> represented by a set of operations and schema which may be implemented by a
> Registry. A Web service can register itself or can be registered by a third
> party by sending a request to the Registry. A Web service can be discovered by
> sending a request to the Registry. The Registry can return the description of
> a Web service with location address included in a description or it may return
> the location address directly.
> Manageable resources have to be discoverable by the managers. Manageable
> resources exposed via Web services can be registered, discovered and located
> via a Registry.

OGSI has these concepts split. Discovery from a Registry (not explicitly
defined in OGSI) would provide a GSH. Location (a GSR) is then provided by a
HandleReslover. However, the two can be combined operationally without
causing any problems. I would separate the definition of Location out from
the others though. 


Take care:

    Dr. David Snelling <d.snelling@fle.fujitsu.com>
    Fujitsu Laboratories of Europe
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE

    +44-208-606-4649 (Office)
    +44-208-606-4539 (Fax)
    +44-7768-807526  (Mobile)

This e-mail has been scanned by Trend InterScan Software.

This e-mail (and its attachment(s) if any) is intended for the named 
addressee(s) only. It may
contain information which is privileged and confidential within the 
meaning of the applicable law.
Unauthorised use, copying or disclosure is strictly prohibited and may 
be unlawful.

If you are not the intended recipient please delete this email and 
contact the sender via email return.

Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
for changes made to this email after
it was sent. The views expressed in this email may not necessarily be 
the views held by FLE.

Unless expressly stated otherwise, this email does not form part of a 
legally binding contract
or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).

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