websphere service registry and repository

8/12/2019 WebSphere Service Registry and Repository

http://slidepdf.com/reader/full/websphere-service-registry-and-repository 1/11

Product ReportIBM WebSphere Service Registry andRepository (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

Independent Guidance for

Service Architecture and Engineering

Originally published in the March 2009edition of the CBDI Journal



CBDI Journal © Everware-CBDI Inc. March 2009 23

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 aregistry 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 lifecyclewithin 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, theclassification 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




o 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 Policy Documents. For example, conforming to WS-Policy

o 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.

o Other types of document can be loaded into WSRR , such as Microsoft

Office documents (e.g. a Word description or a Vizio diagram)

o 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.• Concepts (business objects): Allows the user to define any generic object that

doesn’t 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. Thisincludes metadata such as




• 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 text-

based 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




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 IBM’s own Integrated Ontology Development

Toolkit1 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

http://0.0.0.0/

http://0.0.0.0/




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




This can be used to define ‘configurations’ as discussed in the report on Service

Configuration Management4. 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 report5. When creating an instance of that group, the

relationships can be made to specific versions of the documents in the group. The ServiceSpecification 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 additionalimport/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

CMDB Tivoli can exchange information with WSRR. For example, publishing

deployment metadata into WSRR.

Service

Management

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.

ServiceDiscovery

WSRR can discover and import WSDL files from

• IBM WebSphere Application Server

• Oracle Application Server

• Microsoft Windows .NET

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 - Interoperabili ty Features

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/




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 Knowledgebase6

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

Instantiation in WSRR

Service (notional) 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 SLAusing Policy. e.g. Security Policy

http://0.0.0.0/

http://0.0.0.0/




SAE Deliverable or

Concept

Instantiation in WSRR

Automation Unit

Specification

Concept: Relationship to contained or associated objects. e.g.

• SCA Module Document

Policy Type Policy Domain

Policy 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 ownEA initiatives, or by adopting something like TOGAF, IBM’s 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 http://www.alphaworks.ibm.com/tech/semanticstk

2 The Service Lifecycle. CBDI Journal, Nov 2005.

4 Service Lifecycle Configuration Management. CBDI Journal, Jan 2009.

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



CBDI Journal © Everware-CBDI Inc.

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.