Thursday, September 30, 2010

Developing Service Component Architecture (SCA) Applications Using Rational Application Developer (RAD) 7.5: Getting Started.

Service Component Architecture (SCA), Installation of SCA development tools in RAD and feature pack for WAS runtime, Development and Learning Material Links

Service Component Architecture (SCA) is an Open Service Oriented Architecture Collaboration’s (OSOA) emerging standard programming model.

Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages and a model for assembling service components into a business solution - activities which are at the heart of building applications using a service-oriented architecture.” – [1]

Rational Application Developer (RAD) Version 7.5.2 introduced a new installable feature – Service Component Architecture Development Tools.

“This feature provides a concise set of tools for developing Service Component Architecture service components implemented with annotated Java, for graphically wiring components together to form new composite services, for associating protocol bindings and quality of service intents to Service Component Architecture components, and for packaging Service Component Architecture assets and deploying them to the WebSphere Application Server.” – [2]

SCA Development Tools: Feature Pack Installation

The easiest way to install the SCA development tools for RAD is using the Installation Manager.

When you are doing an install/modify/update, make sure you select the feature “Service Component Architecture Development Tools”.

Installation Manager : SCA Feature Pack

If you have Test Environment, make sure you also select “feature pack for Service Component Architecture” for the runtime to support SCA applications.

Learning and Reference Material

You can find very good documentation on SCA and how to develop SCA applications using RAD on the IBM Info Center. Please use the following links to learn about the same.

IBM InfoCenter: Development Reference
OSOA: Development Reference
IBM InfoCenter: Tutorials
  1. Open Service Oriented Architecture Collaboration (OSOA)
  2. Rational Application Developer (RAD) V 7.5 Releases: New Features And Enhancements

Wednesday, May 26, 2010

Serializing and Deserializing Business Objects From and To XML Documents in WebSphere Integration Developer

Use BOXMLSerializer and BOXMLDocument interfaces to convert a Business Object to an XML string and vice versa in WebSphere Integration Developer.

Often times you will see a need to convert a given Business Object into an XML string and vice versa. You can serialize and deserialize a Business Object to and from a given XML string by using and interfaces.

BOXMLSerializer serializer = (BOXMLSerializer)new ServiceManager().locateService(“com/ibm/websphere/bo/BOXMLSerializer”);

Sample Java code to convert a Business Object to an XML String:

Let’s say you have your Business Object stored in a variable ‘inputDataObject’ (of type commonj.sdo.DataObject)

ByteArrayOutputStream outputStream = newByteArrayOutputStream();
String myXMLString = outputStream.toString(“UTF-8”);

“myXMLString” will hold the XML string corresponding to the Data Object “inputDataObject”.

Sample Java code to convert a given XML String to a Business Object:

Let’s say you have the XML string stored in a variable named ‘inputXMLString’ (of type java.lang.String)

BOXMLDocument document = serializer.readXMLDocument(new ByteArrayInputStream(inputXMLString.getBytes(“UTF-8”)));
commonj.sdo.DataObject myDataObject =document.getDataObject();

“myDataObject” will hold the Business Object corresponding to the XML string “inputXMLString”.

Note: The schema definition (xsd) corresponding to the Business Object that you are trying to convert the XML string into, should be available during runtime.

Wednesday, May 19, 2010

Fetching WSDL Properties From WebSphere Service Registry and Repository (WSRR) In WebSphere Integration Developer (WID) Using REST Calls

Learn how to Query WSRR using REST calls to fetch content and parse this content. In particular, the scenario of fetching a property value on a particular WSDL without using the IBM WSRR (Java (EJB) or SOAP) API is discussed. We will use a regular Java class to make REST calls to WSRR and parse thorough the retrieved content.

WebSphere Integration Developer (WID) 6.2 offers Endpoint Lookup mediation primitive to be used in mediation modules to lookup the endpoint of a particular service from WebSphere Service Registry and Repository (WSRR), but for scenarios where you have the endpoint or any other service related information stored as a property on the WSDL in WSRR, fetching a property without using the IBM WSRR (Java (EJB) or SOAP) API is discussed. We will use a regular Java class to make REST calls to WSRR and parse thorough the retrieved content.

Querying WSRR for Content:

You could use XPath expressions to query content in WSRR. Two types of Queries

Graph Query
The URL format for a REST call using Graph Query is:

XML/GraphQuery?query=<XPath expression>


[@name=’MyWebService.wsdl’ and @version=’1.0’]

The above URL will fetch the metadata associated with a 1.0 version of the WSDL named “MyWebService.wsdl”.

