Introduction

Although every step has been taken to lessen the need for users of IBM WebSphere Integration Developer to program in Java, there are times when it's necessary to use Java and POJO components.

A prime example of when you need a POJO component is when you are integrating components that only understand WSDL-described components with components that can only be exposed with Java interfaces. Additionally, data that can't be manipulated within the WebSphere Integration Developer wizards, such as anyType types, can be handled manually within the confines of a POJO component using the Service Data Object (SDO) APIs. These scenarios give meaningful use cases that demonstrate the need for POJO components.

This article provides a base-level of understanding for coding Java in POJO components with respect to invocation styles and expectations of data coming in and out. It is not intended to describe all the scenarios around SCA POJO usage.

This article assumes you are familiar with the basics of SCA, including the concepts of modules and references.

An example: hello world

To illustrate the concepts introduced here, we start by describing a simple Hello World example. Our example is a single SCA module, named HWModule, which contains two POJO components named HelloWorld and MessageLogger. MessageLogger simply prints to the console the message from HelloWorld and returns if it was successful. Figure 1 illustrates the WSDL describing the interface for MessageLogger:

Figure 2 shows the WSDL describing the interface for HelloWorld:

Figure 3 shows the Assembly diagram for the example:

HelloWorld interacts with MessageLogger using two references. One is typed by Java (j-typed) and the other is typed by WSDL (w-typed), as you can see in figure 4.

Figure 5 illustrates the HWMessage Business Object (BO) that is used between HelloWorld and MessageLogger:

Further details of this example will be discussed where appropriate within each section.

Back to top

Client-side Java programming model

This article focuses on two styles of invocation: dynamic invocation interface (DII) and strongly typed. DII is a generic dynamic invocation model that always ends in an 'invoke' type of call passing in the operation name and the input parameters for that operation. Strongly typed invocation does not end in an 'invoke', but ends in a strongly typed invocation.

Strongly typed style invocation

Strongly typed invocations can only be done on a j-typed reference. In our example, we have a reference, named MessageLoggerPartner, defined on HelloWorld that is j-typed, as you can see in Figure 6.

Listing 1 shows the code in HelloWorld’s sayHello() method that invokes the j-typed MessageLoggerPartner reference in a strongly typed way:

// j-type reference strong-typed usage 
MessageLogger service = locateService_MessageLoggerPartner(); 
Boolean	isSuc = service.logMessage(inMsg);

if (isSuc.booleanValue()) { // reuse the inMsg for our response since it's the same type
	inMsg.setString("message", "Success");

} else inMsg.setString("message", "Problem consuming message sent");

inMsg.setString("sourceEmail", "service@hw.org");

	return inMsg;
			

In the above code, you'll see that the method locateService_MessageLoggerPartner() is used to return a proxy to the MessageLogger. This method is generated for each reference defined by a POJO component. In our case we have two references, MessageLoggerPartner and MessageLoggerPartner1, so two methods are generated in HelloWorld, locateService_MessageLoggerPartner() and locateService_MessageLoggerPartner1().

DII (weakly typed) style invocation

Weakly typed invocations can be done irrespective of the type defined for the reference; however, if the reference is w-typed then the client needs to use DII.

J-typed reference with DII

We could have used the MessageLoggerPartner reference in a weakly typed fashion. Listing 2 shows the code in HelloWorld's sayHello() method that invokes the j-typed MessageLoggerPartner reference in a weakly typed way:

// j-type reference DII usage 
Service service = (Service) locateService_MessageLoggerPartner(); 
Boolean	isSuc = (Boolean) service.invoke("logMessage", inMsg);

if (isSuc.booleanValue()) { // reuse the inMsg for our response since it's the same type
	inMsg.setString("message", "Success"); } else
	inMsg.setString("message", "Problem consuming message sent");

inMsg.setString("sourceEmail", "service@hw.org");

return inMsg;
			

Everything is similar to the strongly typed invocation, except the operation name passes into an 'invoke' call along with the input parameter.

W-typed reference with DII

If the reference is w-typed then the only invocation style available to the user is DII. In our example, we have defined another reference in addition to the j-typed reference – MessageLoggerPartner -- that is w-typed named MessageLoggerPartner1, as shown in figure 7.

Listing 3 shows the code in HelloWorld's sayHello() method to use this the w-typed HWMessageLoggerPartner1 reference in a DII way:

// w-type reference DII usage 
Service service = (Service) locateService_MessageLoggerPartner1();

BOFactory bof 
	(BOFactory) new ServiceManager().locateService("com/ibm/websphere/bo/BOFactory");
DataObject inputWrapper = 
	bof.createByType(service.getReference().getOperationType("logMessage").getInputType());

inputWrapper.setDataObject("inMsg", inMsg);

DataObject outputWrapper = (DataObject)	service.invoke("logMessage", inputWrapper); 
boolean	isSuc = outputWrapper.getBoolean("isSuccessful");

if (isSuc) { // reuse the inMsg for our response since it's the same type 
	inMsg.setString("message", "Success");
} else inMsg.setString("message", "Problem consuming message sent");

inMsg.setString("sourceEmail", "service@hw.org");

return inMsg;
			

This scenario is much more interesting, as you can tell from the code snippet in Listing 3. The interesting part is the input types that are sent in/out of the invocation.

In this last scenario we're using DataObjects -- inputWrapper and outputWrapper -- that correspond to the "wrapper" elements in a doc-literal wrapped (DLW) WSDL.

So, to understand what types to send -- strongly or weakly -- you'll need two tidbits of information. First you'll need to know style of WSDL -- DLW or any other -- and then you'll need the reference type, j-type or w-type.

Common problems

Since there can be multiple ways to invoke any given reference one can hit several known problems. The common ones will be presented here.

ClassCastException problems

This common error message indicates that the data being received or sent is not what is expected. For example, if the user does not understand that wrappers are needed for some scenarios then this will be sent on the return object cast. The remedy is to change the code to cast correctly to the right object.

IllegalArgumentException: Class 'x' does not have a feature named 'y' problems

This error message also indicates that the data being received or sent is not what is expected, but instead of happening on the cast it occurs later when data is being accessed. For example, a user receiving a DataObject may think that it is not a wrapper DataObject and try to access the data attributes directly. Accessing it directly will cause an error. The remedy is to change the code to access the correct attributes.

Back to top

Conclusion

This brief article offers a basic overview of selecting strong or weak invocation styles within a POJO component, and the common potential pitfalls of ClassCastException and IllegalArgumentException.

Back to top

Download

Information about download methods

Resources

• Read about the Service Component Architecture (SCA) is a set of specifications Service Component Architecture (SCA) specifications
  
  
• The article "What style of WSDL should I use?" (developerWorks, May 2005) describes the WSDL and SOAP messages for each combination to help you decide which combination of style to use.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• An example: hello world
• Client-side Java programming model
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Java on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers