Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • Use the JAX-RPC Handler API to create a SOAP message handler, describe the function of a handler chain, and describe the role of SAAJ when creating a message handler.

    JAX-RPC handlers allow you to intercept a SOAP message at various times during a service invocation. Handlers are similar to servlet filters. Handlers can exist on both the client and the server side. If you use JAX-RPC on the client side, you can have a handler process a SOAP request message right before it goes on the network, and you can process the response message before it is returned to the client. Similarly, you can intercept an incoming SOAP request message on the server before invoking the service implementation, as well as the outgoing response.

    Several handlers can be combined into what is called a "handler chain". Each handler processes the SOAP message, which is then passed on to the next handler in the chain. The exact sequence in which this happens is configurable.

    To develop a JAX-RPC handler, you simply create a class that implements the javax.xml.rpc.handler.Handler interface. It has three methods to handle SOAP requests, responses and faults, respectively.

    Handlers are defined in the JAX-RPC specification. However, the "Enterprise Web Services" (JSR109) specification describes how they are used in a J2EE environment and adds some clarification to the way handlers are managed by the application server. We will assume that your Web service runs on a J2EE application server and hence we will follow the definitions of JSR109 as well as JAX-RPC.

    Handlers are shared across multiple service invocations. In other words, they can store information that is only valid for a particular client or server instance. You can compare this to the way servlets are handled. When a new instance of a handler is created, its init(...) method is called. That allows you to set up things that you can use for multiple invocations. Before the handler is removed, the destroy() method is called, so that you can do cleanup in there. As a rule of thumb, however, you should avoid storing any state in a handler altogether.

    Handlers can be configured either programmatically or, in case you are running a J2EE application server, they are configured in the Web service deployment descriptor. Handlers and handler chains are defined on a per service basis. They can be defined in both the server and client side deployment descriptors. Listing below shows the deployment descriptor for our sample service, showing how a handler class called handler.PerformanceHandler is registered for the HelloWorldService service (webservices.xml):

    
    <webservices>
       <webservice-description>
          <webservice-description-name>HelloWorldService</webservice-description-name>
          <wsdl-file>WEB-INF/wsdl/HelloWorld.wsdl</wsdl-file>
          <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
          <port-component>
             <port-component-name>HelloWorld</port-component-name>
             <wsdl-port>
                <namespaceURI>http://pack</namespaceURI>
                <localpart>HelloWorld</localpart>
             </wsdl-port>
             <service-endpoint-interface>pack.HelloWorld</service-endpoint-interface>
             <service-impl-bean>
                <servlet-link>pack_HelloWorld</servlet-link>
             </service-impl-bean>
             <handler>
                <handler-name>handler.PerformanceHandler</handler-name>
                <handler-class>handler.PerformanceHandler</handler-class>
             </handler>
          </port-component>
       </webservice-description>
    </webservices>
    					
    					
    Multiple handlers would be defined here to form a chain as mentioned above.

    If multiple handlers that are involved in one service invocation need to share information, they can do so by adding properties to the message context as it is passed from handler to handler. This message context will be available from the request to the response. In other words, we can use it to store information on an incoming request that we can reuse when the response comes back.

    Now let's look at how you can create a handler that measures the response time of your service implementation. We will assume that you have created a HelloWorld web service, which simply returns a String message. Listing below shows the code for the service implementation bean:

    public class HelloWorld {
    	public String helloWorld(String message) {
    		return "Hello " + message;
    	}
    }					
    					
    The handler will be configured for the server that hosts the Web service. It will be invoked on both the request and the response message, so that we can measure the elapsed time.

    Each handler must implement the javax.xml.rpc.handler.Handler interface. Or, you can make your life a bit easier by simply inheriting the javax.xml.rpc.handler.GenericHandler class, which provides default implementations for all the methods. For storing performance results, we use a class called Logger, which we set up in the init() method. Moreover, the application server passes a javax.xml.rpc.handler.HandlerInfo object into this method, which we need to cache as well:

    public class PerformanceHandler extends GenericHandler {
    
    	protected HandlerInfo info = null;
    	protected Logger logger = null;
    
    	public void init(HandlerInfo arg) {
    		info = arg;
    		logger = Logger.getLogger("c://temp//HelloWorldServiceLog");
    	}
    	
    	public void destroy() {
    		try {
    			logger.close();
    		} catch (Exception x) {}	
    	}							
    			
    	...
    }					
    					
    Note that we close the Logger object when the handler instance is destroyed.

    Each handler implements the handleRequest method, which is invoked when a request message arrives:

    public boolean handleRequest(MessageContext context) {
    	try {
    		Date startTime = new Date();
    		context.setProperty("startTime", startTime);
    	} catch (Exception x) {
    		x.printStackTrace();
    	}
    	return true;
    }					
    					
    Here you can see that we store the current time in the message context as a property called "startTime". The application server will guarantee that the same message context object is passed into the handleResponse method, so that we can measure the elapsed time there:
    public boolean handleResponse(MessageContext context) {
    	try {
    		Date startTime = (Date)context.getProperty("startTime");
    		Date endTime = new Date();
    		long elapsedTime = endTime.getTime() - startTime.getTime();
    		logger.write("Elapsed time is " + elapsedTime+"\n");
    	} catch (Exception x) {
    		x.printStackTrace();
    	}
    	return true;
    }
    					

    JAX-RPC defines a mechanism with which you can manage service invocations by intercepting request and response messages without having to change the actual service consumer or provider. In J2EE, you can configure handlers in a deployment descriptor, without writing any code, providing you with a powerful way of controlling SOAP messages as they pass through your system.

    Handlers let you access/modify SOAP request and response messages, but typically used to process service contexts in SOAP header blocks.

    Possible example handlers: encryption, decryption, authentication, authorization, logging, auditing, caching.

    Handlers are pluggable and chainable through standardized programming API, portable across implementations. Handler has its own lifecycle: JAX-RPC runtime system calls init(...), destroy() of a handler. Handler instances can be pooled (stateless). MessageContext is used to share properties among handlers in a handler chain.

    On the service client side: a request handler is invoked before an RPC request is communicated to the target service endpoint, a response or fault handler is invoked before an RPC response is returned to the client.

    On a service endpoint: a request handler is invoked before an RPC request is dispatched to the target service endpoint, a response or fault handler is invoked before communication back to the service client from the target service endpoint.

    javax.xml.rpc.handler.Handler interface is required to be implemented by a SOAP message handler:

    package javax.xml.rpc.handler;
    
    import javax.xml.namespace.QName;
    
    public interface Handler {
    
        public boolean handleRequest(MessageContext context); // 'false' will block the HandlerChain
        public boolean handleResponse(MessageContext context); // 'false' will block the HandlerChain
        public boolean handleFault(MessageContext context); // 'false' will block the HandlerChain
        public abstract void init(HandlerInfo config);
        public abstract void destroy();
        public QName[] getHeaders();
        
    }
    					
    or extend GenericHandler abstract class:
    package javax.xml.rpc.handler;
    
    import javax.xml.namespace.QName;
    
    public abstract class GenericHandler implements Handler {
    
        protected GenericHandler() {}
    
        public boolean handleRequest(MessageContext context) {
            return true;
        }
    
        public boolean handleResponse(MessageContext context) {
            return true;
        }
    
        public boolean handleFault(MessageContext context) {
            return true;
        }
    
        public void init(HandlerInfo config) {}
        public void destroy() {}
        public abstract QName[] getHeaders();
    }
    					

    Example of generic SOAP message handler:

    package com.example;
    
    public class SampleSOAPHeaderHandler implements javax.xml.rpc.handler.Handler {
    	
    	public SampleSOAPHeaderHandler() { ... }
    	
    	public boolean handleRequest(MessageContext context) {
    		try {
    			SOAPMessageContext smc = (SOAPMessageContext)context;
    			SOAPMessage msg = smc.getMessage();
    			SOAPPart sp = msg.getSOAPPart();
    			SOAPEnvelope se = sp.getEnvelope();
    			SOAPHeader sh = se.getHeader();
    			
    			// Process one or more header blocks
    			// ...		
    			// Next step based on the processing model for this handler
    			
    		} catch(Exception ex) {
    			// throw exception
    		}
    	}
    	
    	...
    }					
    					
    					

    Sample handler which extends GenericHandler:

    package com.example;
    
    public class SampleSOAPHeaderHandler extends GenericHandler {
    	
    	public boolean handleRequest(MessageContext ctx) {
    		try {
    			SOAPMessageContext mc = (SOAPMessageContext)ctx;
    			SOAPMessage msg = mc.getMessage();
    			SOAPPart sp = msg.getSOAPPart();
    			SOAPEnvelop se = sp.getEnvelope();
    			SOAPHeader header= se.getHeader();
    			
    			// now we can process the header
    
    			if (everything is fine) {
    				return true; // with 'true' handler chain continues processing
    			} else {				
    				return false; // return 'false' results in chaining to stop
    			}
    		} catch(Exception ex) {}
    	}
    }
    					

    Configurable on both client and endpoint side:

    • Server side in webservices.xml file.

    • Client side in webservicesclient.xml or web.xml or ejb-jar.xml file (inside the service-ref tag).

    webservices.xml (server-side config):

    
    <webservices>
        <webservice-description>
            ...
            <port-component>
                <port-component-name>GetQuote</port-component-name>
    
                <wsdl-port>
                    <namespaceURI>http://example.org</namespaceURI>
                    <localpart>GetQuote</localpart>
                </wsdl-port>
                ...
                <handler>
                    <handler-name>server1</handler-name>
                    <handler-class>service.ServerHandler1</handler-class>
                    <init-param>
                        <param-name>name</param-name>
                        <param-value>My Handler Name</param-value>
                    </init-param>
                    <soap-header>
                        <namespaceURI>http://sample</namespaceURI>
                        <localpart>QuoteHeader</localpart>
                    </soap-header>
                    <soap-role>MyServerHandler</soap-role>                
                </handler>
       
                <handler>
                    <handler-name>server2</handler-name>
                    <handler-class>service.ServerHandler2</handler-class>
                </handler>
                ...
            </port-component>
        </webservice-description>
    </webservices>
    					
    					
    Observe that there are 2 handlers defined to run in the order (for incoming message): server1 -> server2. Also observe that the server-side Handler Chain is associated with a particular 'Port' of a Web Service by port-component tag.

    Server-side handler:

    package service;
    
    import javax.xml.namespace.QName;
    import javax.xml.rpc.handler.soap.SOAPMessageContext;
    import javax.xml.rpc.JAXRPCException;
    import javax.xml.rpc.handler.*;
    import javax.xml.soap.*;
    
    /**
    * This class implements a handler by extending the abstract
    * class javax.xml.rpc.handler.GenericHandler.
    */
    public class ServerHandler1 extends GenericHandler {
    	private HandlerInfo handlerInfo;
    	private String name;
    
    	public void init(HandlerInfo info) {
    		handlerInfo = info;
    		// this parameter was configured in 'webservices.xml'
    		name = (String) info.getHandlerConfig().get("name");
    		System.out.println("ServerHandler1: name = " + name);
    	}
    
    	/*
    	* This method is declared abstract in GenericHandler and must
    	* be defined here. 
    	*/
    	public QName[] getHeaders() {
    		return handlerInfo.getHeaders();
    	}
    
    	/*
    	* This handler will check incoming messages for the header
    	* specified in 'webservices.xml'. It doesn't do anything with the
    	* information besides output it, but it could be used to determine
    	* what type of processing should be performed on this message
    	* before passing on to the ultimate recipient.
    	*/
    	public boolean handleRequest(MessageContext context) {
    		// ...
    	}
    }					
    					

    webservicesclient.xml or web.xml or ejb-jar.xml (client-side config):

    
    <webservicesclient>
        <service-ref>
            <description>WSDL Service StockQuoteService</description>
            <service-ref-name>service/StockQuoteService</service-ref-name>
            <service-interface>sample.StockQuoteService</service-interface>
            <wsdl-file>WEB-INF/wsdl/Sample.wsdl</wsdl-file>
            <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
            <service-qname>
                <namespaceURI>http://sample</namespaceURI>
                <localpart>StockQuoteService</localpart>
            </service-qname>        
            <port-component-ref>
                <service-endpoint-interface>sample.GetQuotePortType</service-endpoint-interface>
            </port-component-ref>
            <handler>
                <handler-name>client1</handler-name>
                <handler-class>client.ClientHandler1</handler-class>
                <init-param>
                    <param-name>name</param-name>
                    <param-value>My Client Handler</param-value>
                </init-param>
                <soap-header>
                    <namespaceURI>http://sample</namespaceURI>
                    <localpart>GetQuote</localpart>
                </soap-header>
                <soap-role>LoggingHandler</soap-role>
                <port-name>GetQuote</port-name>
            </handler>
        </service-ref>
    </webservicesclient>
    					
    					
    NOTE: Unlike the server-side handlers, client-side handlers are associated with service-ref (service references) instead of port-component (port component references). However, they have a configurable parameter, port-name, by which handlers can be associated with the port of the service which is invoked. With port names, you can restrict which handlers to run when a service endpoint (WSDL port) is invoked. In the above case, the handler 'client1' is only run if 'GetQuote' is invoked.

    Client-side handler:

    package client;
    
    import javax.xml.namespace.QName;
    import javax.xml.rpc.handler.soap.SOAPMessageContext;
    import javax.xml.rpc.JAXRPCException;
    import javax.xml.rpc.handler.*;
    import javax.xml.soap.*;
    
    /**
    * This class implements a handler by extending the abstract
    * class javax.xml.rpc.handler.GenericHandler.
    */
    public class ClientHandler1 extends GenericHandler {
    	HandlerInfo handlerInfo;
    	String name;
    
    	public void init(HandlerInfo info) {
    		handlerInfo = info;
    		// this parameter was configured in deployment descriptor
    		name = (String) info.getHandlerConfig().get("name");
    		System.out.println("ClientHandler1: name = " + name);
    	}
    
    	/*
    	* This method is declared abstract in GenericHandler and must
    	* be defined here. Another way to implement is to keep an array
    	* of QNames and set them in the init() method to info.getHeaders().
    	*/
    	public QName[] getHeaders() {
    		return handlerInfo.getHeaders();
    	}
    
    	public boolean handleRequest(MessageContext context) {
    		try {
    			// get the soap header
    			SOAPMessageContext smc = (SOAPMessageContext) context;
    			SOAPMessage message = smc.getMessage();
    			SOAPPart soapPart = message.getSOAPPart();
    			SOAPEnvelope envelope = soapPart.getEnvelope();
    			SOAPHeader header = message.getSOAPHeader();
    			if (header == null) {
    				header = envelope.addHeader();
    			}
    			
    			// Add logger element with mustUnderstand="1".
    			// Will use the default actor "next" for this example, otherwise
    			// Use loggerElement.setActor(String actorURI) to define actor.
    			// The element will contain a ficticuous log level for
    			// this example.
    			System.out.println("ClientHandler1: adding loggerElement");			
    			SOAPHeaderElement loggerElement = header.addHeaderElement(
    				envelope.createName("loginfo", "ns1", "http://example.com/"));
    			loggerElement.setMustUnderstand(true);
    			loggerElement.setValue("10");
    			
    			// Add simple element describing the client making the request.
    			System.out.println("ClientHandler1: adding nameElement");
    			SOAPHeaderElement nameElement = header.addHeaderElement(
    				envelope.createName("clientname", "ns1", "http://example.com/"));
    			nameElement.addTextNode("Duke");
    
    		} catch (Exception e) {
    			throw new JAXRPCException(e);
    		}
    		
    		// return true to continue message processing
    		return true;
    	}
    }					
    					
    this handler will add following headers to processed SOAP message:
    
    <?xml version="1.0"?>
    
    <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
        <soap:Header>
        
            <ns1:loginfo xmlns:ns1="http://example.com/" 
                soap:mustUnderstand="1"
                soap:actor="http://schemas.xmlsoap.org/soap/actor/next">
                10
            <n/s1:loginfo>
            
            <ns1:clientname xmlns:ns1="http://example.com/"
                soap:actor="http://schemas.xmlsoap.org/soap/actor/next">
                Duke
            </ns1:clientname>        
            
        </soap:Header>
        <soap:Body>
            ...
        </soap:Body>
    </soap:Envelope>
    					
    					

    A handler chain represents an ordered list of handlers. This grouping helps you define policies that you want associated with the handler invocation model. Examples of such policies include order of invocation, style of invocation (for example, a one-way call invokes only handleRequest(); no handleResponse()), etc. Another possible policy you can set on the handler chain: A handler chain can invoke a handler based on the qname of the outermost element of a SOAP header. This association can be configured to the handler through the Handler.init(...) method passing a HandlerInfo object. The handler chain continues processing the handlers only if the current processing handler returns true. You can associate a handler chain with SOAP actors (or roles) by specifying the URIs of the actors. By default, a handler chain is always associated with the special SOAP actor "http://schemas.xmlsoap.org/soap/actor/next". A server-side handler chain is registered on a per service endpoint basis, as indicated by the qualified name of the WSDL port.

    package javax.xml.rpc.handler;
    
    import java.util.List;
    import java.util.Map;
    
    public interface HandlerChain extends List {
    
        public boolean handleRequest(MessageContext context);
        public boolean handleResponse(MessageContext context);
        public boolean handleFault(MessageContext context);
    
        public void init(Map config);
    
        public void destroy();
    
        public void setRoles(String[] soapActorNames);
    
        public java.lang.String[] getRoles();
    }
    					

    In the following example, three Handler instances Handler_1, Handler_2 and Handler_3 are registered (in this order) in a single HandlerChain instance that is used for both request and response processing. The default invocation order for these handlers is as follows:

    1. Handler_1.handleRequest

    2. Handler_2.handleRequest

    3. Handler_3.handleRequest

    4. Handler_3.handleResponse

    5. Handler_2.handleResponse

    6. Handler_1.handleResponse

    Handlers Concepts

    A Handler can be likened to a Servlet Filter in that it is business logic that can examine and potentially modify a request before it is processed by a Web Service component. It can also examine and potentially modify the response after the component has processed the request. Handlers can also run on the client before the request is sent to the remote host and after the client receives a response.

    JAX-RPC Handlers are specific to SOAP requests only and cannot be used for other non-SOAP Web services. Handlers may be transport independent. For instance, a Handler as defined by JAX-RPC may be usable for SOAP/JMS in addition to SOAP/HTTP if a JMS protocol binding was available. Handlers for non-SOAP encodings have not been defined yet.

    Handlers are service specific and therefore associated with a particular Port component or port of a Service interface. This association is defined in the deployment descriptors. They are processed in an ordered fashion called a Handler Chain, which is defined by the deployment descriptors.

    There are several scenarios for which Handlers may be considered. These include application specific SOAP header processing, logging, and caching. A limited form of encryption is also possible. For application specific SOAP header processing, it is important to note that the client and server must agree on the header processing semantics without the aid of a WSDL description that declares the semantic requirements. Encryption is limited to a literal binding in which the SOAP message part maps to a SOAPElement. In this case, a value within the SOAPElement may be encrypted as long as the encryption of that value does not change the structure of the SOAPElement.

    Some Handler scenarios described within the JAX-RPC specification are not supported by this specification. For example, auditing cannot be fully supported because there is no means for a Handler to obtain the Principal. The secure stock quote example cannot be supported as stated because encrypting the body would prevent the container from determining which Port component the request should be directed to and therefore which Handler should decrypt the body.

    A Handler always runs under the execution context of the application logic. On the client side, the Stub/proxy controls Handler execution. Client side Handlers run after the Stub/proxy has marshaled the message, but before container services and the transport binding occurs. Server side Handlers run after container services have run including method level authorization, but before demarshalling and dispatching the SOAP message to the endpoint. Handlers can access the java:comp/env context for accessing resources and environment entries defined by the Port component the Handler is associated with.

    Handlers are constrained by the J2EE managed environment. Handlers are not able to re-target a request to a different component. Handlers cannot change the WSDL operation nor can Handlers change the message part types and number of parts. On the server, Handlers can only communicate with the business logic of the component using the MessageContext. On the client, Handlers have no means of communicating with the business logic of the client. There is no standard means for a Handler to access the security identity associated with a request, therefore Handlers cannot portably perform processing based on security identity.

    Handlers are associated with the Port component on the server and therefore run in both the web and EJB containers.

    J2EE applications that define one or more port components or service references include WSDL descriptions for each of them as well as application logic and (optionally) SOAP message handlers associated with them. In order for such applications to behave predictably, all three elements (description, handlers and application logic) must be well aligned. Developers should program handlers carefully in order not to create invalid SOAP envelope format that contradicts WS-I BP 1.0 requirements or violates the message schema declared in the WSDL. In particular, containers cannot provide any guarantees beyond those specified as part of the interoperability requirements on the behavior of an application that violates the assumptions embedded in a WSDL document either in its business logic or in SOAP message handlers.

    Handlers Scenarios

    Scenario 1: Handlers must be able to transform the SOAP header. One example is the addition of a SOAP header for application specific information, like customerId, by the handler.

    Scenario 2: Handlers must be able to transform just parts of the body. This might include changing part values within the SOAP body. Encryption of some parameter values is an example of this scenario.

    Scenario 3: Handlers must be able to just read a message where no additions, transformations, or modification to the message is made. Common scenarios are logging, metering, and accounting.

    Handlers Programming Model

    A Web Services for J2EE provider is required to provide all interfaces and classes of the javax.xml.rpc.handler package. The HandlerInfo setHandlerConfig() and getHandlerConfig() methods do not affect the container's Handler request processing. A Web Services for J2EE provider is not required to provide an implementation of HandlerRegistry. This functionality is specific to the container. A Web Services for J2EE provider is required to provide an implementation of MessageContext. A Web Services for J2EE provider is required to provide all the interfaces of the javax.xml.rpc.handler.soap package. The provider must also provide an implementation of the SOAPMessageContext interface. The programming model of a Port component can be single-threaded or multi-threaded. The concurrency of a JAX-RPC Handler must match the concurrency of the business logic it is associated with. Client handlers may need to support multi-threaded execution depending on the business logic which is accessing the Port. Handlers must be loaded using the same class loader the application code was loaded with. The class loading rules follow the rules defined for the container the Handler is running in.

    The init and destroy methods of the Handler interface allows the container to notify a Handler instance of impending changes in its state. The Handler may use the notification to prepare its internal state for the transition. The container is required to call the init and destroy methods as described. The container must call the init method before it can start dispatching requests to the handleRequest(), handleResponse(), and handleFault() methods of the Handler. The Handler may use the container notification to ready its internal state for receiving requests. The container must notify the Handler of its intent to remove the instance from the container's working set by calling the destroy method. A container must not call the destroy method while a request is being processed by the Handler instance. The container must not dispatch additional requests to the Handler interface methods after the destroy method is called. As defined by JAX-RPC, a RuntimeException (other than SOAPFaultException) thrown from any method of the Handler results in the destroy method being invoked and transition to the "Does Not Exist" state. Pooling of Handler instances is allowed, but is not required. If Handler instances are pooled, they must be pooled by Port component. This is because Handlers may retain non-client specific state across method calls that are specific to the Port component. For instance, a Handler may initialize internal data members with Port component specific environment values. These values may not be consistent when a single Handler type is associated with multiple Port components. Any pooled instance of a Port component's Handler in a "Method Ready" state may be used to service the handleRequest(), handleResponse(), and handleFault() methods. It is not required that the same Handler instance service both the handleRequest() and handleResponse() or handleFault() method invocations of any given request.

    A developer is not required to implement a Handler. Handlers are another means of writing business logic associated with processing a Web services request. A developer may implement zero or more Handlers that are associated with a Port component and/or a Service reference. If a developer implements a Handler, they must follow the requirements outlined in this section. A Handler is implemented as a stateless instance. A Handler does not maintain any message processing (client specific) related state in its instance variables across multiple invocations of the handle_XXX method. A Handler class must implement the javax.xml.rpc.handler.Handler interface:

    package javax.xml.rpc.handler;
    
    public interface Handler {
    	boolean handleRequest(MessageContext context);
    	boolean handleResponse(MessageContext context);
    	boolean handleFault(MessageContext context);
    	// ...
    }					
    					
    A Handler.handle<action>() method may access the component's environment entries by using JNDI lookup of the "java:comp/env" contenxt and accessing the env-entry-name defined in the deployment descriptor by performing a JNDI lookup. The container may throw a java.lang.IllegalStateException if the environment is accessed from any other Handler method and the environment is not available. In addition, the Handler may use java.util.Map HandlerInfo.getHandlerConfig() method to access the Handler's init-params declared in the deployment descriptor. The Handler.init() method must retain the information defined by HandlerInfo.getHeaders(). A Handler implementation must implement the getHeaders() method to return the results of the HandlerInfo.getHeaders() method. The headers that a Handler declares it will process (i.e. those returned by the Handler.getHeaders() method must be defined in the WSDL definition of the service. A Handler implementation should test the type of the MessageContext passed to the Handler in the handle<action>() methods. Although this specification only requires support for SOAP messages and the container will pass a SOAPMessageContext in this case, some providers may provide extensions that allow other message types and MessageContext types to be used. A Handler implementation should be ready to accept and ignore message types which it does not understand. A Handler implementation must use the MessageContext to pass information to other Handler implementations in the same Handler Chain and, in the case of the JAX-RPC service endpoint, to the Service Implementation Bean.
    package javax.xml.rpc.handler;
    
    public interface MessageContext {
    	void setProperty(String name, Object value);
    	Object getProperty(String name);
    	void removeProperty(String name);
    	boolean containsProperty(String name);
    	java.util.Iterator getPropertyNames();
    }					
    					
    A container is not required to use the same thread for invoking each Handler or for invoking the Service Implementation Bean. A Handler may access the env-entry elements of the component it is associated with by using JNDI to lookup an appropriate subcontext of java:comp/env. Access to the java:comp/env contexts must be supported from the init() and handle<action>() methods. Access may not be supported within the destroy() method. A Handler may access transactional resources defined by a component's resource-refs. Resources are accessed under a transaction context. A Handler may access the complete SOAP message and can process both SOAP header blocks and body if the handle<action>() method is passed a SOAPMessageContext:
    package javax.xml.rpc.handler.soap;
    
    public interface SOAPMessageContext extends MessageContext {
    	SOAPMessage getMessage();
    	void setMessage(SOAPMessage message);
    	// ...
    }
    					
    A SOAPMessageContext Handler may add or remove headers from the SOAP message. A SOAPMessageContext Handler may modify the header of a SOAP message if it is not mapped to a parameter or if the modification does not change value type of the parameter if it is mapped to a parameter. A Handler may modify part values of a message if the modification does not change the value type. Handlers that define application specific headers should declare the header schema in the WSDL document for the component they are associated with, but are not required to do so.

    A container is required to provide an instance of a java.util.Map object in the HandlerInfo instance:

    package javax.xml.rpc.handler;
    
    public class HandlerInfo implements java.io.Serializable {
    	public HandlerInfo() { }
    	public HandlerInfo(Class handlerClass, java.util.Map config, QName[] headers) {
    		... 
    	}
    	public void setHandlerClass(Class handlerClass) { ... }
    	public Class getHandlerClass() { ... }
    	public void setHandlerConfig(java.util.Map config) { ... }
    	public java.util.Map getHandlerConfig() { ... }
    	public QName[] getHeaders() { ... }
    	public void setHeaders(QName[] headers) { ... }
    }					
    					
    The HandlerInfo.getHeaders() method must return the set of soap-header elements defined in the deployment descriptor. The Map object must provide access to each of the Handler's init-param name/value pairs declared in the deployment descriptor as java.lang.String values. The container must provide a unique HandlerInfo instance and Map config instance for each Handler instance. A unique Handler instance must be provided for each Port component declared in the deployment descriptor. The container must call the init() method within the context of a Port component's environment. The container must ensure the Port component's env-entrys are setup for the init method to access. The container must provide a MessageContext type unique to the request type. For example, the container must provide a SOAPMessageContext to the handle<action>() methods of a Handler in a handler chain when processing a SOAP request. The SOAPMessageContext must contain the complete SOAP message:
    package com.example;
    public class MySOAPMessageHandler extends javax.xml.rpc.handler.GenericHandler {
    	public MySOAPMessageHandler() { ... }
    
    	public boolean handleRequest(MessageContext context) {
    		try {
    			SOAPMessageContext smc = (SOAPMessageContext)context;
    			SOAPMessage msg = smc.getMessage();
    			SOAPPart sp = msg.getSOAPPart();
    			SOAPEnvelope se = sp.getEnvelope();
    			SOAPHeader sh = se.getHeader();
    			// Process one or more header blocks
    			// ...
    			// Next step based on the processing model for this		
    			// handler
    		} catch(Exception ex) {
    			// throw exception
    		}
    	}
    	
    	// Other methods: handleResponse, handleFault, init, destroy
    	
    }			
    					
    The container must share the same MessageContext instance across all Handler instances and the target endpoint that are invoked during a single request and response or fault processing on a specific node. The container must setup the Port component's execution environment before invoking the handle<action>() methods of a handler chain. Handlers run under the same execution environment as the Port component's business methods. This is required so that handlers have access to the Port component's java:comp/env context.

    The information you are posting should be related to java and ORACLE technology. Not political.