IBM WebSphere® Service Registry and Repository Frequently Asked Questions
1) What is the IBM WebSphere Service Registry and Repository?
WebSphere Service Registry and Repository is a system for storing, accessing and managing information, commonly referred as service metadata, used in the selection, invocation, management, governance and reuse of services in a successful SOA. In other words, it is where you store information about services in your systems, or in other organizations' systems, that you already use, plan to use, or want to be aware of. For example, an application can check the Registry & Repository just before invoking a service to locate the service instance best satisfying its functionality and performance needs. Registry & Repository also play a role in other stages of the SOA lifecycle.
Our view of a Registry & Repository encompasses:
2) What is a Service Registry?
A Service Registry contains information about services, such as the service definitions, interfaces, operations and parameters.
3) What is a Service Metadata Repository?
A Service Metadata Repository is a store to address the diverse nature of service usage. It stores service policies and other service metadata such as version, status, relationships and others that govern the service usage.
4) How do I know if I need the WebSphere Service Registry and Repository?
The promise of SOA depends heavily on the ability to share assets. Such sharing requires coordinated facilities for access and control. With SOA adoption, the increase in the number of services that an organization needs to track and manage becomes evident. Also, with adoption comes the recognition of a need for better processes to manage the lifecycle of services. A disciplined approach to lifecycle management, part of the overall governance, helps ensure that the design, development, deployment, and operation of services adhere to policies. In the most effective SOA deployments, governance processes are woven throughout all phases of the lifecycle. Governance addresses the need for financial transparency, the alignment between business and IT, and process control, as well as how these business imperatives are achieved. The right software tools can greatly facilitate governance. These are some of the primary indications on when one should consider WebSphere Service Registry and Repository as part of the SOA solution.
5) Why is WebSphere Service Registry and Repository so important to my business?
The WebSphere Service Registry and Repository is critical when deploying significant SOA projects because it enables you to:
6) What are the key features of the WebSphere Service Registry and Repository?
The WebSphere Service Registry and Repository plays a major role in all four phases of the SOA lifecycle (Model, Assemble, Deploy and Manage). It helps you:
*For details, please see the IBM SOA Foundation white paper (PDF, 226KB).
7) What kind of information can be stored in WebSphere Service Registry and Repository?
You can put WSDL files, XSDs, WS-Policy documents and any XML file in WSRR. We also support storing SCDL and BPEL documents. WSRR automatically derives the service related information from these documents like operations, interface, types etc. You can then add metadata to these physical as well as derived entities by using the classification system and/or properties (which are user-defined name-value pairs). You can also define relationships/dependencies between various entities e.g. between two services or between service and policies.
8) How is it different from UDDI (Universal Description, Discovery, and Integration)?
UDDI provides basic publish and discovery of Web service descriptions. It does not provide a standard repository capable of storing artifacts, nor governance capabilities for managing the end-to-end life cycle of the various types of artifacts related to services. UDDI has other limitations as well. For example, UDDI data model is restrictive which puts constraints on both the information that can be managed as well as the ability to support different usage models e.g. development, runtime, and management – this is due to the fact that the classification system used in UDDI is highly technical taxonomy which fails to capture the web service semantic that is required to fully exploit the potential of web services i.e. dynamic discovery, selection, and binding. UDDI also requires multiple communication exchanges to perform a single operation, which may not be suitable for all environments.
9) Is WSRR a Runtime or Development Time repository?
IBM views WSRR as relevant to overall SOA lifecycle in driving the service lifecycle. It is optimized for and primary interactions are for run-time operations. There maybe Find and Publish interaction at design/development/assembly stages to find a deployed service or update a service metadata to reflect it’s lifecycle state.
10) What's the level of effort needed to organize services in WSRR?
This is fairly minimal since the organization of services is browser based and intuitively aligns with how you want to view the services.
11) Does WSRR provide a workflow capability?
WSRR provides a state transition engine that enables service lifecycle capability. The more complete workflow/process engine is provided by IBM WebSphere Process Server. WebSphere Service Registry and Repository is integrated to WebSphere Process Server and leverages the process flows, as applicable to service lifecycle transitions.
For more information on WebSphere Process Server, please refer to: http://www.ibm.com/software/integration/wps/
12) Is there a standard way to interface to the registry?
WebSphere Service Registry and Repository provides both Java and Web services interface for searching, updating, creating and deleting service description and associated metadata.
13) Many products on the market build upon and extend UDDI to support additional functions needed for SOA implementation and management. Are we also following the same approach?
No. It is possible to address some of the UDDI problems by extending UDDI but that is an inefficient way of solving the problem. Moreover, there are emerging standards and classification systems that are better suited to the needs of service registries. WebSphere Service Registry and Repository will instead align with these focused standards. We will however integrate with UDDI and UDDI based registries using copy and synchronize approach.
14) What emerging standards are being published around Web Services and Service Registries? What are the emerging standards and classification systems?
IBM, Microsoft, HP and Intel recently published a roadmap for converging Web Services standards for resources, events and management, which will result in new specifications e.g. WS-ResourceTransfer and WS-EventNotification, and new versions of existing specifications e.g. WS-MetadataExchange. As far as classification systems are concerned, WebSphere Service Registry and Repository offers OWL-based user-defined semantic classifications on all parts of the object model, including operations, data types and interfaces.
15) Does that mean that WebSphere Service Registry and Repository will have a standards based Web Services interface?
That is correct. WebSphere Service Registry and Repository is a J2EE application that installs on top of a WebSphere Application Server. Persistence is provided by IBM metadata management technology (Metadata Server) which interacts with a Relational Data Base configured through the Application Server. WebSphere Service Registry and Repository provides both Java and SOAP APIs. Basic CRUD operations as well as governance operations and a flexible query capability based on XPath are provided through both APIs. The product also has a web-based user interface for users representing different roles to interact with the WSRR, supporting lookup and publish scenarios, metadata management and analysis scenarios, and functions that support SOA governance.
16) How does the WebSphere Service Registry and Repository integrate with other IBM products?
WSRR integrates with development tooling using an Eclipse plug-in to support lookup, retrieval and publishing of service metadata. The product will provide an ESB Mediation and Routing Node based on metadata query for WebSphere ESB and Message Broker respectively.
17) What is the roadmap of WebSphere Service Registry and Repository in relation to Web Services Gateway/UDDI in WAS?
The WebSphere Service Registry and Repository is a crucial part of the SOA foundation that fills governance needs by providing a registry for information (metadata) about services and the interaction of services with other SOA infrastructure elements. Not merely a governance tool, the WebSphere Service Registry and Repository also helps unlock the full potential of SOA by promoting the rapid integration of services. It supports service creation and access, publication of information about services - enabling software reuse - and subscription to services, speeding up enterprise-wide adoption of SOA. These capabilities are more focused towards SOA with optimizations for SOA runtimes and the evolving needs in SOA Governance along with service metadata needs. The WebSphere Service Registry and Repository with its more advanced capabilities, fostering reuse and leverage of services becomes core to SOA deployments. Web services gateway and UDDI within WAS are basic offering to enable base web services access. They will continue to function as they are offered today within WAS although the need for addressing some of the more advanced and evolving needs of SOA will quickly lead towards a WebSphere Service Registry and Repository. The WebSphere Service Registry and Repository will federate service endpoint information that may be residing in the UDDI within WAS so that the service information is consistent to access either within WebSphere Service Registry and Repository or just the UDDI and WS Gateway. Increasingly the ESB (WebSphere ESB or the Message Broker) will function as the gateway to all the services within a SOA deployment. Overtime, the capabilities of UDDI will be subsumed with the WebSphere Service Registry and Repository and the Web Services Gateway within WebSphere ESB.
18) What is the interaction, linkage and roadmap of IBM Business Partners focused SOA Business Catalog and the SOA Foundation component - IBM WebSphere Service Registry and Repository?
IBM WebSphere Service Registry and Repository will be used across the enterprise SOA infrastructure to raise the visibility of reusable services fostering reuse. There will be situations where the services internally within the enterprise may not be complete to drive the SOA solution and there may be a need to access other services provided by IBM SOA partners. This is where the linkage between the internally focused WebSphere Service Registry and Repository with the external SOA Business Catalog will be beneficial for IBM SOA offering. Overtime the WebSphere Service Registry and Repository may not only link to the external SOA Business Catalog but also host these services (Plans subject to change). This interaction and linkage along with the roadmap is key to understand when business partners are building assets towards the SOA Business Catalog. The business partners who have services - and repositories today can work with IBM to interact with the IBM WebSphere Service Registry and Repository solution, so that customers will see the benefit of an IBM solution - and can consume it that way.
19) Are there other IBM products that will help me get the most out of my WebSphere Service Registry and Repository?
Yes, typical patterns in SOA leads to the following complimentary products:
20) What is the difference between a registry, catalog and a repository?
A registry is an authoritative store of information that relates to a particular task at hand. Registries are typically built for a particular purpose such as a "gift registry".
A repository stores assets. Repositories are built for the specific kind of assets they are meant to hold and the modes of interaction they must support. Databases, file systems, and content management systems are all repositories of one sort or another, and they are all tailor-made for their specific requirements.
A catalog is where you advertise – For ex, IBM SOA Business Catalog advertising IBM SOA Business partners services.