Version 8.0 2008-12-17 Design Time Scenarios

Version 8.0 2008-12-17 Design Time Scenarios

This document applies to SOALink Cookbook v8.0 Version 8.0 2008-12-17 and to all subsequent releases.

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

Copyright © Fujitsu and Software AG 2008.All rights reserved.

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

Table of Contents................. 1Design Time Scenarios................. 1Design Time Scenarios................. 2Enterprise Architecture................. 2Enterprise Architecture................... 2Overview.................... 2Goal.................... 2Benefits................. 3Technical Approach............... 4Looking up Web Services............... 4Publishing Web Services.............. 4Publishing Business Processes.............. 5Looking up Business Processes............. 5Mapping Organizational Structures............... 5Synchronizing Information............. 5Management of Additional Assets............... 6Additional Considerations.................. 6UI Integration............... 6References and Background.............. 7Integration with Development Tools.............. 7Integration with Development Tools................... 7Overview.................... 7Goal.................... 7Benefits................. 8Technical Approach............... 9References and Background............ 10Integration with Quality Management Tools............ 10Integration with Quality Management Tools................... 10Overview.................... 10Goal.................... 11Benefits................. 11Technical Approach............... 12Looking up Web Services............... 12Looking up BPEL Processes................ 12Publishing Test Results.............. 12Triggering Tests from CentraSite............. 13Viewing Test Results in CentraSite.................. 13UI Integration............... 13Additional Considerations.............. 13References and Further Reading.......... 15Lifecyle Management of Externally-Managed Assets.......... 15Lifecyle Management of Externally-Managed Assets................... 15Overview.................... 15Goal.................... 15Benefits................. 15Technical Approach........... 16Looking up Assets Filtered by Lifecycle State............. 16Management of Additional Assets.............. 17Manipulating the Lifecycle State

iDraft: 17 Dec 2008 16:29

Design Time ScenariosDesign Time Scenarios

................. 17Watching and Checking

.................. 17Custom Importers

................ 17Additional Considerations

............... 17References and Further Reading

..................... 19Federation

..................... 19Federation

.................... 19Overview

..................... 20Goal

..................... 20Benefits

.................. 20Technical Approach


........ 22Integration with Configuration Management Databases (CMDBs)

........ 22Integration with Configuration Management Databases (CMDBs)

.................... 22Overview

..................... 23Goal

..................... 23Benefits


.................. 24Deep Integration

.............. 25Federating the CMDB and CentraSite

................... 26UI Integration


................ 27Workflow Systems Integration

................ 27Workflow Systems Integration

.................... 27Overview

..................... 27Goal

..................... 27Benefits


..... 28Creation and Management of SOA Assets as Part of an Enterprise Workflow

.............. 28Starting a Workflow out of CentraSite


Draft: 17 Dec 2008 16:29ii


Design Time ScenariosThis document describes several design-time scenarios.

The content is organized under the following sections:

Enterprise Architecture Describes the integration of Enterprise Architecture toolswith CentraSite.

Integration with Development ToolsDescribes the integration of development tools withCentraSite.

Integration with Quality Management Tools

Describes the integration of quality management toolswith CentraSite.

Lifecyle Management ofExternally-Managed Assets

Describes the management of external assets.

Federation Describes federation between CentraSite and otherregistries.

Integration with ConfigurationManagement Databases (CMDBs)

Describes how to integrate your existing SOA and CMDBrepositories to provide a shared, current view of your ITenvironment.

Workflow Systems Integration Describes the integration of workflow engines into theSOA lifecycle.

1Draft: 17 Dec 2008 16:29


Enterprise ArchitectureOverview

Goal

Benefits

Technical Approach

UI Integration

References and Background

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, andtechnology infrastructure. EA is primarily tasked to identify the enterprise capabilities needed to supportbusiness objectives. EA utilizes a top-down approach to defining the business processes (which are madeof services) that are needed to achieve the business objectives.

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

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

BenefitsThe benefits of the integration are:

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

Draft: 17 Dec 2008 16:292

Design Time ScenariosEnterprise Architecture

EA Tools are primarily used for planning purposes. The integration with an SOA registry/repositorysolution provides an EA tool with the ability to enforce standardized EA governance processes and toautomate these processes through the use of dynamic design-time and run-time policies. For example, inan EA tool, new services are identified and can be put under governance by registering them into the SOAregistry/repository tool. These services can be tracked in the registry as they go through the various SDLCstages, 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 reuseexisting services for new IT initiatives.

Business processes can be governed over their entire lifecycle, integrating all tools participating inthis 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 thesynchronization 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 tothe 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 ofEnterprise Architecture tools. However, their further lifecycle is not tracked in the EA tool. Whenintegrating with CentraSite, the assets as modeled in the EA tool will be published to CentraSite, and willbe managed from here. On the other hand, relevant lifecycle information from CentraSite (e.g., retirementor the availability for production) should be synchronized back to the EA tool. Furthermore, assets thatexist in CentraSite but not in the EA tool (e.g., services provided by third parties) should be made knownto the EA tool as well.

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

Looking up Web Services

Publishing Web Services

Publishing Business Processes

Looking up Business Processes

Mapping Organizational Structures

3Draft: 17 Dec 2008 16:29

Enterprise ArchitectureDesign Time Scenarios

Synchronizing Information

Management of Additional Assets

Additional Considerations


UDDI v2 or UDDI v3 can be used for web service lookup. Note that web services are registered inCentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configurationof CentraSite, unauthenticated access using these interfaces will yield all services visible to “Everyone” inCentraSite. Authenticated access yields access to all services visible to the authenticated user. Note thataccess to the WSDL file might require authentication. Lifecycle information for web services is availableas 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 providesaccess to versioning information and lifecycle states.


For publishing web services, the usage of UDDI or JAXR is possible but discouraged, due to the complexstructure representing a web service that is introduced by the technical note “Using WSDL in a UDDIregistry”. Instead, the CentraSite API for web service registration should be used, which registers a servicebased on its WSDL. This API is also available via a web service interface. It handles the proper versioningof services in CentraSite.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user musthave 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. Forthis purpose, the EA tool can register itself with the “Products” taxonomy in CentraSite, optionally evenproviding a product icon.

Publishing Business Processes

CentraSite provides an API for registering business processes described in BPEL (also available via webservice 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 partnerlink”, and “BPEL role”. Usage of this API is preferred over using UDDI or JAXR here to ensure aconsistent 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 asXPDL.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user musthave 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 EAtool export BPEL or XPDL to the file system, and in a second step import this into CentraSite using theCentraSite UI.

Draft: 17 Dec 2008 16:294


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, optionallyeven providing a product icon.

Looking up Business Processes

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


CentraSite requires that all assets (services, business processes, and so on) are assigned an owningorganization. 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 tosynchronize 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 organizationsis provided which also allows for easier handling of organization hierarchy.

Synchronizing Information

The usage of the CentraSite federation feature for synchronizing is recommended only if the EA tool hasan interface that allows for easy outside access or publishing. If this is the case, organizational structurescould 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/toCentraSite using its own discretion.

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


Depending 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 tocustom 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 canbe created via the CentraSite UIs, e.g., CentraSite Control. After creation, the type has to be exported intoan archive, also via the UI. At a customer site this archive must be imported into CentraSite either via UIor (preferably) via the importer API to deploy the type definition. This method is preferred over typecreation at customer site, because the latter method would cause a different UUID for the type at eachcustomer site, which might cause problems in later migration scenarios.

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

5Draft: 17 Dec 2008 16:29

Enterprise ArchitectureDesign Time Scenarios


Besides assets, the knowledge about dependencies and relationships between components, which isavailable in the EA tool, should be conveyed to CentraSite, typically in the form of an association or arelationship 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 CentraSiteextension to JAXR to manipulating lifecycle states of assets. Newly-created assets are assigned a lifecyclestate by CentraSite based on the rules defined in CentraSite. It is not expected that EA tools have the needto manipulate the lifecycle state of assets.

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

UI IntegrationSwitching back and forth between the user interfaces of CentraSite and the EA tool might be desirable inseveral use cases, e.g., to drill deeply down into technical dependencies or usage data from the EA tool, orto explore the EA level information from CentraSite. Hence, an easily link from the CentraSite UI to theEA 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 andstored 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 requiresauthentication, a corresponding screen to enter the authentication information will be displayed before theactual targeted screen is displayed.

References and BackgroundBackground information that is relevant in this context:

Access via UDDI

CentraSite JAXR API

Importing/Exporting Registry Objects

API for versioning CentraSite registry assets (Javadoc)

API for programming CentraSite lifecycle management infrastructure (Javadoc)

Draft: 17 Dec 2008 16:296


Integration with Development ToolsOverview

Goal

Benefits

Technical Approach

References and Background

Overview4th Generation Integrated Development Environment (IDE) tools, such as Eclipse, reduce the time fordeveloping software. These tools offer productivity-enhancing features, such as real-time syntax checking,code completion, refactoring support, various wizards, integrated build management, integration withversion 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 tointegrate with standard development tools, such as Eclipse or Visual Studio, thereby providing thedeveloper with a uniform user experience.

The semantic capabilities and the context awareness of these development tools make metadata (as theyare 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, heneeds a user-friendly way to browse and search available and reusable services. Once the service is foundthey need an easy way to consume the service in their code. Development tools could utilizestandards-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 shouldbe possible within the development tool.

GoalThe primary goal of the integration with development tools and CentraSite is to improve the productivityof 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 anddrop, or copy and paste.

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

7Draft: 17 Dec 2008 16:29

Integration with Development ToolsDesign Time Scenarios

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 theworking environment.

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

The functionality provided includes:

Configuration of multiple CentraSite connections, of which one can be active at any time. Credentialsare 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 repositorydocuments.

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 associationsbetween 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 usingJAXR and XQuery.

Plugins are bundled into three features: for the UI, for the reporting support, and for the CentraSiteinterface libraries. When installing into Software AG Designer through the webMethods Installer, the usercan choose the UI plugins, and optionally the reporting support. Similarly, when installing using theEclipse update manager, the reporting feature will require the UI feature, which in turn requires theinterface 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 likeCentraSite Control. In fact, to a great extent the same libraries are used. All server-based mechanisms likepolicy enforcement, lifecycle management, and permission and role checks are applied in the same way.

Draft: 17 Dec 2008 16:298

Design Time ScenariosIntegration with Development Tools

The assets shown and edited are all server-based, meaning that they are not file-based resources, and onlyin-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 inthe CentraSite perspective, which arranges the above-mentioned plugins into a default layout. The usercan, as usual, customize this layout. When using CentraSite in conjunction with other products, selectedviews can be added to other perspectives (and in fact are included in some default layouts of Software AGproducts). For example, the registry tree navigator can be used in the Process Development perspective toselect a service, drag it to the process canvas, and drop it there to create a process step invoking thatservice. This type of integration is based on the Eclipse drag-and-drop framework. Commands contributedto 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 datasources added to this framework are used to define the data sets for a report, which is then built in theusual way. The report can be previewed in the BIRT editor and published to the CentraSite server fromthe report project.

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

References and BackgroundPlease refer to the standard Eclipse documentation for more information on the Eclipse UI and Eclipseextension points.

9Draft: 17 Dec 2008 16:29

Integration with Development ToolsDesign Time Scenarios

Integration with Quality Management ToolsOverview

Goal

Benefits

Technical Approach

References and Further Reading

OverviewEnterprise SOA applications are, by nature, complex and heterogeneous, involving the interaction of manydistributed development teams and stakeholders to leverage multiple technology assets. An organizationmove 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, theincreasing use of service and application SLAs requires minimal disruption during frequent updatesto services.

Therefore, an end-to-end quality management approach is needed to counter the challenges posed bydecentralization, modularity, and increased complexity. An SOA quality management strategy shouldaccount for testing across multiple integration layers, both at business process and service level and acrossa variety of SOA delivery platforms.

GoalThe primary goal of integrating SOA Quality Management tools and CentraSite is to enable end-to-endquality 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 stateimplies quality assurance of an asset.

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

Draft: 17 Dec 2008 16:2910

Design Time ScenariosIntegration with Quality Management Tools

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

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

Ensures compliance and customer satisfaction through predictability and high quality SOAimplementations.

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

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

The streamlined processes enable the user to realize SOA “return on investment” through greaterreuse 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 publishedback to CentraSite. In a more extended scenario, tests can be triggered from CentraSite, and test resultscan be viewed in CentraSite.


Looking up BPEL Processes

Publishing Test Results

Triggering Tests from CentraSite

Viewing Test Results in CentraSite

11Draft: 17 Dec 2008 16:29

Integration with Quality Management ToolsDesign Time Scenarios

UI Integration



UDDI v2 or UDDI v3 can be used for web service look up. Note that web services are registered inCentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configurationof CentraSite, unauthenticated access using these interfaces will yield all services visible to “Everyone” inCentraSite. Authenticated access yields access to all services visible to the authenticated user. Note thataccess to the WSDL file might require authentication. Lifecycle information for web services is availableas 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 providesaccess to versioning information and lifecycle states.

Looking up BPEL Processes

BPEL processes can be looked up using the JAXR API.

Publishing Test Results

Metadata about tests (e.g., the tool used for testing, the date of the last test, success or failure, etc.) can beattached to the service as type-specific or object-specific attributes. To extend the service type usingtype-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 typemanagement 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 integratedinto the generic CentraSite GUI, or even a separate generic test history profile can be created without anyprogramming effort. Object-specific attributes, in contrast, need no preparation at all, and can be added toservices at any time, but always appear in the CentraSite profile for object-specific attributes. In case theUI 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 updatingthe web service.

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

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

Triggering Tests from CentraSite

SOA 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 betested, e.g., using WS-PolicyAttachment.

Draft: 17 Dec 2008 16:2912


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

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

Viewing Test Results in CentraSite

File attributes can be assigned to profiles, permitting you to control where they are displayed. For testreports, this can be used to place the test report file attribute (see above) at a prominent place to allowaccess to the report by a simple click. If external links are used to link the test report, this can be accessedvia 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 thequality management tool’s information to the service type using the extensible web UI technology ofCentraSite by providing a custom plug-in.

UI Integration

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

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


For most of these interfaces, authentication against CentraSite is mandatory. The authenticating user musthave 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 thatdisplay, for example, an overview about the relationship between tested/untested assets, ration of testfailed, etc. CentraSite reports can be defined using the Eclipse-based report definition, and can bepublished to CentraSite from Eclipse. They can be exported, and then at a customer site imported intoCentraSite. For the creation of reports, information has to be extracted from CentraSite using XQuery.

References and Further ReadingBackground information that is relevant in this context:

13Draft: 17 Dec 2008 16:29

Integration with Quality Management ToolsDesign Time Scenarios

Access via UDDI

CentraSite JAXR API

CentraSite WebDAV Functionality

The CentraSite Control Pluggable Architecture

Using WS-Policy Attachment

Working with Reports and Report Templates

CentraSite XQJ Interface

Please refer to the standard Eclipse documentation for more information on the Eclipse UI and Eclipseextension points.

Draft: 17 Dec 2008 16:2914


Lifecyle Management of Externally-Managed Assets

Overview

Goal

Benefits

Technical Approach


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 businessservices start appearing that bridge these silos. These services/assets span multiple environments andgovernance 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 areSOA/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 fostersthe 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 havelifecycle 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 donot support such functionality.

15Draft: 17 Dec 2008 16:29

Lifecyle Management of Externally-Managed AssetsDesign Time Scenarios

Usually, such assets are under the control of the external tool, including storage and access. In order tomanage their lifecycle with the help of CentraSite, the assets must be made known to CentraSite. Theamount of data transferred to CentraSite can vary from just basic metadata (e.g., the name), to morecomplete information, or even to the whole asset. In the least integrated solution, assets are manuallytransferred 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 usingCentraSite’s APIs or by providing a dedicated importer. In each of these cases, information about thelifecycle state of the assets can be passed along with the asset’s data. As an extension, tools could publishlifecycle state updates in between their management task.

On the other hand, assets must be retrieved from CentraSite (possibly based on their lifecycle state) andtransferred 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 theusage of an external management tool.

Looking up Assets Filtered by Lifecycle State


Manipulating the Lifecycle State

Watching and Checking

Custom Importers


Looking up Assets Filtered by Lifecycle State

The preferred way to look up assets is using the JAXR interface of CentraSite. This allows applying filterson lifecycle states and other attributes, and also provides access to versioning information and lifecyclestates


Depending on the nature of the assets, they can be mapped to predefined CentraSite types, or customCentraSite 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 beimported 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 differentUUID 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 CentraSitetype, including custom types. The publication should capture all metadata relevant in for the CentraSitemanagement purposes. The corresponding types should have attributes defined to reflect these metadata, ifthey can be predicted. For this purpose, the type management UI can be used, or existing types can beextended using the type management API. However, CentraSite also allows extending any asset byadditional, not pre-planned metadata.

Draft: 17 Dec 2008 16:2916

Design Time ScenariosLifecyle Management of Externally-Managed Assets

Manipulating the Lifecycle State

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

Watching and Checking

Design-time/change-time policies can be defined to watch changes in lifecycle states for specific lifecyclemodels and specific asset types, and react appropriately (for example, by sending notifications or byperforming checks and triggering approval workflows). Policies can also be used to trigger updates in theexternal management system (for example, to reflect approval). For this purpose, custom policy actionshave to be created in CentraSite.

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

Custom Importers

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


Authentication against CentraSite is mandatory for any of these interfaces. The authenticating user musthave the necessary privileges to assets in CentraSite.

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

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

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


17Draft: 17 Dec 2008 16:29

Lifecyle Management of Externally-Managed AssetsDesign Time Scenarios

CentraSite JAXR API


API for programming CentraSite lifecycle management infrastructure (Javadoc)

Working with Reports and Report Templates


CentraSite XQJ Interface

Federated Repositories

Developing Custom Actions

Draft: 17 Dec 2008 16:2918

Design Time ScenariosLifecyle Management of Externally-Managed Assets

FederationOverview

Goal

Benefits

Technical Approach


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

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

The architecture with CentraSite as master is shown below.

The architecture with CentraSite as slave is shown below.

19Draft: 17 Dec 2008 16:29

FederationDesign Time Scenarios

GoalMetadata is normally distributed among several registries. The user is not interested in the hierarchicaldetails, but in the information in the satellite registry. The primary goal of the federation betweenCentraSite and other registries is to provide visibility into the Enterprise IT information, and enableend-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 allinformation 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 canidentify and reuse existing assets for new IT initiatives.

Technical ApproachCentraSite provides an extensible framework for federation. CentraSite-to-CentraSite federation can beused out-of-the-box. In addition, federation with other systems providing a UDDI v2 or v3 interface isprovided as part of the product. This includes retrieving (pulling) data from such systems as well aspopulating (pushing) these systems with data from CentraSite. This just requires configuration of theappropriate URLs. For federation with systems that do not provide UDDI as their interface, custommediation plug-ins for the federation framework can be provided that do the translation between theforeign system’s data model and protocol and JAXR. The framework provides an infrastructure to specifyfilters 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 interfacethat allows retrieving the information of the foreign system (taking the filter into account) in a set-basedmanner. If modification timestamps are not provided by the foreign system, the mediation plug-ins must

Draft: 17 Dec 2008 16:2920

Design Time ScenariosFederation

compute the difference between the newly-retrieved data and the data already handled by federation topublish only the difference. For the management of authentication information for the foreign system,please refer to the federation manual.



21Draft: 17 Dec 2008 16:29

FederationDesign Time Scenarios

Integration with Configuration ManagementDatabases (CMDBs)

Overview

Goal

Benefits

Technical Approach


OverviewSOA Governance is part of a larger IT Governance effort. Customers are using the InformationTechnology Infrastructure Library (ITIL) to underpin their IT Governance approach. SOA Governanceshould be considered part of this. Release management and run-time operations management are ServiceSupport ITIL processes that allow for the planning and management of the successful rollout of softwareand 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 theirrelationships).

Integration of CentraSite with a CMDB allows Enterprise Architects to manage the service lifecycle fromconcept to operations.

Draft: 17 Dec 2008 16:2922

Design Time ScenariosIntegration with Configuration Management Databases (CMDBs)

GoalSOA is introducing many independent and self-contained moving parts—that is, components that aretypically 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 SOAdeployments. This solution enables you to integrate, or federate, your existing SOA and CMDBrepositories to provide a shared, current view of your IT environment. Navigating from a SOA-centricview 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-levelfailures.

Capture, document, and store physical components and logical elements without introducinguncontrolled 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 typeof object that is kept in both the CMDB and CentraSite. Typically, this will be web services, althoughother assets could be used as well. Application servers and hosts are often also modeled both in CMDBand 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 bekept in sync.

A deep integration of the CMDB tool might consist of the lookup of services in CentraSite and thepublishing 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’sextensible federation facilities. The federation approach requires that the CMDB has an interface toretrieve assets (in order to federate information from the CMDB to CentraSite) and to publish assets (forthe reverse direction).

Deep Integration

Federating the CMDB and CentraSite

UI Integration

23Draft: 17 Dec 2008 16:29

Integration with Configuration Management Databases (CMDBs)Design Time Scenarios

Deep Integration


UDDI v2 or UDDI v3 can be used for web service lookup. Note that web services are registered inCentraSite according to the technical note “Using WSDL in a UDDI registry”. In the default configurationof 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 authenticateduser. Note that access to the WSDL file might require authentication. Lifecycle information for webservices is available as keyedReference in the businessService data. Version information cannot beretrieved via UDDI.

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


For publishing web services, the usage of UDDI or JAXR is possible, but discouraged due to the complexstructure representing a web service that is introduced by the technical note “Using WSDL in a UDDIregistry”. Instead, the CentraSite API for web service registration should be used, which registers a servicebased on its WSDL. This API is also available via a web service interface. It handles the proper versioningof services in CentraSite.

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user musthave 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. Forthis purpose, the EA tool can register itself with the “Products” taxonomy in CentraSite, optionally evenproviding a product icon.

Publishing and Looking Up Other Assets

CentraSite provides an extension to the JAXR API which allows publication of assets of any CentraSitetype, including custom types (see [need link to “Management of Additional Assets”).

For any of these interfaces, authentication against CentraSite is mandatory. The authenticating user musthave the necessary privileges in CentraSite to assets.


CentraSite requires that all assets (services, business processes, and so on) are assigned an owningorganization. These organizations are modeled in CentraSite, and can form a hierarchy (for example,representing departments in a company). As a CMDB might provide a similar capability, it makes sense tosynchronize the organization models. UDDI can be used to retrieve and update organization information,excluding organization hierarchy. Via the JAXR API, a richer view of organizations is provided.


Depending on the CMDB model, even more assets are modeled that are relevant to CentraSite, e.g., fordependency modeling. Depending on their nature, they can be mapped to custom CentraSite types usingthe CentraSite extensibility features, or mapped to taxonomies. For grouping assets (e.g., to reflect aproject structure), the JAXR type “Package” can be used.

Draft: 17 Dec 2008 16:2924


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 beimported 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 adifferent UUID for the type at each customer site, which might cause problems in later migrationscenarios.

Taxonomies can be created via the standard JAXR interfaces for Classification Schemes and Concepts.They cannot be created via UDDI because UDDI does not provide means to specify allowed values fortaxonomies via UDDI calls.


Besides assets, the knowledge about dependencies and relationships between components (which isavailable in the CMDB) should be conveyed to CentraSite, typically in the form of an association or arelationship attribute.

Services defined in CMDB can be published to CentraSite, and services defined in CentraSite can bepublished in CMDB. However, if services are to be defined in CMDB and then further developed (i.e.,guided through the lifecycle) in CentraSite, the versioning information is not exposed via UDDI. It isexposed only via the JAXR interface. In addition, there is a CentraSite extension to JAXR for creation andadvanced handling of versions. The WSDL importer APIs can be relied upon to handle versionsappropriately.

Services defined in CMDB can be published to CentraSite, and services defined in CentraSite can bepublished in CMDB. However, if services are to be defined in CMDB and then further developed (i.e.,guided through the lifecycle) in CentraSite, the versioning information is not exposed via UDDI. It isexposed only via the JAXR interface. In addition, there is a CentraSite extension to JAXR for creation andadvanced handling of versions. The WSDL importer APIs can be relied upon to handle versionsappropriately.

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

CentraSite enables you to define design-time policies which can be used to enforce certain conditions onassets stored in CentraSite. Depending on the policies defined in a CentraSite instance, the publication ofservices, business processes, etc., from the EA tool may fail. This is not a fundamental issue to theintegration; it is just a matter of configuration of a CentraSite instance. The same holds for userconfiguration and privileges.

Federating the CMDB and CentraSite

CentraSite provides an extensible federation framework, which manages the replication andsynchronization of data in CentraSite and another data management system (in this case, the CMDB).Out-of-the-box, this federation framework provides for UDDI- and JAXR-based federation. As it isunlikely that the CMDB provides an interface that supports these protocols, a custom mediator has to bebuilt. The custom mediator must map objects from the CMDB to JAXR objects, using the CMDB’sinterfaces for publishing and retrieval, and CentraSite’s JAXR interface. This mediator can be easilyplugged into CentraSite’s federation framework. A mediator supporting CMDBf as a standard protocol forexchange is planned for the future.

25Draft: 17 Dec 2008 16:29

Integration with Configuration Management Databases (CMDBs)Design Time Scenarios

Where federation cannot be applied, another method of data transfer can be used (at leastunidirectionally): if the CMDB is able to export information to a file, a custom importer can be added toCentraSite to interpret this file and create appropriate CentraSite assets.

UI Integration

Switching back and forth between the user interfaces of CentraSite and the CMDB management systemmight be desirable in several use cases, e.g., to review usage relationships from the CMDB managementsystem, or to explore the IT environment from CentraSite. Hence, an easily link from the CentraSite UI tothe CMDB management UI, and vice versa, is beneficial.

For this purpose, CentraSite provides deep link capability, i.e., each screen can be addressed by adedicated URL. Hence, such links could be added to the CMDB management tool’s UI.

In exchange, if the CMDB management tool UI provides a similar capability, these URLs can be passed toCentraSite 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 requiresauthentication, a corresponding screen to enter the authentication information will be displayed before theactual targeted screen is displayed.

References and Further ReadingAPIs that are relevant in this context are:

Access via UDDI

CentraSite JAXR API

CentraSite JAXR extensions (Javadoc)


The Lifecycle Management API


Draft: 17 Dec 2008 16:2926


Workflow Systems IntegrationOverview

Goal

Benefits

Technical Approach


OverviewSOA Governance is defined as “The art and discipline of managing outcomes consistent with measurablepreconditions and expectations through structured relationships, procedures, and policies applied to theorganization and utilization of distributed capabilities that may be under the control of different ownershipdomains”. Implementing SOA Governance as a part of IT governance often implies enterprise-widepolicies and procedures, which can result in enterprise-wide work flows. In the course of such a workflow,one or more SOA assets may be created whose metadata and lifecycle information are persisted andmanaged in CentraSite. This should be an integral part of the overall workflow. On the flip side, changesin the lifecycle state of an SOA asset in CentraSite might cause a complex work flow due to an enterprisepolicy. While simple work flows such as approval are provided by CentraSite out-of-the-box, CentraSiteis not a workflow management system, and hence, more complex workflows cannot be managed byCentraSite alone.

The integration of workflow engines into the SOA lifecycle is critical for governance because:

The vision of an enterprise-wide SOA can be achieved in a structured and process-oriented way.

Workflow is comprised of services that are used for both human- and system-oriented workflow.

GoalThe primary goal of CentraSite is to promote the governance of all types of IT assets that areSOA/non-SOA related. IT Departments have large investments in ITIL processes that are used for SOAGovernance. These ITIL processes could be implemented using a business process/workflow engine. ITManagers might have a need to control all or some of the asset lifecycle using these ITIL processes.CentraSite is flexible enough to integrate with the external Business process/Workflow engine to providethis functionality.

BenefitsWorkflow provides another way for architects to create a human-oriented and multi-step design- andchange-time policy action that could be triggered during the lifecycle state of a CentraSite asset. Thisenables granular control and visibility over the development of IT assets.

27Draft: 17 Dec 2008 16:29

Workflow Systems IntegrationDesign Time Scenarios

Technical ApproachCreation and Management of SOA Assets as Part of an Enterprise Workflow

Starting a Workflow out of CentraSite

Creation and Management of SOA Assets as Part of an Enterprise Workflow

In a workflow, CentraSite access such as creation of an asset can be achieved via a web service, which issupported by most workflow management systems. Currently, this requires the usage of UDDI, as this is aweb service-based interface, whereas JAXR is not. For the creation of web service assets and businessprocess assets, CentraSite provides dedicated web services.

Operations should be executed under the credentials of the user acting in the respective workflow step.This requires configuration of this user with an appropriate role in CentraSite.

There is no out-of-the-box web service to access lifecycle management and versioning interfaces, but thiscan be easily implemented.

Starting a Workflow out of CentraSite

To attach a workflow to a lifecycle state change (for example, from state1 to state2), the following isrecommended:

1. Introduce an intermediary lifecycle step, e.g., a step called state2_pending, which appears betweenstate1 and state2. Allow transition from state2_pending to state2 only for the user that corresponds tothe workflow in order to prevent another user to pass by the workflow. The intermediate status isneeded because the workflow is a long-running external activity, which currently cannot be part of apolicy action.

2. On transition from state1 to state2_pending, attach a policy that triggers the work flow, for example,a policy that initiates the work flow process in an asynchronous manner (e.g., by calling a webservice). As a best practice, you should enhance the asset with a pointer to the work flow instance,and optionally with a link (URL) to the page representing this instance in the UI of the workflowmanagement system. This could be done as the first activity of the workflow. Doing this in the policyaction in CentraSite might be difficult because it needs data passed back from the work flowmanagement system.

3. As last step of the workflow, change the state of the asset to state 2 using the lifecycle managementAPI. As mentioned above, this can easily be wrapped into a web service if necessary.

References and Further ReadingAPIs that are relevant to this context are:

Access via UDDI


Draft: 17 Dec 2008 16:2928

Design Time ScenariosWorkflow Systems Integration


The Lifecycle Management API

Using WS-Policy Attachment

User and role management

29Draft: 17 Dec 2008 16:29

Workflow Systems IntegrationDesign Time Scenarios

Documents

Version 8.0 2008-12-17 Design Time Scenarios