SOALink “Cookbook” - InfoQ.com€¦ · 12 CentraSite SOA Cookbook Version 1.0 Run-Time Integration Scenarios SOA run‐time solutions provide a wide range of functionality, from

Title Page

SOALink "Cookbook"A Guide to Extending and Integrating with CentraSite

Draft Version 0.1

October 2008

SOALink “Cookbook” A Guide to Extending and Integrating with CentraSite Draft v0.1 October 2008

Copyright& Docu‐ment ID

This document applies to CentraSite SOA Cookbook Version 1.0 and to all subsequent releases.

Specifications contained herein are subject to change and these changes will be reported in subsequent release notes or new editions.

© Copyright Software AG 2008.

All rights reserved.

The name Software AG and/or all Software AG product names are either trademarks or registered trademarks of Software AG. Other company and product names mentioned herein may be trademarks of their respective owners.

Document ID: CSSOALink-80-20081031

Table of Contents

Table of Contents

Part I. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1. Overview of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Introduction to SOALink Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8SOA Lifecycle Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Design-Time Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Run-Time Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Integration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Design-Time Integration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Run-Time Integration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Part II. Design-Time Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Looking up Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Publishing Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Publishing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Looking up Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Mapping Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Synchronizing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Management of Additional Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

UI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20References to API Sections of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Integration with Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25References to API Sections of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Integration with Quality Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

CentraSite SOALink "Cookbook" Version 0.1 1

Table of Contents

Looking up Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Looking up BPEL Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Publishing Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Triggering Tests from CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Viewing Test Results in CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31UI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

References to API Sections of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5. Lifecyle Management of Externally-Managed Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Looking up Assets Filtered by Lifecycle State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Management of Additional Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Manipulating the Lifecycle State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Watching and Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Custom Importers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


6. Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40References to API Sections of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7. Integration with Configuration Management Databases (CMDBs) . . . . . . . . . . . . . . . . 43Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Deep Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Looking up Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Publishing Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Publishing and Looking Up Other Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Mapping Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Management of Additional Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Federating the CMDB and CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47UI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


2 CentraSite SOALink "Cookbook" Version 0.1

Table of Contents

8. Workflow Systems Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Creation and Management of SOA Assets as Part of an Enterprise Workflow . . . . . . 51Starting a Workflow out of CentaSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


Part III. Run-Time Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

9. SOA System of Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Publish Performance Metrics to CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Publish Alerts and Events to CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Publish Runtime Asset Dependencies in CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . 58Allow Third-Party PEPs to Update/Replace Web Service Endpoints in CentraSite . . . 59


10. Consumer Tracking and Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Consumer Application Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Consumer Application Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

References to API Section of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

11. Policy Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Policy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Attaching Policies to Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Retrieving Attached Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Fetch Services with Remote Policy References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Fetch Services with Local Policy References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Fetch Service-Specific Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Fetch Reusable Policy References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Policy Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

References to API Section of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


Table of Contents


I Overview

Chapter 1, “Overview of this Document”

CentraSite SOA Cookbook Version 1.0 5

I Overview

6 CentraSite SOA Cookbook Version 1.0

1 Overview of this Document

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Introduction to SOALink Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

SOA Lifecycle Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Integration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10



OverviewCentraSite acts as the system of record and the central point of control in the development and operations of systems built using Service Oriented Architecture. As a result, customers frequently need to integrate other parts of their SOA infrastructure with CentraSite. This document provides an overview of how CentraSite functionality can be extended and integrated with other products and systems. This document is not meant to be an extensive documentation of all APIs, standards, and extension points supported by CentraSite. Instead, this document provides an overview of common patterns and techniques, or “recipes”, that customers and partners can use for integration with CentraSite.

The goal of this document is to:

1 Describe common integration scenarios for SOA design‐time and run‐time

2 Recommend an implementation approach with CentraSite ActiveSOA

3 Describe supported interfaces and techniques that can be used to build the integration

The patterns and techniques described in this document are based on the integration work done by members of the CentraSite Community, which brings together vendors whose technologies tie‐in with CentraSite and consultants whose “best practice” approaches are complemented by CentraSite.

Introduction to SOALink FrameworkSOALink is a framework that provides the interoperability between CentraSite and various SOA infrastructure components that participate in the SOA lifecycle. SOALink consists of a set of standards, APIs, and extension points supported by CentraSite ActiveSOA. SOALink leverages standards such as UDDI, SNMP, WS‐Policy, and WS‐PolicyAttachment as the building blocks for the interface. In cases where a particular standard does not exist or is inadequate, SOALink defines a set of extensions to existing standards.

The SOALink framework consists of the following standard‐based APIs:

UDDI v2, v3

JAXR

WS‐PolicyAttachment

WS‐Policy 1.5

SNMP v2, v3

The framework also defines the following extensions:

Custom design‐time policy actions

Custom run‐time policy actions



Run‐time policy format converter

UI plug‐ins

Asset type plug‐ins

Custom asset importers

Custom report templates

CentraSite development framework

SOA Lifecycle GovernanceCentraSite ActiveSOA provides the enabling technology to govern the entire SOA lifecycle. The figure below shows a typical service lifecycle that covers activities ranging from service portfolio management to service operations.

In a typical service lifecycle, many stakeholders and enterprise tools work together to move the service from one step to the next step. Effective SOA lifecycle governance requires coordination and communication across a wide range of enterprise stakeholders and activities.

SOA is also unique in that it involves the creation of discrete, well‐defined services that exist not only as building blocks of larger systems and applications, but also as independent entities. SOA exposes standalone application functionality at a fine level of granularity. It is not prudent to consider SOA governance a run‐time or design‐time activity; instead, SOA governance happens all the time.

Portfolio Management

Analysis Design Build Test Deploy Operate

¬Identify new/revised services to be built.

¬What technical / business problem the services address?

¬When should we build the services?

¬What are interface details?

¬What is expected behavior of the service?

¬What are the security/performance requirements?

¬Develop detailed service designs.

¬Develop testing strategy

¬Build the service implementation

¬ Conduct Unit Testing

¬ What capacity is needed? ¬ What dependencies are

present?

¬Develop test cases ¬Does the service behave as per the specification?

¬Does the service meet all expected thresholds?

¬Is everything operating as intended?

¬Does anything need to be changed?



Design-Time GovernanceDesign‐time governance is an IT development function that involves the enforcement of processes and the application of rules for governing the definition, creation, and maintenance of SOA assets such as services and schemas. Policies typically ensure that services are technically correct and valid, and that they conform to relevant organizational and industry standards. Design‐time governance includes change management—the act of managing SOA assets through the cycle of change—which is arguably more complex and important in the long term than the design and creation of SOA assets.

Run-Time GovernanceGovernance at run‐time consists of defining and enforcing policies for controlling the deployment, utilization, and operation of deployed services. These run‐time policies typically relate to non‐functional requirements such as trust enablement, QoS management, and compliance validation. Run‐time governance also involves service‐level agreement (SLA) monitoring and reporting. By tracking the actual performance of a service and comparing it to the requirements specified in the SLA, the system can identify non‐compliant services that require prompt action.

The SOALink framework is primarily meant to cover all “use cases” resulting from the requirements for design‐time and run‐time governance.

Integration ScenariosSOA Governance is an essential component of every successful SOA program. The CentraSite registry/repository provides command and control functionality in an SOA infrastructure. At each step of the service lifecycle, the CentraSite registry/repository can work with various third‐party tools to enable effective SOA Governance. This document attempts to cover all important integration scenarios that happen during the various stages of the lifecycle.

Design-Time Integration ScenariosThe following figure depicts the various third‐party tools that can interact with CentraSite during the design‐time phase of the service lifecycle. It shows a few common types of third‐party tools integrating with CentraSite. In reality there may be additional third‐party tools that may integrate with CentraSite. In this document, we have focused on the most common types of integration scenarios requested by CentraSite customers and partners.



This document takes a use case‐driven approach and addresses the following use cases:

Enterprise Architecture (see Chapter 2, “Enterprise Architecture”)

Integration with Integrated Development Environment (IDE) tools (such as Eclipse) (see Chapter 3, “Integration with Development Tools”)

Integration with quality management (see Chapter 4, “Integration with Quality Management Tools”)

Lifecycle management of externally‐managed assets (see Chapter 5, “Lifecyle Management of Externally‐Managed Assets”)

Federation (see Chapter 6, “Federation”)

CMDB integration (see Chapter 7, “Integration with Configuration Management Databases (CMDBs)”)

Integration with workflow systems (see Chapter 8, “Workflow Systems Integration”)

Portfolio Management

Analysis Design Build Test Deploy Operate

¬Enterprise Architecture tools

¬UML Modeling Tools ¬Process Modeling

¬Model Driven Development

¬IDE Tools like Eclipse ¬SCCS

¬ CMDB

¬Quality Management Tools

¬Other Repositories ¬LDAP



Run-Time Integration ScenariosSOA run‐time solutions provide a wide range of functionality, from hosting services to delivering, securing ,and managing services. Run‐time solutions generally fall into one of the following categories:

It is common for enterprises to have multiple tools and products that address one or more of the above requirements. Architects and IT managers who are leading SOA initiatives require visibility and control over their entire run‐time infrastructure. Hence, the primary goal of the integration between run‐time components and CentraSite is to:

Enable CentraSite to act as the SOA system of record, thereby allowing different stakeholders to view the entire SOA blueprint (see Chapter 9, “SOA System of Record”)

Extend CentraSite governance process‐like consumer provisioning to third‐party Policy Enforcement Points (PEPs) (see Chapter 10, “Consumer Tracking and Provisioning”)

Enable a standards‐based way to create policies in CentraSite, and to provision them to third‐party PEPs (see Chapter 11, “Policy Management Framework”)

Run-time solution Description

SOA Enablement Creating services from existing applications and systems

SOA Mediation Providing location, protocol, version, and format independently between consumer and provider

SOA Appliances Providing XML accelerations, threat protection, and advanced security

SOA Management Providing advanced visibility and monitoring


II Design-Time Scenarios

Chapter 2, “Enterprise Architecture”

Chapter 3, “Integration with Development Tools”

Chapter 4, “Integration with Quality Management Tools”

Chapter 5, “Lifecyle Management of Externally-Managed Assets”

Chapter 6, “Federation”

Chapter 7, “Integration with Configuration Management Databases (CMDBs)”

Chapter 8, “Workflow Systems Integration”


II Design-Time Scenarios


2 Enterprise Architecture

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Technical Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

UI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

References to API Sections of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



OverviewEnterprise Architecture (EA) tools are used to analyze and optimize the portfolio of business strategies, organizational structures, business processes/tasks and activities, information flows, applications, and technology infrastructure. EA is primarily tasked to identify the enterprise capabilities needed to support business objectives. EA utilizes a top‐down approach to defining the business processes (which are made of services) that are needed to achieve the business objectives.

