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.
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.
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:
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:
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:
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.
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: For more information, see:
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.
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.
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: