AOP technology is generally used for the log, authentication, etc. of a function call of an object.
WebService is a remote function call and requires a similar AOP approach, for example Jax-ws's webservice,handler is equivalent to AOP.
Give a case of JAX-WS handler example
Let's write a webservice.
Import Javax.jws.HandlerChain; Import Javax.jws.WebMethod; Import Javax.jws.WebService; @WebService @HandlerChain (file= "Handlers.xml") public class Hello {@WebMethod () public String SayHello (string name) {RET Urn "Hello" + name + ".";}}
The WebService of Super fools, the only special is the @handlerchain callout, where handlers.xml is an XML file that describes the JAX-WS handler chain, which can be placed in the same directory as the source file.
Take a look at the contents of Handlers.xml.
<?xml version= "1.0" encoding= "UTF-8"?>
It defines the handler chain, which has only one handler in the chain, and can also include multiple handler
And then look at the specific implementation of handler:
Import Java.util.Set; Import Javax.xml.namespace.QName; Import Javax.xml.ws.handler.MessageContext; Import Javax.xml.ws.handler.soap.SOAPHandler; Import Javax.xml.ws.handler.soap.SOAPMessageContext; public class Hellohandler implements soaphandler<soapmessagecontext> {@Override public boolean handlemessage ( Soapmessagecontext context) {System.out.println (Context.get (Messagecontext.wsdl_service). toString ()); @Override public boolean Handlefault (Soapmessagecontext context) {//TODO auto-generated method stub return true;} @Over Ride public void Close (Messagecontext context) {//TODO auto-generated ' stub} @Override public set<qname> ge Theaders () {//TODO auto-generated method stub return null;}}
A handler must implement Soaphandler or Logicalhandler interfaces, as for the difference between them, the handler interface, and the meaning of the xxxcontext in <>, please refer to the JAXWS spec, Here are just HelloWorld examples.
All interface-defined methods I actually implemented one, printed the name of the called WebService, and could actually do a lot of things here, such as modifying content in soap, adding or removing XML tags, adding delete soap attachments, getting SOAP-related fields, More image features can be added to decrypt, log, and so on.
Finally, do some related configuration file modification:
Add in Web.xml:
<listener> <listener-class>com.sun.xml.ws.transport.http.servlet.wsservletcontextlistener</ listener-class> </listener> <servlet> <servlet-name>wsservlet</servlet-name> < Servlet-class>com.sun.xml.ws.transport.http.servlet.wsservlet</servlet-class> <load-on-startup>1 </load-on-startup> </servlet> <servlet-mapping> <servlet-name>wsservlet</servlet-name > <url-pattern>/helloservice</url-pattern> </servlet-mapping>
In fact, when a class is labeled with @webservice, the container will automatically turn him into a webservice, but I have tried to use the above method, which is to use the JAXWS runtime to match the request with Wsservlet. And it is specified to load a class as a webservice by Wsservletcontextlistener in the initial context. This listener automatically detects files named Sun-jaxws.xml under Webroot (and web.xml the same directory), which contains representations of webservice specific implementations.
Here the Sun-jaxws.xml content is:
<endpoints xmlns= "Http://java.sun.com/xml/ns/jax-ws/ri/runtime" version= "2.0" > <endpoint name= " HelloService "implementation=" Com.ws.service.Hello "url-pattern="/helloservice "/> </endpoints>
The implementation specified here can be a @webservice class, or it can be a class that implements the provider interface, and provider can view the official spec, which is the basis of jax-rs.
Pack, deploy, I was deployed in GlassFish, find a WebService test tool, the Eclipse JEE Suite has its own WebService client test.