The CentraSite registry/repository enables Enterprise Architects to drive the transition from envisioning services as a means of achieving business objectives to managing its lifecycle after implementation. In addition, the registry/repository provides “quality of service” data to enable continuous improvement. The CentraSite registry/repository also enables the architects to exercise more control and to govern services and business processes through the use of policies.

GoalThe primary goal of the integration between EA tools and CentraSite is to provide visibility into the Enterprise IT information, and to enable end‐to‐end management of SOA. A top‐down Enterprise Architecture approach results in the reuse of existing services and the identification of new services. But these new services are not governed and are not known outside the EA Tool. Similarly, metadata collected in the EA tool is not shared with the other applications. The integration between the two product categories will result in increased visibility for the Business/IT stakeholders. Similarly, business processes as designed in EA tools can be governed over the whole lifecycle, even though their implementation is out of the scope of the EA tools.

BenefitsThe benefits of the integration are:

The integration between the two product categories provides the missing link between EA planning and project execution.

EA Tools are primarily used for planning purposes. The integration with an SOA registry/repository solution provides an EA tool with the ability to enforce standardized EA governance processes and to automate these processes through the use of dynamic design‐time and run‐time policies. For example, in an EA tool, new services are identified and can be put under governance by registering them into the SOA registry/repository tool. These services can be tracked in the registry as they go through the various SDLC stages, and the status of these services can be fed into the EA tool.

Integration increases the reuse of services.

Since all the existing services are made available to the EA tool, an architect can identify and reuse existing services for new IT initiatives.



Business processes can be governed over their entire lifecycle, integrating all tools participating in this lifecycle (implementation, testing, and deployment) via CentraSite.

Enterprise Architects can easily access lifecycle status information for their business processes.

Enterprise Architects can know about the relationship between the various components due to the synchronization of data between the EA tool and SOA registry/repository.

The additional information is helpful during impact analysis and portfolio management.

The modeling of organizational structures can be synchronized between the EA tool and CentraSite, to maintain consistency.

Additional assets modeled in an EA tool can be published to CentraSite to make these available to the subsequent implementation chain, and to include these into governance and impact analysis.

Technical ApproachIn typical enterprise architecture scenarios, assets such as processes or services originate from the usage of Enterprise Architecture tools. However, their further lifecycle is not tracked in the EA tool. When integrating with CentraSite, the assets as modeled in the EA tool will be published to CentraSite, and will be managed from here. On the other hand, relevant lifecycle information from CentraSite (e.g., retirement or the availability for production) should be synchronized back to the EA tool. Furthermore, assets that exist in CentraSite but not in the EA tool (e.g., services provided by third parties) should be made known to the EA tool as well.

As a consequence, the EA tool will publish services, processes, or other assets to CentraSite, and will also look up such assets in CentraSite. CentraSite provides open APIs for these tasks.

Looking up Web ServicesUDDI v2 or UDDI v3 can be used for web service lookup. Note that web services are registered in CentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configuration of CentraSite, unauthenticated access using these interfaces will yield all services visible to “Everyone” in CentraSite. Authenticated access yields access to all services visible to the authenticated user. Note that access to the WSDL file might require authentication. Lifecycle information for web services is available as keyedReference in the businessService data. Version information cannot be retrieved via UDDI.

The preferred way to look up web services is to use the JAXR interface of CentraSite. This also provides access to versioning information and lifecycle states



Publishing Web ServicesFor publishing web services, the usage of UDDI or JAXR is possible but discouraged, due to the complex structure representing a web service that is introduced by the technical note “Using WSDL in a UDDI registry”. Instead, the CentraSite API for web service registration should be used, which registers a service based on its WSDL. This API is also available via a web service interface. It handles the proper versioning of services in CentraSite.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user must have the necessary privileges in CentraSite to publish web services.

Note that published web services can be categorized with the EA tool’s name, to indicate their origin. For this purpose, the EA tool can register itself with the “Products” taxonomy in CentraSite, optionally even providing a product icon.

Publishing Business ProcessesCentraSite provides an API for registering business processes described in BPEL (also available via web service interface). The registration follows the technical note “Using BPEL in a UDDI registry”. In JAXR, it will create objects of the CentraSite types “BPEL process”, “BPEL Partner Link type”, “BPEL partner link”, and “BPEL role”. Usage of this API is preferred over using UDDI or JAXR here to ensure a consistent mapping of the process information to CentraSite. Upon registration through this interface, CentraSite will also derive all dependencies to existing services referenced from the BPEL description.

A similar functionality is available via the CentraSite Community for business processes described as XPDL.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user must have the necessary privileges in CentraSite to publish business processes.

Preferably, these interfaces are called from within the EA tool. An alternative method is to have the EA tool export BPEL or XPDL to the file system, and in a second step import this into CentraSite using the CentraSite UI.

Note that published business services can be categorized with the EA tool’s name, to indicate their origin. For this purpose, the EA tool can register itself with the “Products” taxonomy in CentraSite, optionally even providing a product icon.

Looking up Business ProcessesBusiness processes registered in CentraSite can be looked up using UDI v2 or UDDI v3 (following the guidelines of the technical note “Using BPEL in a UDDI registry”) or preferably via JAXR. UDDI access provides lifecycle information as a keyed reference, but does not provide versioning information, while access using JAXR provides both types of information.



Mapping Organizational StructuresCentraSite requires that all assets (services, business processes, and so on) are assigned an owning organization. These organizations are modeled in CentraSite, and can form a hierarchy (for example, representing departments in a company). As many EA tools provide a similar capability, it makes sense to synchronize the organization models. UDDI can be used to retrieve and update organization information. The UDDI specification defines how Organization hierarchy is modeled by publisher assertions; however, currently CentraSite does not fully support this method. Via the JAXR API, a richer view of organizations is provided which also allows for easier handling of organization hierarchy.

