WebSphere

Management

A service-oriented architecture (SOA) helps you to manage services more easily. This section covers the management of Service Component Architecture (SCA) modules that invoke your services.

Introduction

With an enterprise service bus (ESB) you can manage your services more easily, so you can respond faster to changing business needs. You can manage the SCA modules that invoke your services, from the administrative console, from the command line, and from scripts.

With an ESB you can mediate between service requesters (consumers) and service providers. If you use WebSphere® ESB, mediation flows occur in a type of SCA module that WebSphere Integration Developer calls a mediation module. If you use WebSphere Process Server, mediation flows can occur either in mediation modules or in a type of SCA module that WebSphere Integration Developer simply calls a module. The administrative console refers to both mediation modules and modules as SCA modules.

This section deals primarily with the management of SCA modules that contain mediation flows. Mediation primitives are the building blocks of mediation flows and each mediation primitive lets you do different things with a message.
Note: It is often the case that WebSphere Process Server modules do not contain mediation flows.

Managing SCA modules

After you have deployed an SCA module to the run time, you might want to do a number of tasks to manage your service flows:

Enabling service connectivity flows

Each SCA module has an associated application. In order for service connectivity flows to be enabled, the application has to be started. By default, the application starts automatically when the server starts. However, you might want to enable the service connectivity immediately after you deploy your mediation module.

Use the administrative console to start the application associated your with your SCA module. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.

Changing SCA module properties without redeploying your module

WebSphere Integration Developer allows you to make some SCA module properties visible to the runtime administrator. SCA module properties that are visible to the administrator are called promoted properties.

WebSphere Integration Developer lets you give alias names to promoted properties; and it is the alias names that are displayed on the administrative console. For more information, see: Click this link to go to the topic for WebSphere Integration Developer.

You can use the administrative console to change the value of promoted properties without having to redeploy an SCA module, or restart the server or module. However, any changes that are made at runtime do not affect the integration development version of the module.

Mediation flows start to use the value of a changed property as soon as the configuration update is visible to their server. In a network deployment environment this occurs after a node's synchronization of configuration data with its Deployment Manager. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.

Changing service endpoints

At run time, there are various ways in which you can change the service endpoint that an SCA module invokes.

For example, suppose you have a mediation module, Transform, that does message enhancement and transformation, and invokes another mediation module, Route, to do message routing. If you want the Transform module to call a different routing module, you can do this in the runtime environment if the mediation modules connect to each other using the default (SCA) bindings.

Any changes that you make to an SCA module at run time do not affect the integration development version. Therefore, if you want to change an SCA module permanently you might typically change it in the integration environment, and redeploy the SCA module.

The following examples describe some of the ways you can change service endpoints at run time:
  • If you have an SCA module that invokes another SCA module, using SCA bindings, you can use the administrative console to change which SCA module is invoked: Applications > SCA Modules > Imports > Binding. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.
  • If you have an SCA module that directly invokes a Web service, you can use the administrative console to change the Web service that is invoked: Applications > SCA Modules > Imports > Binding. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.
  • If you have an SCA module that gets its service endpoints from a database, you can determine which services get invoked by updating the database.
  • If you have an SCA module that gets its service endpoints from a registry, you can determine which services get invoked by updating the registry or by updating the query that is used. You can only use a registry to provide certain types of service endpoints. For more information, see: Click this link to go to the topic for WebSphere Integration Developer. Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere Process Server.

Changing the registry used by an SCA module

At run time, you can change which WebSphere Service Registry and Repository (WSRR) instance is used by your mediation flow.

If the Endpoint Lookup mediation primitive (used in your SCA module) does not specify a registry, the mediation flow makes use of the default WSRR definition. If the integration developer has promoted the Registry Name property, you can check to see if the property has a value.

You can change the default WSRR definition: Service integration > WSRR definitions, and set which WSRR definition you want to be the system default. For more information, see: Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere ESB for z/OS. Click this link to go to the topic for WebSphere Process Server. Click this link to go to the topic for WebSphere Process Server for z/OS.

If the integration developer has promoted the Registry Name property of the Endpoint Lookup mediation primitive, you can set the Registry Name value from the administrative console. You could set a particular SCA module to use a particular registry instance.

Validating messages

When designing your service flows, it might be a requirement to ensure that the message type at run time matches the message type definition. You can validate messages against their schema by using mediation primitives that have a Validate input property, for example, the XSLT and Message Element Setter mediation primitives.

Because message validation can impact performance, the integration developer would normally disable the Validate input property, but promote it. The runtime administrator could then enable message validation under certain circumstances.

Logging different parts of a message

When you design your service flows, it might be a business requirement to have an audit trail of service requests. You can log all messages that are sent by a service requester using the Message Logger mediation primitive.

The integration developer sets the Message Logger Root property to indicate what part of the message should be logged. If the integration developer promotes the Root property, the runtime administrator can change its value.

For example, if the integration developer sets the alias for the Root property to LogLevel and its value to /body, then the mediation flow would log the body of a message. At run time, the administrator might want to log the entire message, in which case he could set the value of LogLevel to /. For more information, see: Click this link to go to the topic for WebSphere Integration Developer. Click this link to go to the topic for WebSphere ESB. Click this link to go to the topic for WebSphere Process Server.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:38:41 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wbpm.scenarios.esb1.620.doc/concepts/cwesb_management.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on