Product Report IBM WebSphere Service Registry and Repository (WSRR)

This report takes a look at the capabilities provided by the IBM WebSphere Service Registry and Repository. We explore the customization and extension capabilities provided to understand the support for the meta models inherent in Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports. By Lawrence Wilkes

Originally published in the March 2009 edition of the CBDI Journal

Independent Guidance for Service Architecture and Engineering

Product Report: IBM WebSphere Service Registry and Repository (WSRR)

This report takes a look at the capabilities provided by the IBM WebSphere Service Registry and Repository. We explore the customization and extension capabilities provided to understand the support for the meta models inherent in Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports.

By Lawrence Wilkes Introduction

As its name suggests, WebSphere Service Registry and Repository (WSRR) provides both a registry of Services as well as providing a repository capability to store documents that hold further metadata to detail them. WSRR is not limited to Web Services, and can support services defined using a variety of other protocols and programming models. By using the customization capabilities provided it can also be used to define and store Service at a more conceptual level, such as Business Services. Customization can also be used to define the metadata and documents to describe just about any SOA asset type so these can also be stored in WSRR as well as their relationships to the Services. WSRR also provides a customizable SOA lifecycle, together with Policy Management function that can be used to provide governance over the Service metadata and lifecycle within WSRR, as well as SOA policies that can be enforced elsewhere in the run-time environment, such as by an ESB. In this report we look at WSRR capabilities and examine how the customization and extension approach might be used in support of the CBD-SAE approach. This report is based on WSRR 6.2.

Content Structure and Meta Model

WSRR ships with a sample Configuration Profile (called the Governance Profile) that contains various configuration files detailing the content types that can be stored, the classification systems used, roles, plus the lifecycle used to control governance. Whilst the provided Governance Profile contains the basic structure for managing standard Service metadata such as WSDL files, IBM fully expects users to customize and extend the profile to capture further objects and define governance activities that the customer uses in their SOA approach. Content held in WSRR is based on the following elements as shown in Figure 1:

Service Description Entities

These are either, Documents: Documents containing structured service metadata. This includes

CBDI Journal Everware-CBDI Inc. March 2009

23

Standard-based schemas for describing Services such as Web Service Description Language (WSDL) Service Component Definition Language (SCDL) for Service Component Architecture (SCA) Services

o o

Policy Documents. For example, conforming to WS-Policy User-defined documents in XSD or just XML. For example, these might be schemas for business objects or business messages that are standardized within a particular vertical industry, that might form the basis of a service specification. Other types of document can be loaded into WSRR , such as Microsoft Office documents (e.g. a Word description or a Vizio diagram) Documents can also be broken down into logical objects (derivations). For example, a WSDL Document can be parsed into logical objects for each of the interfaces, messages, bindings, and so on.

o o

Concepts (business objects): Allows the user to define any generic object that doesnt have an associated document type. It may just be a pointer to content held elsewhere, such as in a development tool. A Concept can also be used to group documents.

Figure 1 - WSRR Home Page

Service Description Metadata

This defines the various additional metadata that may not already be part of a document. This includes metadata such as

CBDI Journal Everware-CBDI Inc. March 2009

24

Classifications. Including industry standard service classifications, or user defined. For example, adding classification of Services according to SAE Service Architecture Layers Relationships. Associations to other documents or concepts Properties. Whatever further properties the user wishes to add

Services can therefore be represented and managed in WSRR in a number of ways. For example, a Business Service - a service provided by the business, irrespective of whether it is implemented in software or not - could be managed as a Concept, whereas its implementation can be managed as a WSDL Document. These can then be associated together via relationships, so that the conceptual Business Service can be traced though to its realization as a Web Service. WSRR enables objects and their relationships to be viewed graphically as well as via the textbased explorer, as shown in Figure 2 where the logical derivations of a WSDL file are visualized.

Figure 2 - Graphical View of WSRR Content

Business Model Templates

Concepts can be created from scratch, or more likely created from a Business Model template that ensures all instances of similar concepts follow the same structure. The naming is probably a little misleading as the use of templates is not limited to defining Business Models or Business Objects. Rather they are used to define the properties and relationships for any object the user wants to manage as a Concept in WSRR.