Synchronizing InformationThe usage of the CentraSite federation feature for synchronizing is recommended only if the EA tool has an interface that allows for easy outside access or publishing. If this is the case, organizational structures could be synchronized, as well as the lifecycle information of services known to the EA tool.

The preferred way of synchronization is that the EA tool pulls and pushes the relevant information from/to CentraSite using its own discretion.

Where such a tight coupling cannot be applied, another method of data transfer can be used (at least unidirectionally): if the EA tool is able to export information to a file, a custom importer can be added to CentraSite to interpret this file and to create appropriate CentraSite assets.

Management of Additional AssetsDepending on the EA Tool, even more assets are modeled that relate to business processes and services, e.g., business objects, business domains, or projects. Depending on their nature, they can be mapped to custom CentraSite types using the CentraSite extensibility features, or to taxonomies. For grouping assets (e.g., to reflect a project structure), the JAXR type “Package” can be used. Custom CentraSite types can be created via the CentraSite UIs, e.g., CentraSite Control. After creation, the type has to be exported into an archive, also via the UI. At a customer site this archive must be imported into CentraSite either via UI or (preferably) via the importer API to deploy the type definition. This method is preferred over type creation at customer site, because the latter method would cause a different UUID for the type at each customer site, which might cause problems in later migration scenarios.

All these interactions require the usage of the JAXR interface from the EA tool.



Additional ConsiderationsBesides assets, the knowledge about dependencies and relationships between components, which is available in the EA tool, should be conveyed to CentraSite, typically in the form of an association or a relationship attribute.

CentraSite versioning information is not exposed via UDDI. It is exposed via JAXR interface. In addition, there is a CentraSite extension to JAXR for creation and advanced handling of versions. The WSDL, BPEL, and XPDL importer APIs can be relied upon to handle versions appropriately.

CentraSite lifecycle information is exposed via UDDI and JAXR. In addition, there is a CentraSite extension to JAXR to manipulating lifecycle states of assets. Newly‐created assets are assigned a lifecycle state by CentraSite based on the rules defined in CentraSite. It is not expected that EA tools have the need to manipulate the lifecycle state of assets.

CentraSite allows to define design time policies which can be used e.g. to enforce certain conditions on assets store in CentraSite. Depending on the policies defined in a CentraSite instance, publication of services, business processes etc from the EA tool may fail. This is not a fundamental issue to the integration, it is just a matter of configuration of a CentraSite instance. The same holds for user configuration and privileges.

UI IntegrationSwitching back and forth between the user interfaces of CentraSite and the EA tool might be desirable in several use cases, e.g., to drill deeply down into technical dependencies or usage data from the EA tool, or to explore the EA level information from CentraSite. Hence, an easily link from the CentraSite UI to the EA tool UI (and vice versa) is beneficial. For this purpose, CentraSite provides deep link capability, i.e., each screen can be addressed by a dedicated URL. Hence, such links could be added to the EA tool’s UI. In exchange, if the EA tool UI provides a similar capability, these URLs can be passed to CentraSite and stored in an attribute of type URL, which will then allow clicking the URL in the GUI:

Note that currently no authentication integration is available, i.e., if the target system requires authentication, a corresponding screen to enter the authentication information will be displayed before the actual targeted screen is displayed.

References to API Sections of This DocumentAPIs that are relevant in this context are:

UDDI v2, v3

JAXR API

Importers for WSDL, XML schema, BPEL; XPDL (API, web services)

Custom importer



Type definition UI, export

CentraSite APIs for versioning and life cycle management

UI (deep links)

Note: The API section of this document will be provided in the next version of this document, and links to them will be provided as well.


3 Integration with Development Tools

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24





Overview4th Generation Integrated Development Environment (IDE) tools, such as Eclipse, reduce the time for developing software. These tools offer productivity‐enhancing features, such as real‐time syntax checking, code completion, refactoring support, various wizards, integrated build management, integration with version control systems, and even generating code from a machine‐processable language, such as a WSDL (Web Services Description Language). Most tools needed to manage and develop SOA assets are able to integrate with standard development tools, such as Eclipse or Visual Studio, thereby providing the developer with a uniform user experience.

The semantic capabilities and the context awareness of these development tools make metadata (as they are available in a SOA registry/repository such as CentraSite) particularly useful.

When a developer, in the course of his or her development tasks, needs to call or orchestrate a service, he needs a user‐friendly way to browse and search available and reusable services. Once the service is found they need an easy way to consume the service in their code. Development tools could utilize standards‐based protocols to introspect the CentraSite registry/repository and to reuse services. Similarly, once new services are developed, publishing them to CentraSite to make them available for reuse should be possible within the development tool.

GoalThe primary goal of the integration between development tools and CentraSite is to improve the productivity of developers and to provide ease of use for the various CentraSite features.


Increased developer productivity, by making the usage of registered services as easy as drag and drop, or copy and paste.

Increased reusability of SOA assets. The integration allows the developer to search and browse the registry and find services that match their requirements.

The developer can reuse metadata associated with SOA assets.

New SOA assets can be seamlessly published to CentraSite to make them available for reuse.

Dependencies between the SOA assets can be easily browsed by the developer without switching the working environment.



