 
 |
|
|
 Generate Revenue Through IT Using Business Service Management
Sponsored by HP
Making sure that your business applications are available to their end users is an important part of running your business smoothly. Business operations have evolved to where IT must now broaden its focus to help the company attract, retain and grow customer relationships and increase customer satisfaction. Business service management (BSM) helps lay the foundation by managing services in dynamic support of business requirements. »
|
|
Managing the Modern Network
Sponsored by HP
Networks are more than vehicles to transport e-mail and Web pages. In a global economy where information crosses the globe in an instant, and where Web-based applications power business, it's more important than ever to ensure your network is safe from threats and optimized to deliver the data your business needs. »
|
|
Storage Networking 2, Configuration and Planning
Sponsored by HP
In Part 1, we discussed storage area networks (SANs) and fibre channel. In Part 2, delve into best practices and cover the general concepts you must know before configuring SAN-attached storage. The most critical, sometimes tedious, part of setting up a SAN is configuring each individual disk array. This guide examines configurations for SAN-attached servers and disk arrays, and also includes a look at the future of IP storage.
»
|
|
Is Your Disaster Recovery Plan Good Enough? Get Disaster Recovery Right
Sponsored by HP
Preparing for a disaster is more often than not part of the storage planning process, and without question it is one of the most difficult task, since it includes local hardware and software, networking equipment, and a test plan to ensure that you can recover from the disaster. Learn how to put your organization on the proper disaster recovery plan, now. »
|
 |
 |
  |
|
|
|
|
|
|
Axis2 Execution Framework
By Deepal Jayasinghe
Go to page: 1 2 3 4 Next
Web services have become highly demanding and a large number of players have entered the Web service arena. Axis2 is the latest solution by Apache solutions to the Web service stack, which addresses some of the drawbacks of the Axis 1.x family and introduces some new concepts into the Web service stack. Axis2 is a highly flexible, easily configurable, highly reliable SOAP processing engine. One of the main advantages gained from Axis2 is the dynamic handler chain; although the notion of handler chain remains as in Axis 1.x, the underlying architecture is quite different.
Introduction
Axis2 is shaped by the experience from the Axis 1.x family and the advancements in the Web service stack during the last few years. Axis2 developers take conscious effort to make sure that Axis2 performs better in terms of speed and memory despite the fact that new features and functionalities are added. Among all those features and functionalities, the dynamic nature of the handler chain (Execution chain) is considerably important. The article published by Web service experts in Indiana University (Beytullah Yiliz, Shrideep Pallickara, and Geoffery Fox) on the topic of "Deployment Problems in Axis and Suggestions" has suggested that the requirement of dynamically configurable handler chain in Axis is as follows:
"In Axis, handlers are currently statically configured—the configuration being made when a service is being deployed. A handler cannot be added or removed from a service. Currently, Axis architecture allows cloning the handler chain. The cloned chain can replace a current one after required changes are applied. But this is not sufficient. Dynamic configuration of handler chains will be very useful. A deployment may have lots of handlers, but a user/handler should be able to select a group of handlers that a message would need to go through."
In Axis2, the handler chain is easily configurable and has the ability of changing dynamically, the capability achieved through so-called phases, phase rules, and module engagement.
Handlers
If you have ever used any version of Axis, you should be familiar with the term "Handler," the Apache terminology given for the "message interceptors" in any messaging system. Interceptor has its factual meaning in the context of messaging too, which intercepts the messaging flow and does whatever task it is assigned to do. In fact, an interceptor is the smallest execution unit in a messaging system so that, as the interceptor in Axis, handler does the same thing.
Handlers in Axis are stateless, meaning they keep their pass execution states in memory. A handler can be considered as a logic invoker with the input for the logic evaluation taken only from the MessageContext (MC). Handler has both read and writes access to MC.
Note: MessageContext can be seen as a property bag that keeps incoming or outgoing messages and other (maybe both) required parameters and properties to carry the message through the execution chain. On the other hand, via the MC one can access the whole system, such as global parameters, properties, and so forth.
Most of the time ( 99% of the time) handlers only touch the header block part of the SOAP message, which will either read a header (or headers), add a header(s) or remove a header(s). In the reading, if a header is targeted to a handler and if it cannot execute properly (message might be faulty) then it should throw an exception, and next chain driver (in Axis2 it is engine) would take necessary action depending on the flow, and phase.
Any handler in a chain has the capability to pause the message execution, meaning that the handler can stop the message flow if it cannot continue. Reliable messaging (RM) is a good example or the use case for that scenario that needs to pause the flow depending on some pre- and post conditions. In the case of RM, it works on the message sequence. If a service invocation consists of more than one message, and if the second one comes before the first, the RM handler will stop (rather pause) the execution of message invocation corresponding to the second message until it gets the first message. And, when it gets the first message, it will invoke that, and then, after, that will invoke the second message.
Writing a simple handler
Writing a handler in Axis is very simple. The only compulsory factor is that it has to extend from AbstractHandler. A simple handler is as follows:
public class SimpleHandler extends AbstractHandler {
private String message;
private QName name;
public SimpleHandler() {
this.message = "I am Simple Handler ";
}
public QName getName() {
return name;
}
public void invoke(MessageContext msgContext) throws AxisFault {
// write invocation logic here
}
public void setName(QName name) {
this.name = name;
}
}
Among all the methods in the above implementation, invoke(msgContext) is the most important to discuss. When a message is received to the Axis engine, it will call invoke methods of each handler by passing an argument as a corresponding message context, so that inside the invoke method all the processing logic should be implemented. Inside the invoke method handler, the author has full access to the SOAP message and all the required properties to process the message via the message context. In addition to that, if handler finds some pre-condition and is not satisfied with the invocation, the invocation can be paused as mentioned earlier. It should be noted that the Axis2 engine provides a facility to store and retrieve message context, so a handler can use those features to store and retrieve message context.
Go to page: 1 2 3 4 Next
|
Generate Revenue Through IT Using Business Service Management
Managing the Modern Network
Storage Networking 2, Configuration and Planning
Is Your Disaster Recovery Plan Good Enough? Get Disaster Recovery Right 
IE 7
Firefox 2.0
