SCA nodes simplify interoperability between IBM® WebSphere® Process Server V6.2 (hereafter referred to as Process Server) and IBM WebSphere Message Broker (hereafter referred to as Message Broker). They support both outbound scenarios (Message Broker flow invoking an SCA endpoint on Process Server) and inbound scenarios (Message Broker flow behaving as an SCA endpoint and invoked by a business process hosted on Process Server). Application integration is supported using both "bottom-up" integration (export SCA SCDL from Message Broker for use by business process on Process Server), and "top-down" integration (import SCA SCDL from Process Server to kick-start message flow creation on Message Broker).
This article introduces the new SCA nodes, and describes toolkit wizards and techniques to develop an SOA solution using Message Broker and Process Server, which will be of interest to architects, message flow designers, and developers.
Service Component Architecture (SCA) provides a programming model for building applications and systems based on SOA. It is based on the idea that business function is provided as a series of services, which are assembled to create solutions that serve a particular business need. Key benefits of SCA:
- Components integrate with other components without needing to know how those components are implemented (loose coupling).
- Components can be easily replaced by other components (flexibility).
- Services can be easily invoked either synchronously or asynchronously.
- Components can be easily integrated to form composite applications (productivity).
With SCA, services are packaged as components with an interface. Different implementation types are allowed for a component, but the invocation mechanism for a service component is the same across the varied implementation types. In addition, services can be associated with bindings, which enable invocations to be made using various protocols, such as JMS messaging or Web services, independent of the actual service implementation.
Figure 1. SCA Component
Figure 1 shows the parts that make up an SCA component. A component is an instance of an implementation that has been configured by a configuration file. The configuration file is defined in an XML-based format called Service Component Definition Language (SCDL). The implementation is the code that actually provides the component's functions, such as a Java class or a BPEL process. The configuration, expressed in SCDL, defines how that component interacts with the outside world. Every SCA component contains a:
- A service is used to describe what operations can be accessed by a consumer of this component. A service has an interface that describes the operations that are available to be consumed. The interface can be defined using a Java interface or by Web Services Description Language (WSDL).
- A reference is used to describe which services provided by other components are needed. A reference also has an interface that describes the operations that need to be invoked.
- A binding defines exactly how to communicate with an SCA component. Services and references specify a binding that is used for communication. By having bindings, a component's business logic can be separated from communication details.
- A component can define one or more properties. Each property has a value that is defined in the SCDL configuration file.
Process Server is used for hosting SOA-based composite applications. It is a secure, robust, and scaleable environment in which mission-critical business processes can be deployed and run. Process Server supports a consistent programming model for representing data, invoking services, and structuring composite applications. You can develop these composite applications using WebSphere Integration Developer (hereafter referred to as Integration Developer). Within Process Server, services are defined and invoked in a uniform way using SCA, with each service defined as a component with an interface. The services can be associated with import or export components that enable services to be invoked using different means of communication, such as Web services or MQ.
Figure 2 shows an example of how components are defined in Integration Developer. An Import allows a component to access services from another component. An Export allows a component to externalise its services for other components to consume. Both imports and exports require binding information that specifies the communication details for accessing the services:
Figure 2. SCA components used in Process Server and Integration Developer
Five new SCA nodes have been provided in WebSphere Message Broker V7. These nodes simplify interoperability between applications hosted on Message Broker and Process Server. These nodes are configured using SCDL information and they enable communication with Process Server using Web service or MQ bindings.
Enable Message Broker to expose services that can be consumed by business process applications hosted on Process Server. The SCAInput node receives an inbound message from the business process, and the SCAReply node sends the response back. This enables an application running on Message Broker to behave as an SCA endpoint. An Import component must be used by the business application to access the services offered by the Message Broker application. Figure 3 shows how Message Broker processes an inbound SCA message:
Figure 3. Processing inbound SCA messages
SCARequest, SCAAsyncRequest, SCAAsyncResponse
Enable Message Broker applications to consume services provided by business processes hosted on Process Server. An Export component must be used by the business application to enable its services to be consumed by the Message Broker application. The SCARequest node is used to send an outbound message to Process Server. The message is sent synchronously, which means that the message flow will wait for a specified amount of time for the response to be returned before flow processing continues. The SCAAsyncRequest and SCAAsyncResponse nodes are used to send an outbound message asynchronously, which means that after the message has been sent by the SCAAsyncRequest Node, flow processing can continue as the response is received by the SCAAsyncResponse node. Figure 4 shows how Message Broker processes an outbound SCA message:
Figure 4. Processing outbound SCA messages
The SCA nodes are configured by a new Message Broker artifact called a Broker SCA Definition, which resides within a Message Set project. The Message Set project is referenced by the message flow. The SCA nodes cannot be configured without a Broker SCA Definition.
The Broker SCA Definition contains all the information needed to communicate with business processes residing on Process Server, including the SCDL (contains binding and property information), WSDL (defines the interface being used), and XSD (defines the message model). There are two types of Broker SCA Definition: an inbound Broker SCA Definition, which has a suffix of .insca, and an outbound Broker SCA Definition, which has a suffix of .outsca.
The inbound Broker SCA Definition is used to configure SCAInput and SCAReply nodes. The outbound Broker SCA Definition is used to configure SCARequest, SCAAsyncRequest and SCAAsyncResponse nodes. An inbound Broker SCA Definition is derived from an SCA Import component, while an outbound Broker SCA Definition is derived from a SCA Export component. Figure 5 shows where the Broker SCA Definition artifact resides within a Message Set Project:
Figure 5. Broker SCA Definition
The SCA nodes can be configured using drag-and-drop, or by manually selecting the Broker SCA Definition in the property. In addition, you can create SCA nodes by dragging and dropping the Broker SCA Definition directly onto the Message Flow Editor:
Figure 6. Drag and drop support
Application integration is greatly simplified by new wizards that help Message Broker developers to import or export SCA components.
You can import SCA components into Message Broker using the SCA Importer Wizard, which can import SCA Import or SCA Export components contained within a Project Interchange file (PI file) that was previously exported from Integration Developer. To invoke the SCA Importer wizard, select the message set and then select New => Message definition file from => SCA import or export, using the context menu:
Figure 7. SCA Importer Wizard
After the Importer Wizard has completed, a Broker SCA Definition is created in the Message Set project, and the associated message model is created in the Message Set within the Message Set Project. If an SCA Import had been imported, an inbound Broker SCA Definition (.insca) is created. If an SCA Export had been imported, an outbound Broker SCA Definition (.outsca) is created. Once created, the Broker SCA Definition can be used to create and configure SCA nodes in a message flow.
The importer checks if the SCA Import or SCA Export is valid during the import process. An error is raised if the SCA Import or Export does not meet certain constraints. These include:
- The SCA Import or SCA Export must contain a Web service or MQ binding.
- The SCA Import or SCA Export must contain an interface.
A Broker SCA Definition is created after the Importer Wizard completes, but it can also be created without importing a PI file from Integration Developer. A Broker SCA Definition can be generated from an existing message set that has one or more message definition files. To invoke the Generate Broker SCA Definition Wizard, select the message set and then select Generate => Broker SCA Definition, using the context menu as shown in Figure 8:
Figure 8. Generate Broker SCA Definition Wizard
The Generate Broker SCA Definition Wizard creates a Broker SCA Definition using artifacts in the message set and values specified by the user, and it creates an .outsca or .insca Broker SCA Definition, which is stored under the Broker SCA Definitions folder within the chosen message set project. You must specify the following values in the Generate Broker SCA Definition Wizard:
- A message set to create the .outsca or .insca Broker SCA Definition.
- An Inbound (.insca) or Outbound (.outsca) Broker SCA Definition.
- A name for the created SCA Import/Export within the SCA Broker SCA Definition
- The interface used by the Broker SCA Definition. Select either:
- An existing deployable WSDL that defines a portType
- A new set of operations to be contained in a generated portType. For new operations, you must specify operation name, operation type, and data types used by the input and output messages.
- The binding type: select either Web Services or MQ.
- The properties needed by either the Web services or the MQ binding.
The generated .outsca or .insca Broker SCA Definition contains
- A single .import (SCA Import) or .export (SCA Export) component.
- A WSDL containing one portType with one or more operations.
- XSDs that correspond to the messages used in the operations defined in the portType.
You can use the Broker SCA Definition to configure SCA nodes after it has been generated. The generator wizard allows a message flow that currently uses MQ or SOAP transport nodes to be updated to take advantage of the new SCA nodes.
A Broker SCA Definition is an artifact that can only be used while developing Message Broker applications. It cannot be used by business processes developed in Integration Developer. SCA Components can be exported from a Broker SCA Definition using the SCA Exporter and then imported into an existing project in Integration Developer. To invoke the Exporter Wizard, select the message set and then select Export from the context menu as shown in Figure 9. You must choose which Export Wizard to launch. Select SCA import or export from Broker SCA Definition, as shown in Figure 10:
Figure 9. SCA Exporter Wizard
Figure 10. Selecting the SCA Exporter Wizard
The following artifacts are exported from Message Broker by the SCA Exporter:
- SCA import or SCA export
You may choose to export to an external directory or to a workspace directory. After you have exported the SCA components, they may be imported into Integration Developer and wired up to a business process. To import the SCA components that you exported from Message Broker, select the project in Integration Developer and then select Import from the context menu, as shown in Figure 11 below. Then select File system under the General category as shown in Figure 12 below. Specify the directory that you used for exporting the SCA components from Message Broker.
Figure 11. Import SCA components into Integration Developer
Figure 12. Select import from file system
After importing into Integration Developer, the SCA Export or SCA Import is shown in the Assembly diagram and can be wired up. The interface, data types, and SCA Export or SCA Import can be seen in the project in the Business Integration view. You may have to take corrective action in Integration Developer if you are using an existing interface and interface partner that you want to replace with the interface that you have imported from Message Broker.
A new Quick Start wizard lets you quickly start building up an application using SCA nodes. To launch it, select Quick Starts => Start from SCA Import or Export:
Figure 13. SCA Quick Start Wizard
- Top-down integration
- The Importer Wizard allows a top-down development approach. A business integration developer can develop the business processes first in Integration Developer, export the project to a PI file, and then import it into Message Broker to create a message model and a Broker SCA Definition that is used to configure SCA nodes in message flows.
- Bottom-up integration
- The Generator and Export Wizards allow a bottom-up development approach. A Message Broker developer can develop a Message Broker application first and then export SCA components from a Broker SCA Definition. You can then import the exported SCA components into Integration Developer and wire them up to a business process.
The SCAInput and SCAReply nodes are used for processing inbound messages received from Process Server using Web service or MQ bindings. They are configured by an inbound Broker SCA Definition (.insca) artifact.
The SCARequest, SCAAsyncRequest, and SCAAsyncResponse nodes are used for processing outbound messages sent to Process Server using Web service or MQ bindings. They are configured by an outbound Broker SCA Definition (.outsca) artifact.
The SCA nodes are binding agnostic -- they can be configured irrespective of the binding being used. There is a single Binding tab on the SCAInput node, and the properties that are displayed in the Binding tab are dependent on the binding found in the SCDL contained within the Broker SCA Definition. The properties' values are automatically populated using the values specified in the SCDL (and from WSDL in the case of Web services binding). The SCA nodes model the same characteristics as the SOAP and MQ nodes, except that their binding properties are configured automatically by the Broker SCA Definition. You can override the binding properties on the node, but make sure that the SCA Import or SCA Export used by the business process application has the same changes reflected in it.
The SCAInput node also has dynamic terminals that let you configure how messages should be routed from the node. These terminals are determined by operations contained in the WSDL interface file. An incoming message is routed to the appropriate terminal depending on the target operation. If you don't want to use dynamic terminals, you can configure the node to use a common out terminal instead, in which case the dynamic terminals are deleted from the node in the message flow canvas, and at runtime, all messages are routed to the common out terminal. Figure 14 shows that the SCAInput node has dynamic terminals that enable messages to be routed to two different subflows. Dynamic terminals are currently available only for the Web service binding.
Figure 14. Dynamic terminals
Web services binding
If the SCAInput node is configured to use a Web services binding, then the node listens for incoming Web services requests on port 7800 (HTTP) or 7843 (HTTPS) by default. Messages can be propagated with or without the SOAP envelope and SOAP headers. The setting is configurable via a Propagate only SOAP body checkbox on the SCAInput node, as shown in Figure 15. By default, the entire SOAP message (including the envelope and headers) is propagated in the SOAP domain. If the checkbox is checked, then the SOAP envelope and headers are stored in the local environment and the SOAP message body is propagated under the XMLNSC domain. The checkbox is greyed out if the common out terminal is used rather than dynamic operation terminals, because the entire SOAP message is propagated when the common out terminal is used.
Figure 15. Propagate SOAP body checkbox
If the SCAInput node is configured to use an MQ binding, then the node performs an MQGET on the specified MQ Queue. The SCAInput Node supports all MQ data bindings used by Process Server, and therefore supports both XML and non-XML data. The message is propagated according to the Message Domain property in the Input message parsing Properties tab. By default, if the data binding in the SCDL indicates that all operations are using XML (com.ibm.websphere.sca.mq.data.impl.MQDataBindingImplXML or com.ibm.wbiserver.datahandler.xml.XMLDataHandler) then the XMLNSC domain is selected, otherwise the BLOB domain is selected. You can override the default domain and select the most appropriate domain for the type of data. For example, you can select the MRM domain to parse non-XML messages, such as CSV or COBOL messages, using a pre-existing message set.
Sending a reply message
If a Web service binding is being used and WS-Addressing is enabled on the SCAInput node, the SCAReply node sends a reply to the URI within the WSA ReplyTo property. Otherwise the reply is sent back to the sender. When processing MQ messages, the SCAReply node uses the Reply-to destination in the MQMD Header of the inbound message to send the reply to the appropriate queue and queue manager. The SCAReply node also uses the Report property that is specified in the MQMD header of the inbound message to set the correlation id in the reply message that is sent back to Process Server.
The SCAInput node always creates a Reply Identifier that allows the SCAReply node to send a response back to the originating client. If the SCAReply node is in a separate flow from the SCAInput node, then you must store the ReplyIdentifier that is created by the SCAInput node and make it available in the flow containing the SCAReply node. The Reply Identifier is available in LocalEnvironment.Destination.SCA.Reply.ReplyIdentifier. If the SCAReply node is in a separate flow, make sure that the flows containing the SCAInput and SCAReply nodes are deployed to the same execution group.
Receiving a one-way message
If the SCAInput node receives a message for an operation that is defined as a one-way operation, then for Web services, an HTTP 202 acknowledgment is sent back. If the SCAReply node is wired up, then the SCAReply performs a no-op and the input message is just propagated though the output terminal without sending back a reply message. If the Broker SCA Definition contains an interface that only has one-way operations defined, then only an SCAInput node is created when you drag and drop the inbound Broker SCA Definition onto the Message Flow Editor.
Local environment information available for inbound processing
The local environment can be used to access values set by the SCA nodes during inbound processing. as shown in Table 1:
Table 1. Local environment information set by the SCA nodes during inbound processing
|Local environment property||Description|
|LocalEnvironment.SCA.Input.Operation||Access the operation that is being called on an inbound request|
|LocalEnvironment.Destination.SCA.Reply.ReplyIdentifier||Reference to the originating client for sending a reply to inbound messages|
Sending an outbound message to Process Server synchronously
The SCARequest node is used to send an outbound message to Process Server synchronously, which means that the Message Broker thread blocks until a response is received within the specified timeout period. It is not related to how Process Server handles the message. If no response is received within the timeout period, the input message for the SCARequest node is propagated to its failure terminal with an exception list. The timeout period is specified in the node, as shown in Figure 16. The property can be overridden by setting a property in the local environment.
Figure 16. Request Timeout property
Sending an outbound message to Process Server asynchronously
The SCAAsyncRequest node and SCAAsyncResponse node are used together to send a request and receive a response message asynchronously, which means that the Message Broker thread does not wait for the Process Server application to respond before continuing. Again, it is not related to how Process Server handles the message. When the response is received by Message Broker, it is handled by a separate SCAAsyncResponse node, thus allowing multiple outbound requests to be sent in parallel. The SCAAsyncResponse node may reside in a separate message flow from the SCAAsyncRequest node, but both nodes must be in flows that have been deployed to the same execution group. A unique identifier specifies the logical pairing of SCAAsyncRequest and SCAAsyncResponse nodes. You can share data between the SCAAsyncRequest and SCAAsyncResponse nodes by storing and retrieving data from the local environment.
Web services binding
The SCARequest Node and SCAAsyncRequest node send a SOAP message to the URL specified in the Web service URL property, with the target operation specified in the Operation property. Both the URL and operation can be changed on the node or by overriding properties in the local environment, and the operation must be available in the drop-down combo list. An error will also be reported at runtime if you specify an incorrect URL or if you specify an operation that is not in the drop-down combo list.
The SCARequest and SCAAsyncResponse node have a Fault terminal, which is used only when the binding is Web services. If the business process on Process Server sends a SOAP Fault back, then the fault message is propagated to the Fault terminal.
You can also configure the SCARequest and SCAAsyncResponse nodes to specify whether the entire SOAP message or just the payload (SOAP Body) should be propagated. The setting is configurable via a Propagate only SOAP body checkbox on the SCARequest or on the SCAAsyncResponse node. By default, the entire SOAP message is propagated. If only the SOAP body is propagated, then it is owned by the XMLNSC domain.
The SCARequest and SCAAsyncRequest have MQ binding properties taken from the SCDL contained in the outbound Broker SCA Definition. These include the Queue and Queue Manager names to which the outbound message should be sent, and the Reply-to Queue and Reply-to Queue Manager that receive the response messages back from Process Server. You can also specify which operation to invoke in the Operation property. The possible values are taken from the WSDL contained in the outbound Broker SCA Definition. The properties used when an MQ binding is specified are shown in Figure 16 above.
When an MQ binding is used, the following properties are set at runtime in the header of the message that is sent to the business process on Process Server:
- Defined in the usr folder in MQRFH2 in the request message sent to Process Server. It is set to the operation specified on the node, and can be overridden in the local environment.
- Reply-to Queue Manager and Reply-to Queue
- Set in the MQMD according to reply-to properties on the node, which can be overridden in the local environment.
- Report property
- Set in the MQMD according to the Response Message Correlation property set on the node.
If the interface defined for the SCA Export has more than one operation defined and you are starting application development from Integration Developer, make sure that the function selector defined on the SCA Export has the MQ uses JMS default function selector option selected:
Figure 17. Function Selector
Sending a one-way message
Only an SCARequest node can be used for sending one-way outbound messages to a business process on Process Server. If you select a one-way operation, then the Reply-to Queue, Reply-to Queue Manager, and Response Message Correlation properties are greyed out. For one-way MQ messages, a datagram message type is specified in the MQMD header sent in the outbound message. If the outbound Broker SCA Definition contains an interface that only has one-way operations defined, then only an SCARequest node is created when you drag and drop the outbound Broker SCA Definition onto the Message Flow Editor. When you use the SCARequest node to send a one-way message, a copy of the input message is propagated from the out terminal.
Local environment information available for outbound processing
The local environment can be used to override values set by the SCA nodes during outbound processing. The last entry in the table for UserContext is not for a node property that can be overridden, but has been made available for storing data to be passed between the SCAAsyncRequest and SCAAsyncResponse nodes, as shown in Table 2:
Table 2. Local environment information set by the SCA nodes during outbound processing
|Local environment property||Description|
|LocalEnvironment.Destination.SCA.Request.Operation||Change operation to invoke for an outbound message|
|LocalEnvironment.Destination.SCA.Request.Timeout||Change timeout (SCARequest node only)|
|LocalEnvironment.Destination.SCA.Request.Binding.WebServices.Transport.HTTP.WebServiceURL||Change URL for Web services binding for an outbound message|
|LocalEnvironment.Destination.SCA.Request.Binding.MQ.queueManagerName||Change the Request Queue Manager for MQ binding for an outbound message|
|LocalEnvironment.Destination.SCA.Request.Binding.MQ.queueName||Change the Request Queue for MQ binding for an outbound message|
|Store and retrieve context data in the local environment (SCAAsyncRequest and SCAAsyncResponse nodes only)|
Application integration using Message Broker, Integration Developer, and Process Server can benefit from using SCA nodes in the following ways:
- The SCA nodes simplify application integration and improve consumability when using Message Broker with Process Server. It takes just a few clicks using the various wizards to configure a Message Broker application to communicate with Process Server. Prior to Message Broker V7, you had to spend time developing the message model and configuring the binding details on the transport nodes.
- If the business process application decides to change its communication method, you just have to import a new PI into Message Broker to update the SCA nodes to use a new binding. The binding tab on the SCA nodes shows specific binding properties according to the binding specified in the SCDL contained in the Broker SCA Definition. Therefore it is easy to swap between using Web services or MQ bindings on the same node. Prior to Message Broker V7, it was awkward to swap between using SOAP nodes and MQ nodes.
- The SCAReply node is binding-agnostic. If you have multiple SCAInput with different bindings, then you can have a single SCAReply for sending a response back. If you were using the SOAP or MQ nodes, you would need separate SOAPReply and MQOutput nodes for sending replies back to Process Server.
- You can migrate from existing applications to use the new SCA nodes by generating a Broker SCA Definition and a message set and then using the generated outbound or inbound Broker SCA Definition to configure the SCA nodes.
- It is easy to import SCA components into Message Broker using the Importer Wizard. You simply export the PI file from Integration Developer and then use the Importer Wizard to import it into Message Broker, which creates the message model and configures the SCA nodes. If you tried to do this manually by exporting XSD and WSDL, you could introduce errors if you started from the wrong WSDL.
- It is easy to export SCA components from Message Broker using the Exporter Wizard. The wizard exports the SCDL, XSD, and WSDL artifacts that can be imported into Integration Developer. Prior to Message Broker V7, you would have to manually export these components and be careful to configure the binding details on the SCA Import or SCA Export in Integration Developer. Using the exporter wizard, you can be sure that the exported SCDL contains the correct binding details.
- The SCA nodes contain the option in the nodes to either propagate the entire SOAP message or just the SOAP Body. The SOAP Nodes have no option to propagate the SOAP Body only. You have to use a SOAPExtract node to propagate the SOAP Body downstream.
- The SCAInput node has dynamic terminals that enable the node itself to route the message to the relevant operation terminal based on the target operation found in the message at runtime. The SOAP nodes, on the other hand, do not have dynamic terminals -- you have to manually configure the flow so that routing is done after the nodes, based on content.
- Drag-and-drop enables easy creation and configuration of the SCA nodes. You can create synchronous (SCARequest) or asynchronous (SCAAsyncRequest/SCAAsyncResponse) nodes from the outbound Broker SCA Definition. The SCAInput and SCAReply nodes are created and configured from an inbound Broker SCA Definition. Drag-and-drop also determines what nodes can be created if the interface only has one-way operations defined.
- For the MQ Binding, the SCARequest and SCAAsyncRequest nodes automatically fill in the appropriate information in the MQMD of the message that is sent to Process Server. If you try to use the MQ Nodes, you have to use the MQHeader node to fill in the TargetFunctionName and set correlation id information.
- For the MQ Binding, the SCAReply node sets the correlation id according to what is specified in the SCDL. If you try to use the MQ nodes, you have to set the correlation id using a Compute or MQHeader node.
- You can change various property values by overriding the value in the local environment. You cannot do the equivalent for MQ nodes (such as overriding the operation to invoke, or storing data in the UserContext when using the SCAAsyncRequest and SCAAsyncResponse nodes.
- The SCAInput node creates a Reply Identifier accessible in the local environment. If you have a request node in between the SCAInput and SCAReply nodes, you can still send a reply back to the originating client by storing the ReplyIdentifier. The MQ nodes have no equivalent functionality.
WebSphere Message Broker V7 introduces five new nodes for simplifying interoperability with Process Server: SCAInput and SCAReply nodes for handling inbound messages (Message Broker flow invoked by a business process hosted on Process Server) and SCARequest, SCAAsyncRequest, and SCAAsyncResponse nodes for handling outbound messages (Message Broker flow invokes an SCA endpoint on Process Server). New wizards simplify application integration and let you use either top-down (starting from Integration Developer) or bottom-up (starting from Message Broker) integration. You can use the nodes with Web services or MQ bindings. In summary, you should use SCA nodes whenever you need to integrate your Message Broker application with a business process hosted by Process Server.
This article includes an animated, self-running Flash demo that guides you through the steps of using SCA nodes in WebSphere Message Broker V7. Download the zip file below, unzip it, and click on the file sca_demo_viewlet_swf.html.
|Animated self-running demo of SCA nodes||SCA_nodes_demo.zip||14 MB||HTTP|
- WebSphere Message Broker V7 information center
A single Web portal to all WebSphere Message Broker V7 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
- WebSphere Message Broker interoperability with WebSphere Process Server
This topic in the WebSphere Message Broker V7 information center shows you how to develop applications that can communicate with WebSphere Process Server using SCA nodes.
- Sample code for WebSphere Message Broker SCA nodes
This link will work only if you have WebSphere Message Broker V7 installed. The SCA node samples are located in the samples gallery under Samples => Transports and connectivity => SCA nodes.
- Introduction to SCA
An introductory article on SCA concepts from David Chappell and Associates. (PDF, 1.4 MB)
- SCA project at the Open Service Oriented Architecture (OSOA) Collaboration
The SCA project at the OSOA Collaboration is a group of SCA and SOA experts working to define a series of SCA specifications in order to make them freely available to the industry.
- What's new in WebSphere Message Broker V7
WebSphere Message Broker V7 provides universal connectivity with its ability to route and transform messages from anywhere to anywhere. This article describes the major enhancements in V7.
- WebSphere Message Broker developer resources page
Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
- WebSphere Message Broker product page
Product descriptions, product news, training information, support information, and more.
- WebSphere Message Broker documentation library
WebSphere Message Broker specifications and manuals.
- WebSphere Message Broker forum
Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
- WebSphere Message Broker support page
A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
- Download free trial version of WebSphere Message Broker V6.1
WebSphere Message Broker V6.1 is an ESB built for universal connectivity and transformation in heterogeneous IT environments. It distributes information and data generated by business events in real time to people, applications, and devices throughout your extended enterprise and beyond.
- WebSphere Integration Developer V6.2 information center
A single Web portal to all WebSphere Integration Developer V6.2 documentation, with conceptual, task, and reference information.
- WebSphere Process Server V6.2 information center
A single Web portal to all WebSphere Process Server V6.2 documentation, with conceptual, task, and reference information.
- developerWorks WebSphere developer resources
Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals.
- developerWorks WebSphere application connectivity developer resources
How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application connectivity and business integration solutions.
- developerWorks WebSphere SOA and Web services developer resources
How-to articles, downloads, tutorials, education, product info, and other resources to help you design and build WebSphere SOA and Web services solutions.
- Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
- WebSphere forums
Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
- WebSphere on-demand demos
Download, watch, and learn what WebSphere products and WebSphere-related technologies can do for your company.
- WebSphere-related books from IBM Press
Convenient online ordering through Barnes & Noble.
- developerWorks blogs
Join a conversation with developerWorks users and authors, and IBM editors and developers.
- developerWorks on Twitter
Check out recent Twitter messages and URLs.
Sanjay Nagchowdhury is a software developer on the WebSphere Message Broker development team at the IBM Hursley Software Lab in the UK. You can contact Sanjay at email@example.com.