Technical ApproachBeyond the Web UI CentraSite Control, CentraSite provides a comprehensive set of functions for the Eclipse platform. As to be expected for Eclipse, these functions are implemented as plugins, and are bundled as features. These either can be directly installed into the Software AG Designer (which is Eclipse with Software AG plug‐ins preinstalled) during installation of CentraSite, or be added to a compatible Eclipse workbench using the Eclipse provisioning functionality. A Software AG internet update site provides for updates through this same provisioning functionality for registered support customers.

The functionality provided includes:

Configuration of multiple CentraSite connections, of which one can be active at any time. Credentials are optionally held in Eclipse secure storage.

Tree‐based and graphical navigators for the registry. Both are customizable using filter settings.

Tree‐based navigator for the repository (supporting documents). Import and export of repository documents.

Asset lists organized by asset types, and optionally by taxonomy.

Editing of assets, with asset type profiles represented as individual editor pages.

Simple, advanced, and XQuery searches within the Eclipse search framework.

Drag and drop of registry and repository entries between views, e.g., for creating associations between objects.

Import and export wizards for services, archives etc. as in CentraSite Control.

An administration view for users, groups, types, and taxonomies.

Report development and execution based on Business Intelligence and Reporting Tools (BIRT), which consists of additional data source implementations for defining CentraSite data sets using JAXR and XQuery.

Plugins are bundled into three features: for the UI, for the reporting support, and for the CentraSite interface libraries. When installing into Software AG Designer through the webMethods Installer, the user can choose the UI plugins, and optionally the reporting support. Similarly, when installing using the Eclipse update manager, the reporting feature will require the UI feature, which in turn requires the interface libraries. The Eclipse platform used as base is 3.4 (Ganymede).

From the CentraSite server’s view, such an Eclipse workbench appears as just another client, just like CentraSite Control. In fact, to a great extent the same libraries are used. All server‐based mechanisms like policy enforcement, lifecycle management, and permission and role checks are applied in the same way. The assets shown and edited are all server‐based, meaning that they are not file‐based resources, and only in‐memory representations are held in the workbench.



The CentraSite plugins can be used on their own to browse and manage assets. This is done typically in the CentraSite perspective, which arranges the above‐mentioned plugins into a default layout. The user can, as usual, customize this layout. When using CentraSite in conjunction with other products, selected views can be added to other perspectives (and in fact are included in some default layouts of Software AG products). For example, the registry tree navigator can be used in the Process Development perspective to select a service, drag it to the process canvas, and drop it there to create a process step invoking that service. This type of integration is based on the Eclipse drag‐and‐drop framework. Commands contributed to the context menus of CentraSite views add product‐specific functions specific to their metadata assets. Extension points exist to contribute further functions to the views.

Reports are created using the BIRT package, one of the most popular Eclipse projects. The CentraSite data sources added to this framework are used to define the data sets for a report, which is then built in the usual way. The report can be previewed in the BIRT editor and published to the CentraSite server from the report project.

All this leveraging of the Eclipse platform and its extensibility mechanisms ensures that developers can perform their workflows in a seamless manner in their development environment. Care is taken to adhere to the Eclipse user interface guidelines to follow the principle of least surprise. This implies that the Eclipse UI will differ from Control wherever it makes sense. On the other hand, terminology, logical, and visual arrangements are shared with Control wherever possible, up to the use of identical visuals and even user preferences and configurations by storing them in the registry.


Eclipse UI

Eclipse extension points



4 Integration with Quality Management Tools

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29





OverviewEnterprise SOA applications are, by nature, complex and heterogeneous, involving the interaction of many distributed development teams and stakeholders to leverage multiple technology assets. An organization move towards SOA increases the modularity and change‐time requirements for SOA assets as follows:

Modularity

Composite business applications are composed quickly, using a large number of custom, outsourced, and packaged services/assets.

Change‐Time

The decentralized nature of SOA organizations increases the complexity of changes. Similarly, the increasing use of service and application SLAs requires minimal disruption during frequent updates to services.

Therefore, an end‐to‐end quality management approach is needed to counter the challenges posed by decentralization, modularity, and increased complexity. An SOA quality management strategy should account for testing across multiple integration layers, both at business process and service level and across a variety of SOA delivery platforms.

GoalThe primary goal of integrating SOA Quality Management tools and CentraSite is to enable end‐to‐end quality management of SOA. The goal is for SOA Quality Management vendors to:

Support the lifecycle quality of service/process assets registered in CentraSite.

Provide an actionable means of enforcing policy through testing, such that advancing a lifecycle state implies quality assurance of an asset.

SOA Quality Management is the process to verify that SOA assets meet functional and operational business requirements. Integration of the SOA Quality Management tools and CentraSite enables the user to maintain a continuous quality focus across all stages of the SOA lifecycle. This would result in:

SOA Testing scripts being lifecycle‐managed in CentraSite.

The asset lifecycle stages being triggered, based on testing results in the SOA testing tool. Alternatively, the test could be triggered by requested changes in the lifecycle state.

The results of the testing becoming feedback, and being stored as metadata for the SOA asset.




Reduced cost and improved credibility with early detection of defects and an integrated lifecycle approach.

The above end‐to‐end SOA Quality Management approach results in early validation of system functionality, system scalability, and identification of any performance bottlenecks.

Ensures compliance and customer satisfaction through predictability and high quality SOA implementations.

This enables the user to handle changes to SOA infrastructure quickly, and to ensure compliance with business objectives and regulatory requirements with minimal downtime.

Improve “return on investment” of software delivery by streamlining business processes across the lifecycle.