Property Query
The URL format for a REST call using Graph Query is:

<XPath expression>&p<#>=<property name>

# denotes a number starting from 1 and incremented by 1 for each additional property that you want to fetch.

You can use “&p<#>=<property name>” once for each property that you want to retrieve.The order of the #s can change.


[@name=’MyWebService.wsdl’ and @version=’1.0’]

Note: Make sure you use %27 for ‘, when you are using the URL from the browser to view the content.

Let us consider the scenario where I have a WSDL stored in WSRR with a property named ‘endpoint’. The value of the property will hold the endpoint URI for that service.

In-order to invoke a service from WID, we can create a utility class that hold the methods to fetch the information from WSRR and we can use this utility from any mediation. Once the endpoint is retrieved, you can save that information on the SMO to invoke your service dynamically with the fetched endpoint value.

The path on the SMO to store the endpoint for dynamic invocation is “smo/headers/SMOHeader/Target/address”.

Make sure you also select the “Use dynamic endpoint if set in the message header” option under “Details” section in the “Properties” view of either the “Callout” node or the “Service Invoke” primitive.

Fetching the property value involves two steps:

1. Fetch the content using REST call with a property query.
String resturl = "http://<host>:<port>/
URL url = new URL(resturl);
URLConnection urlConnection = url.openConnection();
BufferedReader reader = new BufferedReader
(new InputStreamReader(urlConnection.getInputStream()));
StringBuffer stringBuffer = new StringBuffer();
String line = null;
while(null != (line = reader.readLine()))

2. Parse the fetched content using an xml parser to read the value of the property.

String searchPath = "//*[local-name()='property'
 and @*[local-name()='name'='endpoint']]
