Axis2 -> Top-down approach -> MessageReceiverInOut class and CallBackHandler classes ?

[kri shan]

If we follow top-down approach(creating binding classes from WSDL/XSD) using Axis2 framwork gives Stub class, Skeleton class, MessageReceiverInOut class and CallBackHandler class. WebService Client(consumer) will connnect to server(WebService provider) uisng stub and skeleton classes. I don't unsderstand why we neeed MessageReceiverInOut class and CallBackHandler classes ?

[Kamal Wickramanayake]

Stub class is only to be used by the client. Skeleton is only to be used to develop the service. MessageReceiverInOut is used to act as a bridge between the Axis2 engine and the service skeleton instance. In terms of Axis2 message processing details, Axis2 core engine assumes that a message is processed to conclusion when a message receiver is invoked. MessageReceiverInOut is one such message receiver that can receive a message as well as generate a response. You don't have to worry too much about it.

A call back handler is used if you develop asynchronous clients/services. It's used at the client side. With asynchronous mode, client sends the request and continues doing work. When the server sends a response, the call back is used by the client to handle it. In this mode you can even use two TCP connections. Mostly you write synchronous clients/services.

Look at the wsdl2java command line parameters. You can separately generate the skeleton code in one directory, finish and deploy the service. Then you can use the same command to generate the client only code (say only with synchronous mode stub code) and get the client completed.