The streamlined processes enable the user to realize SOA “return on investment” through greater reuse and agile infrastructure.

Test automation for SOA assets.

Quality policies can automatically be enforced.

Technical ApproachThe basic integration is that on the Quality Management Tool side, services are looked up in CentraSite, to select them for testing. Test results (including the fact that tests have been executed) can be published back to CentraSite. In a more extended scenario, tests can be triggered from CentraSite, and test results can be viewed in CentraSite.

Looking up Web ServicesUDDI v2 or UDDI v3 can be used for web service look up. Note that web services are registered in CentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configuration of CentraSite, unauthenticated access using these interfaces will yield all services visible to “Everyone” in CentraSite. Authenticated access yields access to all services visible to the authenticated user. Note that access to the WSDL file might require authentication. Lifecycle information for web services is available as keyedReference in the businessService data. Version information cannot be retrieved via UDDI.

The preferred way to look up web services is using the JAXR interface of CentraSite. This also provides access to versioning information and lifecycle states.



Looking up BPEL ProcessesBPEL processes can be looked up using the JAXR API.

Publishing Test ResultsMetadata about tests (e.g., the tool used for testing, the date of the last test, success or failure, etc.) can be attached to the service as type‐specific or object‐specific attributes. To extend the service type using type‐specific attributes, you use the CentraSite type management, edit the service type, add the attributes, and assign them to profiles. To make sure that these are available at the customer site as well, the type management API has to be used on the first contact of the SOA testing tool with CentraSite.

Using type‐specific attributes has the advantage that the value of these attributes can be nicely integrated into the generic CentraSite GUI, or even a separate generic test history profile can be created without any programming effort. Object‐specific attributes, in contrast, need no preparation at all, and can be added to services at any time, but always appear in the CentraSite profile for object‐specific attributes. In case the UI is extended by a plug‐in (see below), object‐specific attributes are the method of choice.

No matter which type of attributes is chosen, the attribute values are propagated to CentraSite by updating the web service.

For updating web services, UDDI or JAXR can be used. However, if UDDI is used the representation of JAXR attributes in UDDI has to be followed.

Test results not only consist of simple metadata, but also of possibly voluminous test reports. These can and should be stored in the CentraSite repository, using the webDAV interface. To attach them to the web services, you can use service‐specific file attributes or external links (corresponding to object‐specific attributes). This can be done even if the test report itself is not stored in CentraSite.

Triggering Tests from CentraSiteSOA Quality Management tools usually have web service‐based interfaces to initiate testing activities. These can either refer to a test case defined in the tool, or the test case can be attached to the service to be tested, e.g., using WS‐PolicyAttachment.

In order to use WS‐PolicyAttachment, the test plan must be present as a WS‐Policy definition, and a WS‐Policy object has to be created in JAXR or via UDDI and attached to the service according to the WS‐PolicyAttachment standard.

To trigger the test run, i.e., to call the quality management tool interface (e.g., web service), a CentraSite design‐time policy should be created. This policy can be run manually, or can be assigned to a lifecycle state to couple test execution with lifecycle state evolution. Note that long‐running tests will have to run asynchronously, which, in the case of the coupling with lifecycle state will require two lifecycle states to be used: a “Testing in progress” state that triggers the test execution, and another state reflecting the successful test. The latter state would be entered automatically (via a design‐time policy) when the successful test is published to CentraSite.



Viewing Test Results in CentraSiteFile attributes can be assigned to profiles, permitting you to control where they are displayed. For test reports, this can be used to place the test report file attribute (see above) at a prominent place to allow access to the report by a simple click. If external links are used to link the test report, this can be accessed via a single click as well, however the link will always be displayed in the external link profile.

A more involved, yet much more attractive, integration is the addition of a new profile reflecting the quality management tool’s information to the service type using the extensible web UI technology of CentraSite by providing a custom plug‐in.

UI IntegrationAccessing the quality management tool from within the CentraSite UI might be desirable in several use cases, e.g., to examine or modify the test plan. Hence, an easy link from the CentraSite UI to the quality management UI should be provided. If the quality management tool provides such links, these can be passed to CentraSite and stored in an attribute of type URL, which will then allow clicking the URL in the GUI.

Note that currently no authentication integration is available. If the target system requires authentication, a corresponding screen to enter the authentication information will be displayed before the actual targeted screen is displayed.

Additional ConsiderationsFor most of these interfaces, authentication against CentraSite is mandatory. The authenticating user must have the necessary privileges in CentraSite to publish web services.

To provide an overview of the whole SOA landscape quality, reports can be created in CentraSite that display, for example, an overview about the relationship between tested/untested assets, ration of test failed, etc. CentraSite reports can be defined using the Eclipse‐based report definition, and can be published to CentraSite from Eclipse. They can be exported, and then at a customer site imported into CentraSite. For the creation of reports, information has to be extracted from CentraSite using XQuery.


UDDI v2, v3

JAXR API

WebDAV & WVCM

Web UI extension.



Eclipse and extensibility

Policy attachment

UDDI

JAXR

JAXR extensions (type definition)

Reports generation, export, import

XQuery



5 Lifecyle Management of Externally-Managed Assets

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34





OverviewSOA is a journey that begins with the task of piercing the application silos that isolate data and processes, thereby limiting organizational agility. As SOA matures within an organization, composite business services start appearing that bridge these silos. These services/assets span multiple environments and governance of services/assets becomes important to fulfil the SOA promises like agility and reuse.

GoalThe primary goal of CentraSite is to promote the governance of all types of IT assets that are SOA/non‐SOA related.