Classification
Classifications enable the content of WSRR to be more easily searched, filtered or navigated. For example, classifying Service Types according to Service Architecture layers in SAE. Classifications should not be used as a substitute for modeling objects. For example to show which Services belong to a business domain, you could create the business domain as a

CBDI Journal Everware-CBDI Inc. March 2009

25

concept, and then make relationships to the Services it contains. However, if you have no need to store any additional properties about business domains or create further relationships to them, then a simple classification may be sufficient.

Web Ontology Language (OWL)

Both Business Model Templates and Classification systems in WSRR are defined using Web Ontology Language (OWL) files. Whilst OWL may be a powerful mechanism for architects, it is nevertheless perhaps a bit more daunting than simply allowing users to define new objects and their properties quickly via a UI. However, it means a certain level of governance is inherent in the OWL structure and WSRR can then enforce those rules without having to write additional policies or rules elsewhere. In the case of the classification system this can be built by using the WSRR Web UI and saved as an OWL file, or by importing the OWL file from some other source. However, the OWL files for Business Model Templates must be imported. You could build these by hand, or preferably use tools such as IBMs own Integrated Ontology Development Toolkit 1 that is available via their alphaWorks program.

Service LifeCycle and Governance

The default Configuration Profile contains a lifecycle based on the IBM SOA Foundation life cycle. This includes the stages: model, assemble, deploy, and manage.

Figure 3 - WebSphere Integration Designer (WID) used to define Service Lifecycle

CBDI Journal Everware-CBDI Inc. March 2009

26

The lifecycle can be customized, or a new one defined using WebSphere Integration Developer (WID). The lifecycle defines the permitted states, transitions allowed between states, conditions for transition, and actions that are upon transition.As an example, the life cycle state machine diagram for the IBM SOA Foundation life cycle is shown in Figure 3. WID creates State Adaptive Choreography Language (SACL) files containing an XML representation of the State Machine. An example of SACL is shown below. These could be defined manually without WID. <sacl:mainStateMachine> <sacl:state name="State1"/> <sacl:compositeState name="CompositeState1"/> <sacl:transition name="transition1"/> </sacl:mainStateMachine> Example of SACL (source IBM) As a final step, the SACL files must also be turned into an OWL file. At least this is done by WSRR. WSRR only allows one SACL file to be loaded at a time. This is not as constraining as it might sound, as a SACL file can hold multiple, complex lifecycles. This makes it possible to define alternative paths through the lifecycle for different objects. Constructing a WSRR lifecycle based on CBDI-SAE Service Lifecycle 2 would therefore be straightforward. A list of the states together with permitted transitions is also available in the CBDI-SAE Knowledgebase 3 We note that WSRR did ship with a sample lifecyle very similar to the CBDI-SAE Service Lifecycle in an earlier version, so this may still be available to users. The SOA or Service lifecycle states should not be confused with the development status of a particular document instance in terms of whether it is still in the draft stage or has been approved. WSRR does not currently manage this sort of document lifecycle, so any content would be considered approved. Though users could limit access to objects that they do not wish others to see by using permissions, or role-based views.

Governance Policy Validator

Documents and Concepts can be declared as governed entities. Governed entities are then subject to the lifecycle for that entity. The Governance Policy Validator is a plug-in that is used to define the assertions (rules) that will be applied to operations performed on governed entities such as state transitions, or on their creation, update or deletion. The assertions are formed from the properties, relationships and classifications that apply to the entity. The assertions are held in policy files. These contain a set of assertions that test whether the operation should be permitted. For example a policy can assert that in order for an entity to transition to a new state, then it must have certain property values, and certain relationships must exist (or should not exist).

CBDI Journal Everware-CBDI Inc. March 2009

27

