P. 1
Gap Analysis

Gap Analysis

|Views: 465|Likes:
Publicado porss2315

More info:

Published by: ss2315 on Jan 14, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





A UDDI (Universal Description, Discovery, and Integration) repository [UDDI-A] stores metadata about the
capabilities and interfaces of services. Service metadata is published to UDDI (either manually or by a service
deployment tool), and the repository can be queried to discover services that match with specified capabilities and
attributes. Query results are returned in the form of URIs that point to the metadata (usually in the form of a WSDL
document) of each service satisfying the query.

Metadata about a service needs to be provided in a specific format within the UDDI registry – such as the physical
address/location of a service, contact phone number, the category of a service (generally specified based on a Tax Code
ID or a Dun and Bradstreet (DUNS) number), etc. Such metadata is therefore specifically aimed at business services,
and extending the data structure to register and provide support for services in another domain (such as scientific
computing) may lead to incompatibilities. It is also not obvious how such extensions should be undertaken, and whether
vendors are likely to support them. Further, search to a UDDI registry is based on a unique key, and capability based
search is difficult to undertake. Another significant issue is the management of “top level” UDDI registries – currently
undertaken by major vendors, such as IBM, Microsoft etc. Although the vendors indicate that replicated registries are
likely to have identical content, there is no obligation for this to be the case. Therefore, there is likely to be inconsistent
replication of UDDI registries, which may be further compounded by particular organisations managing their own
“private” registry services. Therefore, although the approach adopted in UDDI is a useful one, the current
implementations and availability of this technology may be limiting for supporting Grid Services.


Alternative approaches to support registries include the Lightweight Directory Access Protocol (LDAP), which defines
a network protocol for querying and updating X500-type directory servers. Although it does not offer a data model rich
enough to encode Grid Services, it does have the advantage that many implementations are available (for Linux,
Windows, and in programming languages like Java), and the current version of Globus MDS [GlobusMDS] utilises it.
The primary factor against the adoption of LDAP is its limited scalability over a distributed environment.

A number of UDP multicast based approaches also provide the capability to support registry services, examples include
Jini [Jini], the IEEE SLP (Service Location Protocol [SLP]), and the Service Discovery Service from Berkeley
[NinjaSDS]. All of these approaches rely on the use of multicast requests to discover a registry service(s), and therefore
are often restricted to a limited part of the network (using a limited number of hops/Time To Live) – and unlikely to
scale to the Internet and the Grid. Jini provides a useful approach for enabling Java classes to expose and publish their
interfaces with a “look-up” service, along with proxy objects that enable subsequent invocation of the Java classes. The
proxy object needs to be downloaded by the client to initiate a session, and can thereby enable a number of different
protocols to co-exist. The approach relies on the assumption that all services must define their interfaces using the Java
type system, and also that subsequent search for suitable services in the registry (the lookup service) is restricted to
these data types. Jini provides the notion of “leasing” (or soft state), which is also now available in OGSA. The Service
Location Protocol uses a series of filter expressions to identify the location, types and attributes of a service within a
part of the network. The query language is simpler than Jini’s. The Service Discovery Service also uses the same
principles as SLP and Jini, and support a simple XML-based exact matching query type. The particular advantage
offered by SDS is the use of secure channels to discover and publish service metadata. Furthermore, SDS servers can be
organised into a hierarchy, enabling an administrator to analyse (and subsequently improve) performance at particular
points in the hierarchy. Each SDS node in the hierarchy can hold an aggregated index of the content of its sub-tree.

The original version of this contribution can be found in the appendix, section A.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->