Xfire integrates spring to build webservice and xfirewebservice

Xfire integrates spring to build webservice and xfirewebservice

Xfire and spring are popular technologies, so we will not repeat their respective advantages here. This article focuses on the integration of xfire and spring, so we will not make a thorough exploration.

Server

1.Web. xml configuration
Spring configuration section: contextConfigLocation defines the path of the configuration file. You can specify the Global Path of the configuration file.

<! -- Spring configuration --> <context-param> <param-name> contextConfigLocation </param-name> <param-value>/WEB-INF/xfire-servlet.xml </param-value> </context -param> <listener-class> org. springframework. web. context. contextLoaderListener </listener-class> </listener> <! -- Spring configuration -->

XFire configuration part: xfire configuration 1 use spring's DispatcherServlet class as the xfire processing class, DispatcherServlet configuration file name is [servletname]-servlet by default, located in the WEB-INF directory, you can also use the namespace parameter to specify or use the contextConfigLocation parameter to customize the location of the configuration document. This configuration method can only use the service name. ws to hide other service interfaces. xfire configuration 2 uses the XFireSpringServlet class of xfire as the processing class. This configuration method can be accessed directly through the interface name, you can also access all service interfaces.

<! -- XFire configuration 1 use spring's DispatcherServlet as the xfire processing class. The advantage is that the service name can be customized and all other interfaces provided can be hidden. The client can only use the service name. ws access --> <servlet> <! -- Servlet that works with XFire in the Spring container --> <servlet-name> xfireServlet </servlet-name> <servlet-class> org. springframework. web. servlet. dispatcherServlet </servlet-class> <init-param> <! -- WebApplicationContext namespace, the default value is [servlet-name]-servlet, corresponding to the definition file name of DispatcherServlet, located in/WEB-INF, you can also use the contextConfigLocation parameter to customize the location --> <param-name> namespace </param-name> <param-value> xfire-servlet </param-value> </init- param> <! -- Use the contextConfigLocation parameter to customize the location <init-param> <param-name> contextConfigLocation </param-name> <param-value>/WEB-INF/xfire-servlet.xml </param-value> </init-param> --> </servlet> <servlet-mapping> <servlet-name> xfireServlet </servlet-name> <! -- Open the Web Service under this URI --> <url-pattern> *. ws </url-pattern> </servlet-mapping> <! -- XFire configuration 1 --> <! -- XFire configuration 2 uses xfire's XFireSpringServlet as the xfire processing class. You can directly use the interface class name to access open services, or view all developed service interfaces --> <servlet> <! -- Servlet that works with XFire in the Spring container --> <servlet-name> xfireServlet2 </servlet-name> <servlet-class> org. codehaus. xfire. spring. XFireSpringServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name> xfireServlet2 </servlet-name> <! -- Open the Web Service under this URI --> <url-pattern>/service/* </url-pattern> </servlet-mapping> <! -- XFire configuration 2 -->

2. xfire-servlet Configuration
Xfire must be introduced first. xml configuration; the second part is used to define the service name to be accessed. If XFireSpringServlet is used as the servlet, this configuration is not required, and access through the interface name directly; in the third part, we use XFireExporter to export the Service class as a Web Service. For any export tool, we need to introduce the XFire environment, that is, serviceFactory and xfire. This is a standard configuration. ServiceFactory is the core class of XFire. It can generate a POJO as a Web Service. In this example, we define a baseWebService, and the rest of the webService configurations use this bean as the parent bean. This simplifies Spring configuration and does not need to introduce serviceFactory and xfire multiple times, in this example, the inHandlers parameter is used to define the xfire SOAP interception processing class. You can add multiple parameters to complete security verification and other functions. The last part is used to define the business interface, they all need to use baseWebService as the parent bean.
<? Xml version = "1.0" encoding = "UTF-8"?> <! DOCTYPE beans PUBLIC "-// SPRING // dtd bean // EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <import resource = "classpath: org/codehaus/xfire/spring/xfire. xml "/> <! -- This configuration is not required when the accessed url uses XFireSpringServlet as the servlet --> <bean class = "org. springframework. web. servlet. handler. simpleUrlHandlerMapping "> <property name =" urlMap "> <map> <entry key ="/helloworld. ws "> <ref bean =" HelloWorldService "/> </entry> </map> </property> </bean> <! -- Use the XFire export tool to export the business class as a Web Service through XFireExporter. For any export tool, we need to introduce the XFire environment, that is, serviceFactory and xfire. This is a standard configuration. ServiceFactory is the core class of XFire. It can generate a POJO as a Web Service. In this example, we define a baseWebService and use the bean as the parent bean for other webService configurations. This simplifies Spring configuration and does not need to introduce serviceFactory and xfire multiple times. --> <Bean id = "baseWebService" class = "org. codehaus. xfire. spring. remoting. XFireExporter" lazy-init = "false" abstract = "true"> <! -- Reference the factory defined in xfire. xml --> <property name = "serviceFactory" ref = "xfire. serviceFactory"/> <! -- Reference xfire instance in xfire. xml --> <property name = "xfire" ref = "xfire"/> <! -- Security verification --> <property name = "inHandlers" ref = "AuthenticationHandler"> </property> </bean> <! -- Security Authentication --> <bean id = "AuthenticationHandler" class = "com. authenticationHandler "> </bean> <bean id =" HelloWorldServiceImpl "class =" com. impl. helloWorldServiceImp "/> <bean id =" HelloWorldService "parent =" baseWebService "> <! -- Business service bean --> <property name = "serviceBean" ref = "HelloWorldServiceImpl"/> <! -- Narrow Interface Class of Business Service bean --> <property name = "serviceClass" value = "com. HelloWorldService"/> </bean> </beans>
3. AuthenticationHandler security verification class
Webservice is an open service, but sometimes we need to control user access. Here we use handler to intercept the accessed SOAP message to determine whether it contains verification information, in this way, you can complete a simple security verification. inherit the AbstractHandler class to implement the invoke method, and use MessageContext to obtain whether the request message header contains the authentication information such as the user name and password we need, we need to add this information when calling the client. The client authentication class ClientPasswordHandler is described in the client section below.
Public class AuthenticationHandler extends acthandler {public void invoke (MessageContext cfx) throws Exception {if (cfx. getInMessage (). getHeader () = null) {// whether verification information is available. throw new org. codehaus. xfire. fault. XFireFault ("the request must contain verification information", org. codehaus. xfire. fault. XFireFault. SENDER);} Element token = cfx. getInMessage (). getHeader (). getChild ("AuthenticationToken"); // AuthenticationToken is the custom element value if (token = null) {throw new org. codehaus. xfire. fault. XFireFault ("the request must contain authentication information", org. codehaus. xfire. fault. XFireFault. SENDER);} String username = token. getChild ("Username "). getValue (); String password = token. getChild ("Password "). getValue (); try {// for identity authentication. Only the user test @ test is the authorized user if (username. equals ("test") & password. equals ("test") System. out. println ("authenticated"); else throw new Exception ();} catch (Exception e) {throw new org. codehaus. xfire. fault. XFireFault ("invalid user name and password", org. codehaus. xfire. fault. XFireFault. SENDER );}}}

4. After completing the configuration and interface class development, the work on the server end will be completed. Run this demo in tomcat and enter the corresponding url in the browser when "Invalid SOAP request" appears. "indicates that the interface can be accessed normally. After the url, add? Wsdl can obtain more detailed interface information, such:
Client
1. ClientPasswordHandler security verification class
The Client Security Authentication class must inherit the AbstractHandler class to implement the invoke method. The authentication information constructed in the Element method is added to the SOAP message header information, then add this class to the request of the Service Interface accessed by the client, and the security verification will be completed by the AuthenticationHandler class of the server.
Public class ClientPasswordHandler extends acthandler {private String username = null; private String password = null; public String getUsername () {return username;} public void setUsername (String username) {this. username = username;} public String getPassword () {return password;} public void setPassword (String password) {this. password = password;} public ClientPasswordHandler (String username, String password) {this. username = username; this. password = password;} public void invoke (MessageContext context) throws Exception {// construct the authentication information for the SOAP Header Element el = new Element ("header"); // Header context. getOutMessage (). setHeader (el); Element auth = new Element ("AuthenticationToken"); // custom Element username_el = new Element ("Username"); username_el.addContent (username ); element password_el = new Element ("Password"); password_el.addContent (password); auth. addContent (username_el); auth. addContent (password_el); el. addContent (auth );}}
 
2. access the server interface
The GetServiceBean class is used to obtain the interface objects of the server side and add the client verification class. ClientTest calls GetServiceBean to obtain the interface objects of the server side, and then calls the methods (such as) Like local classes ), the obvious requirement here is that the client must retain the interface class and object class of the server to complete the call.
Public class GetServiceBean {private static XFireProxyFactory factory = new XFireProxyFactory (); public static Object getBean (String serviceUrl, Class <?> ServiceClass) throws MalformedURLException {Service service = new ObjectServiceFactory (). create (serviceClass); Object object = factory. create (service, serviceUrl); Client client = (XFireProxy) Proxy. getInvocationHandler (object )). getClient (); // obtain the client that accesses the service. addOutHandler (new ClientPasswordHandler ("test", "test"); // Add the client verification class return object ;}}
Public class ClientTest {public static void main (String [] args) throws Exception {HelloWorldService service = (HelloWorldService) GetServiceBean. getBean ("http: // localhost/xfireserver/helloworld. ws ", HelloWorldService. class); System. out. println (service. hello ("James"); Person person = new Person (); person = service. getPerson (); System. out. println ("id:" + person. getId () + "name:" + person. getName (); List <Person> students = new ArrayList <Person> (); students = service. getList (); for (int I = 0; I <students. size (); I ++) {Person per = students. get (I); System. out. println ("id:" + per. getId () + "name:" + per. getName ());}}}
Conclusion:I personally understand that there will be some negative and incorrect points. You are welcome to criticize and correct them!
Demo: http://pan.baidu.com/s/1eQxRjeM