Policy Management
A significant new feature of WSRR 6.2 is Policy Management. This enables SOA Policies to be managed as documents in WSRR, as well as providing a Policy Authoring tool that runs in the WSRR web-UI. As well as being used to define the policy files used by the Governance Policy Validator mentioned above, the policy authoring tool can be can be used to author SOA policies that will be enforced elsewhere, outside of WSRR. For example these could be run-time policies enforced by an Enterprise Service Bus (ESB), Service/Systems management tool, or security products. The challenge in this activity is identifying the structure and content of the policies that could be published to such tools, particularly the detail of the assertion languages they understand to determine the rules they must enforce. As a consequence, WSRR currently enables policies to be authored based on the WS-Policy standard, such as those that cover security, reliable messaging or transaction co-ordination. As these provide standardized assertion languages, WSRR is able to provide the UI to define the policy, as illustrated in Figure 4

Figure 4 - WS-Reliable Messaging Policy, edited in WSRR

Versioning and Configurations

WSRR provides versioning capabilities. Versions of objects are considered as new objects. A Concept (Service Description Entity) in WSRR can be used to define a group of objects. Hence it is straightforward to show dependencies based on specific versions of objects. E.g. objectA.V1 is dependent on objectB.V2

CBDI Journal Everware-CBDI Inc. March 2009

28

This can be used to define configurations as discussed in the report on Service Configuration Management 4. For example, Service Specification can be defined as a Concept that groups the various documents that make up the Service Specification in the Service Lifecyle Automation report 5. When creating an instance of that group, the relationships can be made to specific versions of the documents in the group. The Service Specification would also be defined as a Business Model Template to ensure all instances of Service Specification had the same content. And as a Governed Entity this could be subject to a lifecycle that determines which objects in the group and their relationships should exist at each lifecycle state.

Interoperability
Access to, and interoperability with WSRR is provided through a comprehensive API that is exposed either via Java, SOAP Web Services or REST (Representative State Transfer) protocols. These allow content, lifecycle and ontology to be managed via the API, providing additional import/export mechanisms, or interoperability with tools. Some specific interoperability features are listed in Table 1.
IDE and other development tools IBM Rational Asset Management can publish content to, or retrieve from, WSRR A SupportPac enables Visual Studio to exchange documents with WSRR A SupportPac enables developers to exchange documents with WSRR within an Eclipse environment UDDI Registry WSRR does not provide standard UDDI interfaces. However, the UDDI Synchronizer feature allows content in WSRR to be mapped to and synchronized with UDDI V3 registries using the WSRR API Tivoli can exchange information with WSRR. For example, publishing deployment metadata into WSRR. A SupportPac for Tivoli Composite Application enables the SOA Event Handler to publish events to that update metadata in WSRR. This would for example, enable the operational status of services or other QoS information to be visible from within WSRR. WSRR can discover and import WSDL files from IBM WebSphere Application Server Oracle Application Server Microsoft Windows .NET

CMDB

Service Management

Service Discovery

WSRR can also discover and import SCA integration modules in WebSphere Enterprise Service Bus and WebSphere Process Server. The Service Discovery Framework enables developers to build plug-ins for any environment. Table 1 - Interoperability Features

CBDI Journal Everware-CBDI Inc. March 2009

29

Representing CBDI-SAE
Implementing the structures of CBDI-SAE inside WSRR should be straightforward, although would require preparation, primarily to construct the OWL ontology to represent SAE. Various classes in the CBDI-SAE Meta Model for SOA could be represented as concepts in WSRR, and then as shown in Table 2, further concepts could be defined to represent deliverables. These deliverables could then show relationships to contained objects. We are aware of at least one CBDI subscriber that has implemented SAE concepts within WSRR in this way. The Business Model Templates to define these Concepts and their relationships in WSRR can be constructed from deliverable templates provided by CBDI or from the attribute definitions for the CBDI-SAE Meta Model for SOA. These are provided in the resource library of the CBDI-SAE Knowledgebase 6 Structuring it this way would enable the ontology to enforce governance rules via WSRR. For example, a Service Specification must have a relationship to a Service Architecture, whilst a Service Architecture must have a relationship to a Service Portfolio. Or that a Service Specification must have a relationship to Specified Operations and a Service Information Model. A specific configuration of Service Portfolio Plan could then be defined as a Concept Group that groups the physical documents together as a unit. SAE Deliverable or Concept
Service (notional)

