Why is a Services Registry needed in a service-oriented application architecture?
A registry is usually identified as one of the first requirements of SOA adoption.
In simple terms, a registry is a catalog or index that acts as the system of record for the services within an SOA.
A services registry is not designed to store the services themselves. It rather indicates their location by reference. Also, having a centralized catalog of services is of importance from an organizational perspective because it enables the easy discovery, reuse, and management of services. A robust registry is an important component of any SOA governance solution.
2008 © 2008 SAP AG. All rights reserved.
169
Figure 131: Demand for a Services Registry
Another important issue is the interoperability of the registry with other components of the SOA infrastructure. OASIS provides a platform-independent standard for registry interoperability known as UDDI (Universal Description, Discovery, and Integration). UDDI defines a Web services-based programming interface that allows different consumer applications, tools, and run-time systems to query the registry, discover services, and interact as required to provide management and governance capabilities.
UDDI is the most commonly adopted standard and ensures the greatest degree of compatibility with other products in the environment. The Enterprise Services Repository contains the model metadata along with the interfaces, its operations and global data types.
Services Providers implement the services using ESR metadata and then publish these implemented services in the Services Registry. Consumer tools in turn access the Services Registry to find the centrally published services with all the required information to consume it.
Figure 132: Services Registry – Concept
To simplify the search, services are grouped and organized in taxonomies. This Services Registry information is published in an open standard way complying with the UDDI V3.0 requirements. The Services Registry can interoperate with other UDDI registries like Systinet.
Figure 133: Interoperability Services Registry – UDDI V3.0 Server
2008 © 2008 SAP AG. All rights reserved.
171
Interoperability with the third party UDDI V2 server can be achieved as seen in the following diagram. Typical scenario steps are:
• Install Services Registry
• Install third party Application Server with is built-in service registry
• Unplug SAP NetWeaver's UDDI Server & Plug-in the third party Service Registry
• Pre-load tModels and perform API tests
• Publish enterprise services from SAP AS ABAP system on to the third party UDDI server
• Consume the published services from a Web Dynpro application
The Services Registry has a large number of centralization-related benefits. It enables governance or improves governance for the following, for example:
Services management Standardization Classification
Definition of procedures
Other advantages are the possibility to centrally define and expose functionality for configuration, documentation, creation of global taxonomies, and versioning of Web services. In addition, the consumer is able to configure the Web service dynamically at runtime, which provides additional flexibility in terms of performance and service level agreements.
Figure 134: Services Registry in Detail
Figure 135: Services Registry
To access your SAP NetWeaver PI 7.1 Services Registry front-end application, you have to access first your SAP AS Java server home page and select Services Registry. The Services Registry will start in a separate window.
2008 © 2008 SAP AG. All rights reserved.
173
Figure 136: Access to the Services Registry in SAP NetWeaver PI 7.1
1. Access the Java Engine home page: http://<full qualified hostname>:<HTTP port>
2. Choose Services Registry
Figure 137: Services Registry – UDDI Server Components
The Services Registry implements UDDI Version 3.0 APIs plus three sets of proprietary interfaces in Java and ABAP:
Classification Services
Additional Services Registry APIs for Java and ABAP
Figure 138: Services Registry – Classification Service
The Classification Service
• Supports classification and browsing in the user interfaces.
• Provides the metadata on different classification systems.
• Provides the content of each classification system, including possible values.
• Supports the dynamic addition of values to a classification system.
2008 © 2008 SAP AG. All rights reserved.
175
The following lists the supported classifications in the Services Registry:
• Deployment unit
– Part of the enterprise service-oriented architecture metamodel . – Contains a set of process components; for example, SP_HR.
• Process component
– Implements business processes and allows their functions to be used as services.
– Contains one or more related business objects.
– Can be used in different integration scenarios; for example, HR Compensation Management.
• Business object
– A set of entities with common characteristics and common behavior representing well-defined business semantics.
– The set of entities is generally accepted in the business world – for example, HR Salary Adjustment.
• Lifecycle status
– Informs customers of the development status of objects.
– Determines whether the customer can or cannot use a service and whether restrictions apply.
• Service Operation
– Part of the Enterprise Service Architecture metamodel.
– Sets of messages related to a single service action.
• Service Interface
– Group of operations in the Enterprise Services Repository
• Software Component Version
– Smallest shipment unit for design objects in the Enterprise Services Repository and for development objects in the relevant application system.
– Part of the software catalog in the System Landscape Directory.
SAP offers a Services Registry containing various SAP Enterprise Services including Cassification data. The Services Registry URL is http://sr.esworkplace.sap.com/. For more details and how to get a test-user for more check out the SDN - Explore Enterprise Services area at https://www.sdn.sap.com/irj/sdn/explore-es.