DocumentBuilder documentBuilder =
Document contentDocument = documentBuilder.
parse(new InputSource(new StringReader
XPath xPath = XPathFactory.
XPathExpression xPathExpression = xPath.
String  endpoint = (String)xPathExpression.

The string endpoint will hold the value against the property named “endpoint” on the WSDL “MyService.wsdl” and version 1.0 that is in WSRR.

You could basically use the same method to fetch the value of any property on the WSDL. You can also fetch any other content from WSRR by creating appropriate queries using REST calls.

If you would like to use SOAP or Java (EJB) API for WSRR, you will need to use two jar files named
  • sdo-int.jar
  • ServiceRegistryClient.jar
You can find these jars in the installation directory of WSRR.

For more information on using the IBM API for WSRR use references below.

  1. Using DataPower SOA Appliances to query WebSphere Service Registry and Repository.
  2. WebSphere Service Registry and Repository Handbook.
  3. Query Content in WSRR – (WSRR Information Center).
  4. SOAP API Guide – (WSRR Information Center)

Tuesday, May 11, 2010

Dynamic Invocation Using IBM Service Component Architecture (SCA) Addressing API

This article highlights the steps involved in invoking imports with dynamic endpoints in WebSphere Integration Developer using Service Component Architecture (SCA) API. The static endpoints defined on the imports will be overridden by the dynamically selected endpoint value.

You have defined your imports with different bindings. You have defined your component which invokes these imports. Everything looks good….

What happens when you deploy the module in different environments? Will you change the endpoints on your imports with each deployment (e.g. for SOAP/HTTP web services)? How do you dynamically select endpoints for invoking the imports?

You can use the SCA Addressing API to dynamically invoke components using imports in WebSphere Integration Developer.

All wired/un-wired imports with any type of binding can be invoked with dynamic endpoints using SCA Addressing API. Shown below are some samples for some commonly used bindings.
  • Obtain the endpoint (for overriding the defaults on the import) based on a condition.
The endpoint can either be stored in a properties file or as a namespace binding on the WebSphere process server.

If you would like to store it in a properties file, you could use resource bundles to look-up the value.

You can define namespace binding using admin console @ Environment>Naming>Name space bindings. After defining the endpoint URL as a string, you can look it up by doing a JNDI look-up.

SCA endpoint URI format:




Web services (SOAP/HTTP) URI format:




If you have changed the context root and the URL mapping, then use the format that you have defined.

(SOAP/JMS) URI format: same as JMS URI format shown below.

Unless the binding type attribute on the EndpointReference object is set (sample shown below), the address is interpreted as a SOAP/JMS endpoint.

JMS endpoint URI format:




MQ endpoint URI format:

@<queueManager>? connectQueueManager=<qmgr>


  • Create new EndpointReference and set required attributes.
    // import
    // import
    EndpointReference eRef = EndpointReferenceFactory.
    eRef.setAddress(<Obtained String Endpoint Value(URI)>);
  • Selectively add attribute values to EndpointReference
If you are trying to use imports that are not wired to the component where you have this code, also add


If you are trying to invoke an import with JMS binding, you need to explicitly set the binding type by adding the following line of code.


For <bindingType>, you can use one of the following
  • Lookup the Service with the new endpoint reference and invoke the service
Service service = (
getService(<Reference Partner String Name>, eRef);
param_output = service.invoke(<method name>, param);

To find the <ReferencePartnerStringName>, select the component that you have wired to the imports and in the properties view and select the “Details” tab.

Please Refer to my previous post "Must-Have bookmarks for IBM WebSphere Integration Developers" for reference material.

Please use the references below for information on how to use dynamic endpoints with other bindings not mentioned above or for additional information on what is discussed here.

  1. IBM WebSphere Business Process Management Version 7.0 Information Center
  2. IBM WebSphere Application Server, Release 6 API Specification

Monday, May 3, 2010

Updating XML Maps in WebSphere Integration Developer When Service Message Object (SMO) Context Changes

Update XML maps when service context on Service Message Object (SMO) changes with out having to redo the existing mappings.

Consider the scenario in which you have created a mediation module where you used XSL Transformation primitive to transform messages and have chosen the Message Root for this primitive to be the root of the Service Message Object (SMO).

If you now try to set up the correlation, transient or shared context on the input node of the flow and want to do the mappings for the same in the XML maps that you originally created, the new object that was added to the context will not show up and you will see a warning message that the context type does not match as shown below.

Warning Message

How do I now update the XML map with out having to redo my mappings?

Right click on the XML map and select “Open With>XML Editor”. You will see all the mappings in an XML format. What you are looking for are the tags <mapping></mapping>.

XML Mappings
Now rename the current XML map to <name>_old and create a new one select the Message Root to be “/” and having the same input and output as the original map.

Once the map is created, right click and select “Open With>XML Editor”, and copy the mappings (all the <mapping> tags) from the old map to the new one.

Close the new XML map and reopen it using the Mapping Editor and you should see all your old mappings. You will also see the context of the SMO updated with your changes.

New Request Map With Correlation Context

When you have submaps in the original mappings, you can basically use them as-is. Any updates to the Business Objects will be reflected automatically on the XML maps.

Tuesday, April 27, 2010

Invoke Business Object Maps Using WebSphere Business Integration API

Use “” interface to invoke Business Object Maps from your Java Classes.

Using the MapService interface is pretty straight forward.
  1. Use class to lookup the MapService.
  2. Use appropriate methods on the MapService to invoke the Business Object Maps.
Let’s see a small example of how this is done. I have created a sample interface with one operation, an input BO (Business Object) (FromBO) and an Output BO (ToBO). I have also created a business object map to map from FromBO to ToBO. The picture below shows the details.

In the code sample below, the input to the operation is an instance of FromBO. We create an instance of ToBO and use the ‘simpleTranformation’ method on the MapService to invoke the ‘FromBO_ToBO_Map’ business object map.

public DataObject mapInputtoOutput(DataObject input1) {
               //create an instance of the output data object.
              BOFactory boFactory = (BOFactory)ServiceManager.INSTANCE.
              DataObject output1 = boFactory.create("http://SampleLib/com/test/bo", "ToBO");
              //locate the map service
             MapService serviceOne = (MapService)ServiceManager.INSTANCE.
             // invoke the business object map to do the transformation.
             try {
                                      "FromBO_ToBO_Map",input1, output1);
             } catch (WBIMapServiceException e) {
                      // TODO Auto-generated catch block
              } catch (WBIMapNotFoundException e) {
                     // TODO Auto-generated catch block
             } catch (WBIMapFailureException e) {
                   // TODO Auto-generated catch block
         return output1;

You can also use ‘transform’ method on the MapService interface if you would like to invoke business object maps that deal with transformations from multiple BOs to multiple BOs

Please check Must-Have bookmarks for IBM WebSphere Integration Developers for WAS API and other useful references.

Wednesday, April 21, 2010

WebsiteBaker: Customizing Multiflex-5 theme to add new blocks

Customize Multiflex-5 to add new blocks, display icons and add content.

Recently, I was looking for website themes for my personal website, to use with websitebaker and found Multiflex-5 which I really liked for its features and its simple looks.

You will get all the info that you need to customize your template @ Multiflex:5.0. All you need to do is to find something that you like on the above site, right click on the webpage and select “View Page Source / View Source”. You basically browse down to the section that you are looking for, and use that in your template.

I wanted to add a new block and add content to it as shown in the picture below

Thought it might be useful for others who want to do the same, if I post this information. So, here you go!

In-order to add new menus or new blocks, you need to modify “info.php” under <installation dir>/templates/Multiflex-5/

The default template comes with two blocks named “News” and “Sidebar”. If you want an additional block or want to change the name of the existing blocks, “info.php” is the place to do it.
Once you have added a new block to “info.php”, it will be reflected in your (websitebaker) admin screen (Manage sections of a page) as shown below.

Note that “MyBlock” was added to info and it shows up in the drop down box in the Manage Sections page.

To add content to a block:
  1. Add a section to your page and place it under one of the block names in the drop down box.
  2. Modify “index.php” under <installation dir>/templates/Multiflex-5/, to pull the content into that block. The picture below shows a sample of how the “index.php” was modified to show the blocks.
Add Block - index.php
Additionally you can use different classes with your headings to display cool icons as shown below.
NOTE: When you modify the template "index.php" to display the content of the blocks, this will be done on all pages. If you do not add sections to other pages to provide content, empty blocks will be displayed.


[1] WebsiteBaker-Designer Guide

[2] Multiflex-5.0

Friday, April 16, 2010

Web Services: A HOWTO on SOAP headers using JAX-RPC and JAX-WS

This article tries to address the following questions
  • How to define SOAP headers in a WSDL?
  • How to deal with SOAP headers when following the top-down and bottom-up development approaches?
  • How to make the SOAP headers available to the implementation when the headers are defined using explicit or implicit styles using a top-down or a bottom-up approach?
Development Environment: WebSphere Integration Developer (WID) 6.2

Defining SOAP headers in WSDL (Implicit and Explicit Styles):

“An implicit SOAP header is a SOAP header that fits one of the following descriptions:
  1. A message part that is declared as a SOAP header in the binding in the Web Services Description Language (WSDL) file, but the message definition is not referenced by a portType element within a WSDL file.
  2. An element that is not contained in the WSDL file.” – [4]

The author of the wonderful article named “Implement implicit and explicit SOAP headers” has described both styles in great detail.

Two cases when using SOAP headers:
  1. The data in the SOAP header is either used or populated in the implementation of the operation.
  2. The data in the SOAP header is neither used nor populated in the implementation of the operation.
In particular, the rest of this article focuses on case 1 with both Implicit and Explicit styles.

Development Approach (Top-Down and Bottom-Up):

In a Top-Down development approach of a web service, the WSDL is first defined from which the java artifacts that are necessary to implement the service are generated.

For a top-down approach, you could use

  1. WSDL2Java command in case of JAX-RPC
  2. wsimport command in case of JAX-WS

In a Bottom-Up approach of a web service, the WSDL is generated from the java artifacts that are associated with the implementation of a particular service.

For a bottom-up approach, you could use
  1. Java2WSDL command in case of JAX-RPC
  2. wsgen command in case of JAX-WS

Combining the two options of the development approach with the two options of SOAP header definition styles, we end up with 4 combinations.
  1. Top-Down – Explicit
  2. Top-Down – Implicit
  3. Bottom-Up – Explicit
  4. Bottom-Up – Implicit


Top-Down – Explicit

If you have defined your SOAP header using the explicit style in the WSDL, JAX-RPC maps the explicit headers to the Service Endpoint Interface (SEI) of the web service. Both request and response headers if any will be available for the implementation code.

With an explicit header definition style, after the java artifacts are generated, the SEI looks like the following for one operation named “returnInput” that has both request and response headers defined

public interface TestTopDownHeaders extends java.rmi.Remote {
              public void returnInput(com.test.TestInput parameters, com.test.BaseRequest_Type    
                                            request_header, com.test.holders.TestOutputHolder parameters2, 
                                            com.test.holders.BaseResponse_TypeHolder response_header) throws  

Note that the headers are passed in as parameters.

Top-Down – Implicit

JAX-RPC does not provide any mapping for the implicit header definitions.

One could use JAX-RPC handlers to access the headers for cases where the implementation of the service does not deal with the header information.

For cases where the SOAP header is either used or populated in the implementation of the operation, you could use one of the two options
  1. Use the ServiceLifecycle interface as described in [2] in the references section.
  2. Use JAX-RPC handler and use ThreadLocal class to store/retrieve the header information. On the Server side, when the request comes in, the handler basically populates the values in the request header that the implementation needs on the thread-local variable. The information stored is available to the operation implementation. For the response headers, the operation implementation can pass the information along to the handler in a similar fashion. This is not an elegant approach but sure works!

Bottom-Up – Explicit

For the Bottom-Up – Explicit header approach, a lot of manual changes need to be made. This is particularly for cases where the operation implementation needs to have access to SOAP headers.

Here is what I have done.
  1. Create holder classes
  2. Modify the SEI to pass headers as parameters mimicking the generated classes in the top-down approach.
  3. Generate the WSDL
  4. Modify the WSDL
  5. Modify the mapping xml

Seems to work fine, but I would not recommend this approach since there is a lot of manual work involved.

Bottom-Up – Implicit

Some amount of manual changes to the WSDL is required (adding the SOAP header to the bindings sections). Also, in-order to generate the mappings for the header objects, they will have to be added to the interface and then removed at a later point, not to mention the changes to the mappings xml file.

One of the two approaches described in Top-Down – Implicit can be used to make the SOAP header information available to the implementation of the operation.

JAX-WS (2.1)

Using annotations in JAX-WS, you can mark a parameter as a header.


@WebParam(name = "RequestHeader", targetNamespace = "", header = true, partName = "request_header")

If you are looking for JAX-WS annotations reference, please use [5] in the references section.

Top-Down – Explicit

JAX-WS supports explicit headers and provides the header objects as parameters to the operation. It generates the annotations, marking the SOAP header parameters as headers.

Top-Down – Implicit

JAX-WS has no support for implicit headers but after generating the java artifacts. For cases where the implementation deals with the headers
  1. Simply add header parameters with annotations to the interface/implementation classes and the mapping is taken care of. Don’t forget to use the Holder class for OUT and IN/OUT parameters.
  2. The other approach would be to use JAX-WS handlers and MessageContext object to make the headers accessible to the implementation. Please refer [3] to see how you can work with JAX-WS handlers to do the same.

Bottom-Up – Explicit

JAX-WS supports explicit headers even in the bottom-up approach. Add the annotations marking the header parameters as headers.


@WebService(name = "TestBottomupHeaders", targetNamespace = "")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public interface TestBottomupHeadersIntf extends java.rmi.Remote{
            @WebMethod(action = "returnInput")
            public void returnInput(
                @WebParam(name = "TestInput", targetNamespace = 
                            "", partName = "input") TestInput input,
                @WebParam(name = "BaseRequest", targetNamespace = "",  
                           header = true, partName = "request_header") BaseRequest_Type requestHeader,
                @WebParam(name = "TestOutput", targetNamespace = "", mode 
                      = WebParam.Mode.OUT, partName = "output") Holder<TestOutput> output,
                @WebParam(name = "BaseResponse", targetNamespace = "", 
                     header = true, mode = WebParam.Mode.OUT, partName = "response_header")
                     Holder<BaseResponse_Type> responseHeader);

NOTE: For OUT and IN/OUT parameters, you must use the Holder class as shown above.

Bottom-Up – Implicit

Two approaches here:

  • Define the POJO interface passing the headers as parameters and with annotations marking header=”true” where appropriate
  • Generate the WSDL
  • Change the WSDL manually to have implicit headers definitions rather than explicit.
2.   Use JAX-WS handlers to make the headers available to the implementation. Please refer [3] to see how you can work with JAX-WS handlers and MessageContext to do the same.


[1]        Implement implicit and explicit SOAP headers

[2]        Web services programming tips and tricks: Using SOAP headers with JAX-RPC

[3]        Get a handle on the JAX-WS API's handler framework

[4]        IBM WebSphere Application V 7.0 Information Center

[5]        JAX-WS annotations reference

Wednesday, April 14, 2010

Must-Have bookmarks for IBM WebSphere Integration Developers

Reference Material Links for IBM WebSphere Integration Developers.

  1.  IBM Education assistant
  2. IBM WebSphere Business Process Management V7.0 Information Center
  3. IBM WebSphere Application Server V7.0 Information Center
  4. IBM WebSphere Business Process Management Samples and Tutorials
  5. IBM WebSphere Forums
  6. IBM WebSphere Technical Library
  7. IBM WebSphere Redbooks
  8. IBM WebSphere Training & Certification
  9. Working with BPC – IBM developerWoks Reference Material
  10. WebSphere Integration Developer - Information Roadmap
  11. IBM WebSphere Application Server, Release 6 API Specification which includes
    • Human Task APIs (
    • Business Process Engine (BPE) APIs (
    • Service Data Object APIs (
    • Services Interfaces APIs (
    • Services Addressing APIs (
   12. Service Message Object (SMO) APIs (Release 6)