Instantiation in WSRR

Concept. Relationship to contained or associated objects One or more Service Specifications

Service Portfolio

Concept. Relationship to contained or associated objects Business Models (pointer to) Service Architectures Service (notional)

Service Architecture

Concept. Relationship to contained or associated objects Service Specifications Architecture Model (pointer to)

Service Specification

Concept. Relationship to contained or associated objects. e.g. Specified Operation Service Information Model (pointer to)

Specified Operation

Concept. Relationship to contained or associated objects. e.g. Operation Signature = XSD document

Service Level Agreement

Concept. Might be possible to define some elements of the SLA using Policy. e.g. Security Policy

CBDI Journal Everware-CBDI Inc. March 2009

30

SAE Deliverable or Concept

Automation Unit Specification Policy Type Policy

Instantiation in WSRR

Concept: Relationship to contained or associated objects. e.g. SCA Module Document

Policy Domain Policy Document. Attach to relevant objects Table 2 - Defining CBDI-SAE in WRSS

Summary
WSRR is a powerful product, essentially an engine that is totally driven though a configuration profile. However, building the configuration profile required is a relatively complex activity and needs planning and forethought. Architects cannot just dive in and quickly establish a meta model or lifecycle through the WSRR UI as might be possible in some other registry/repository products. Rather various schemas and ontologies must be defined and imported into WSRR first. Subsequent updates to the configuration must undergo the same process. However, encouraging architects to properly think through their requirements and produce their ontology for SOA is not a bad thing. We imagine that many users will look to IBM for help in building their configuration. WSRR is therefore aimed at the more mature SOA organization, which has a growing inventory of SOA assets, and recognizes the need for additional governance. They are likely to have already established their SOA approach and framework, either as part of their own EA initiatives, or by adopting something like TOGAF, IBMs own SOMA approach, or CBDI SAE. WSRR then provides them with a capability in which they can physically instantiate that approach in a registry/repository and better enforce their Service Lifecycle and the policies that should govern their deliverables.
1 2

http://www.alphaworks.ibm.com/tech/semanticstk The Service Lifecycle. CBDI Journal, Nov 2005.

Service Lifecycle Configuration Management. CBDI Journal, Jan 2009.

Service Lifecycle Automation. CBDI Journal, Dec 2008. See Table 6, elements of a Service Specification.

CBDI Journal Everware-CBDI Inc. March 2009

31

About CBDI
CBDI Forum is the Everware-CBDI research capability and portal providing independent guidance on best practice in service oriented architecture and application modernization. Working with F5000 enterprises and governments the CBDI Research Team is progressively developing structured methodology and reference architecture for all aspects of SOA.

CBDI Products
The CBDI Journal is freely available to registered members. Published quarterly, it provides in-depth treatment of key practice issues for all roles and disciplines involved in planning, architecting, managing and delivering business solutions. Visit www.cbdiforum.com to register. Platinum subscription A CBDI Forum subscription provides an enterprise or individual with access to the CBDI-SAE Knowledgebase for SOA delivering ongoing practice research, guidance materials, eLearning, tools, templates and other resources.

Everware-CBDI Services
At Everware-CBDI we enable large enterprises and governments to become more agile by modernizing their business systems. We have repeatable processes, resources, tools and knowledge-based products that enable enterprises to transform their current applications in an efficient, low risk manner, into an optimized service-based solutions portfolio that supports continuous, rapid and low cost evolution. Our consulting services range from providing practices and independent governance to architecture development, solution delivery and service engineering.

Contact
To find out more, and to discuss your requirements visit www.everware-cbdi.com or call USA and Americas: 703-246-0000 or 888-383-7927 (USA) Europe, Middle East, Africa, Asia, and Australasia: Telephone: +353 (0)28 38073 (Ireland)

www.everware-cbdi.com
IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognized and acknowledged. The CBDI Journal may be distributed internally within customer enterprises that have current corporate subscriptions. Otherwise CBDI Journals may not be copied or distributed without written permission from Everware-CBDI.

CBDI Journal Everware-CBDI Inc.