BenefitsThe benefits of managing external assets are:

Granular control and visibility over the development of IT assets.

Reuse of IT assets.

CentraSite allows consumers to search the registry for assets and provide an environment that fosters the reuse of IT assets.

Central governance even for assets that are managed by disparate components.

Integrates multiple tools in the production lifecycle from design over test to deployment

Technical ApproachThe goal is to manage the lifecycle of an asset even if these are managed by tools which do not have lifecycle management built‐in, or if they cover only a certain phase of an asset’s lifecycle. As a result, assets can be governed over their whole lifecycle, even if the tools producing and manipulating them do not support such functionality.

Usually, such assets are under the control of the external tool, including storage and access. In order to manage their lifecycle with the help of CentraSite, the assets must be made known to CentraSite. The amount of data transferred to CentraSite can vary from just basic metadata (e.g., the name), to more complete information, or even to the whole asset. In the least integrated solution, assets are manually transferred between the external system and CentraSite, which involves just the normal UI of CentraSite. In a more integrated approach, assets are transferred to CentraSite programmatically, either using CentraSite’s APIs or by providing a dedicated importer. In each of these cases, information about the lifecycle state of the assets can be passed along with the asset’s data. As an extension, tools could publish lifecycle state updates in between their management task.



On the other hand, assets must be retrieved from CentraSite (possibly based on their lifecycle state) and transferred to the external tool. This is typically done via CentraSite’s APIs.

Lifecycle models can be customized for each asset type, to reflect the specific lifecycle as dictated by the usage of an external management tool.

Looking up Assets Filtered by Lifecycle StateThe preferred way to look up assets is using the JAXR interface of CentraSite. This allows applying filters on lifecycle states and other attributes, and also provides access to versioning information and lifecycle states

Management of Additional AssetsDepending on the nature of the assets, they can be mapped to predefined CentraSite types, or custom CentraSite types can be created using the CentraSite extensibility features.

Custom CentraSite types can be created via the CentraSite UIs, e.g., CentraSite Control. After creation, the type has to be exported into an archive, also via the UI. At a customer site this archive must be imported into CentraSite either via UI or (preferably) via the importer API to deploy the type definition. This method is preferred over type creation at the customer site because the latter would cause a different UUID for the type at each customer site, which might cause problems in later migration scenarios.

CentraSite provides an extension to the JAXR API which allows publication of assets of any CentraSite type, including custom types. The publication should capture all metadata relevant in for the CentraSite management purposes. The corresponding types should have attributes defined to reflect these metadata, if they can be predicted. For this purpose, the type management UI can be used, or existing types can be extended using the type management API. However, CentaSite also allows extending any asset by additional, not pre‐planned metadata.

Manipulating the Lifecycle StateThe lifecycle state of an asset can be changed according to the lifecycle model assigned to the corresponding type. There is a dedicated API as an extension to the JAXR API to access and manipulate lifecycle state information. The change in a lifecycle state can trigger a design‐time policy, which can be used, for example, to do consistency checks on assets, or to trigger approval workflows.



Watching and CheckingDesign‐time/change‐time policies can be defined to watch changes in lifecycle states for specific lifecycle models and specific asset types, and react appropriately (for example, by sending notifications or by performing checks and triggering approval workflows). Policies can also be used to trigger updates in the external management system (for example, to reflect approval). For this purpose, custom policy actions have to be created in CentraSite.

These policies can be defined using the CentraSite UI, and can be exported to create deployment‐ready archives. At the customer site, these archives can be imported to make the policies available. The policies will be inactive after import, so the policy UI or API has to be used to activate them.

Custom ImportersCentraSite provides an open framework for adding new types of importers. These can have any input, and can use CentraSite’s JAXR interface for registering their assets. These importers will appear integrated with CentraSite’s UI.

Additional ConsiderationsAuthentication against CentraSite is mandatory for any of these interfaces. The authenticating user must have the necessary privileges to assets in CentraSite.

For iterative processes, the usage of the CentraSite versioning capabilities should be considered, which allows having multiple versions of one asset, with each version possibly being in a different lifecycle state.

To support governance and create system overviews, CentraSite reports can be defined using the Eclipse based report definition, and can be published to CentraSite from Eclipse. They can be exported, and then at a customer site imported into CentraSite. For the creation of reports, information has to be extracted from CentraSite using XQuery.

Lifecycle management of externally managed assets makes sense only if the external management tool has a basic integration with CentraSite, e.g., to publish the assets. Otherwise, synchronization issues might occur that decrease the value of the approach. Hence, usage of custom importers, which usually are a method for non‐invasive data extraction, should not be used to publish assets to CentraSite. Usage of federation with a custom mediator might be an option if the external management system provides appropriate query interfaces.




JAXR and CentraSite’s extensions

LCM API

Versioning API

Reports generation, export, import, XQuery

Federation (incl. federation framework and custom mediators)

Design time policies (UI, API), including custom actions

Custom Importers



6 Federation

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40




6 Federation

OverviewSOA deployments tend to span organizational and governance boundaries. Organizations large and small prefer to have local autonomy over their SOA deployments, but also need to seamlessly integrate their services with those in SOA deployments of other organizations. In order to meet the requirement of local autonomy while providing seamless integration and interoperability globally, SOA deployments must federate with other SOA deployments using open standards.

In such a federation, multiple degrees of heterogeneity can occur: products from different vendors can be involved; standards other than UDDI might be supported by the products involved; and even the level of detail of the information provided in the different environments may differ.

GoalMetadata is normally distributed among several registries. The user is not interested in the hierarchical details, but in the information in the satellite registry. The primary goal of the federation between CentraSite and other registries is to provide visibility into the Enterprise IT information, and enable end‐to‐end management of SOA.

BenefitsThe benefits of registry federation are:

The interconnection of several registries with CentraSite provides a master registry for access of all information in the enterprise.

This integration increases the reuse of assets.

Since all the existing available assets are made available in the single master registry, an architect can identify and reuse existing assets for new IT initiatives.

Technical ApproachCentraSite provides an extensible framework for federation. CentraSite‐to‐CentraSite federation can be used out‐of‐the‐box. In addition, federation with other systems providing a UDDI v2 or v3 interface is provided as part of the product. This includes retrieving (pulling) data from such systems as well as populating (pushing) these systems with data from CentaSite. This just requires configuration of the appropriate URLs. For federation with systems that do not provide UDDI as their interface, custom mediation plug‐ins for the federation framework can be provided that do the translation between the foreign system’s data model and protocol and JAXR. The framework provides an infrastructure to specify filters for such mediation plug‐ins, which allow restricting the amount of data included in the federation. As a prerequisite for federating data into CentraSite, the foreign system must provide a query interface that allows


6 Federation

retrieving the information of the foreign system (taking the filter into account) in a set‐based manner. If modification timestamps are not provided by the foreign system, the mediation plug‐ins must compute the difference between the newly‐retrieved data and the data already handled by federation to publish only the difference. For the management of authentication information for the foreign system, please refer to the federation manual.

References to API Sections of This DocumentAPIs that are relevant to this context are:

[To be determined.]



6 Federation


7 Integration with Configuration Management Databases (CMDBs)

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


UI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47




OverviewSOA Governance is part of a larger IT Governance effort. Customers are using the Information Technology Infrastructure Library (ITIL) to underpin their IT Governance approach. SOA Governance should be considered part of this. Release management and run‐time operations management are Service Support ITIL processes that allow for the planning and management of the successful rollout of software and related hardware. These processes are controlled by configuration management databases (CMDBs).

A CMDB holds a complete record of all configuration items (CIs) associated with the IT Infrastructure, software, and hardware. It includes information about servers, storage devices, networks, middleware, applications, services and data (e.g., versions, location, documentation, and components and their relationships).

Integration between CentraSite and a CMDB allows an Enterprise Architect to manage the service lifecycle from concept to operations.

GoalSOA is introducing many independent and self‐contained moving parts—that is, components that are typically widely reused across the enterprise and are a vital part of mission‐critical business processes. The primary goal of the integration between CMDB and CentraSite is to provide end‐to‐end view of SOA deployments. This solution enables you to integrate, or federate, your existing SOA and CMDB repositories to provide a shared, current view of your IT environment. Navigating from a SOA‐centric view of assets (covered by CentraSite) from the more technical view in the CMDB UI )and vice versa) provides an integrated view of the whole environment over tool boundaries.


Assess the business impact of IT issues quickly.

To help IT operations staff track the lifecycle of service assets and analyze root cause of SOA‐level failures.

Capture, document, and store physical components and logical elements without introducing uncontrolled redundancy.

Reduce the costs and risks of managing new services and making changes to existing ones.



Technical ApproachTo enable the link between the CMDB’s data and the assets in CentraSite, there must be at least one type of object that is kept in both the CMDB and CentraSite. Typically, this will be web services, although other assets could be used as well. Application servers and hosts are often also modeled both in CMDB and in CentraSite (while business processes typically are not reflected in a typical CMDB). In addition, both tools might model organizational structures. For such assets, the information in both systems must be kept in sync.

A deep integration of the CMDB tool might consist of the lookup of services in CentraSite and the publishing of services (or other assets) to CentraSite. CentraSite provides open APIs for these tasks.

A less invasive and more symmetric approach is to federate the CMDB and CentraSite using CentraSite’s extensible federation facilities. The federation approach requires that the CMDB has an interface to retrieve assets (in order to federate information from the CMDB to CentraSite) and to publish assets (for the reverse direction).

Deep Integration

Looking up Web ServicesUDDI v2 or UDDI v3 can be used for web service lookup. Note that web services are registered in CentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configuration of CentraSite, unauthenticated access using these interfaces will yield access to all services visible to “Everyone” in CentraSite. Authenticated access yields access to all services visible to the authenticated user. Note that access to the WSDL file might require authentication. Lifecycle information for web services is available as keyedReference in the businessService data. Version information cannot be retrieved via UDDI.

The preferred way to lookup web services is using the JAXR interface of CentraSite. This also provides access to versioning information and lifecycle states.

Publishing Web ServicesFor publishing web services, the usage of UDDI or JAXR is possible, but discouraged due to the complex structure representing a web service that is introduced by the technical note “Using WSDL in a UDDI registry”. Instead, the CentraSite API for web service registration should be used, which registers a service based on its WSDL. This API is also available via a web service interface. It handles the proper versioning of services in CentraSite.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user must have the necessary privileges in CentraSite to publish web services.



Note that published web services can be categorized with the EA tool’s name to indicate their origin. For this purpose, the EA tool can register itself with the “Products” taxonomy in CentraSite, optionally even providing a product icon.

Publishing and Looking Up Other AssetsCentraSite provides�

Documents

SOALink “Cookbook” - InfoQ.com€¦ · 12 CentraSite SOA Cookbook Version 1.0 Run-Time Integration Scenarios SOA run‐time solutions provide a wide range of functionality, from