[wise-users] [Wise] - Wise-core Programmer Guide (version 1.0)

Administrator Administrator [http://community.jboss.org/people/admin] modified the document: "Wise-core Programmer Guide (version 1.0)" To view the document, visit: http://community.jboss.org/docs/DOC-12896 -------------------------------------------------------------- * #1_What_is_wisecore 1. What is wise-core * #2__Who_should_read_this_guide 2 . Who should read this guide * #3_API_description 3. API description * #4_Configurations 4. Configurations ** #41_WiseClientConfiguration 4.1 WiseClientConfiguration ** #42_WSDynamicClientFactory 4.2 WSDynamicClientFactory ** #43_WSConsumer 4.3 WSConsumer ** #44_WSSEHelloWorld 4.4 WSSEHelloWorld ** #45_WSSEDefault 4.5 WSSEDefault ** #46_EnablerDelegate 4.6 EnablerDelegate * #5_Using_Wise_API 5. Using Wise API ** #51_One_line_of_code_invocation 5.1 One line of code invocation ** #52_Interactively_explore_your_wsdl_objects 5.2 Interactively explore your wsdl objects ** #53_Go_Dynamic_use_Groovy 5.3 Go Dynamic, use Groovy ** #54_Go_Dynamic_use_Ruby 5.4 Go Dynamic, use Ruby * #6_WiseMapper_from_your_own_object_model_to_the_generated_JAXWS_model_and_vice_versa 6. WiseMapper: from your own object model to the generated JAX-WS model and vice versa ** #61_SmooksWiseMapper 6.1 SmooksWiseMapper ** #62_Writing_your_own_Mapper 6.2 Writing your own Mapper * #7_Adding_standard_JAXWS_handlers 7. Adding standard JAX-WS handlers ** #71_Logging_Handler 7.1 Logging Handler ** #72_Smooks_Handler 7.2 Smooks Handler ** #73_Adding_your_own_Handler 7.3 Adding your own Handler * #8_Extensions_WS_and_MTOM 8. Extensions (WS-* and MTOM) * #9_JAXRS_Client_Support 9. JAX-RS Client Support ** #91_Create_RSDynamicClient 9.1 Create RSDynamicClient ** #92_Return_responses_ 9.2 Return responses * #10_Requirements_and_dependencies 10. Requirements and dependencies ** #101_Special_Note_on_jaxwsrt_and_jbosswsnativejaxws_jars_on_JDK5 10.1 Special Note on jaxws-rt and jbossws-native-jaxws jars on JDK5 * #11_Samples 11. Samples ** #111_AddressingAndSecurity 11.1 AddressingAndSecurity ** #112_HelloWorld 11.2 HelloWorld ** #113_HelloWorldGroovy 11.3 HelloWorldGroovy ** #114_HelloWorldJDK6 11.4 HelloWorldJDK6 ** #115_HelloWorldRuby 11.5 HelloWorldRuby ** #116_InteractiveHelloWorldJDK6 11.6 InteractiveHelloWorldJDK6 ** #117_jaxrs 11.7 jaxrs ** #118_MTOMSample 11.8 MTOMSample ** #119_UsingSmooks 11.9 UsingSmooks h1. 1. What is wise-core It is a library to simplify web service invocation from a client point of view aims to  provide a near zero-code solution to find and parse wsdls, select service and endpoint and call operations mapping user defined object model to JAX-WS objects needed to perform the call. In other words wise-core aims to provide web services client invocation in a dynamic manner. It’s matter of fact that wsconsume tools is great for java developer, generating needed stub class, but it introduces a new (or renewed :) ) level of coupling very similar to corba IDL. Generating statically webservice stub you are in fact coupling client and server. So what is the alternative? Generate these stubs runtime and use dynamic mapping on generated stub. How wise-core does perform this generic task? In a nutshell it generates classes on the fly using wsconsume runtime API, loading them in current class loader and uses them with Java Reflection API. What we add is a generic mapping API to transform an arbitrary object model in the wsconsume generated ones, make the call and map the answer back again to the custom model using Smooks. Moreover this is achieved keeping the API general enough to plug in other mappers (perhaps custom ones) to transform user defined object into JAX-WS generated objects. Wise supports standard JAX-WS handlers too and a generic smooks transformation handler to apply transformation to generated SOAP messages; in the next future it will also support easy configuration/API to activate various WS-*. The key to understand the Wise-core idea is to keep in mind it is an API hiding JAX-WS wsconsume tools to generate JAX-WS stub classes and providing API to invoke them in a dynamic way using mappers to convert your own object model to JAX-WS generated one. One of the most important aspects of this approach is that Wise delegates everything concerning standards and interoperability to the underlying JAX-WS client implementation (JBossWS in the current implementation). In other words if an hand written webservice client using JBossWS is interoperable and respects standard, the same applies for a Wise-generated client! We are just adding commodities and dynamical transparent generation and access to JAX-WS clients, we are not rewriting client APIs, the well tested and working ones from JBossWS is fine for us ;) h1. 2 . Who should read this guide This guide is written for developers who would use Wise-core in their own application to call webservices. This guide would be very useful also for programmers and architect using JBossESB and would better understand what is happening under the hood during a zero-code webserive invocation based on Wise. h1. 3. API description We are going to describe here our API, its goals and how it could be used in practice to simplify your webservice client development. Anyway we strongly suggest you to take a look at our javadoc as more complete reference for the API. The core elements of our API are: * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WSDynamicClient: This is the Wise core class responsible for the invocation of the JAX-WS tools and that handles wsdl retrieval & parsing. It is used to build the list of WSService representing the services published in parsed wsdl.  It can also be used to directly get the WSMethod to invoke the specified action on specified port of specified service. It is the base method for "one line of code invocation" * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WSService: represents a single service. It can be used to retrieve the current service endpoints (Ports). * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WSEndpoint: represents an Endpoint(Port) and has utility methods to edit username, password, endpoint address, attach handlers, etc. * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WSMethod: represents a webservice operation(action) invocation and it always refers to a specific endpoint. It is used for effective invocation of a web service action. * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WebParameter: holds single parameter's data required for an invocation * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... InvocationResult: holds the webservice's invocation result data. Anyway it returns a Map<String, Object> with webservice's call results, eventually applying a  mapping to custom objects using a WiseMapper * http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WiseMapper: is a simple interface implemented by any mapper used within wise-core requiring a single method applyMapping. All the elements mentioned above can be combined and used to perform web service invocation and get results. They basically support two kinds of invocation: 1. One line of code invocation: with this name we mean a near zero code invocation where developer who have well configured Wise just have to know wsdl location, endpoint and port name to invoke the service and get results. For a complete description and sample of this Wise usecase please refer to paragraph 5.1. 2. Interactively explore your wsdl: Wise can support a more interactive style of development exploring all wsdl artifact dynamically loaded. This kind of use is ideal for an interactive ser interface to call the service and is by the way how we are developing our web GUI. For a complete description and sample of this Wise usecase please refer to paragraph 5.2. h1. 4. Configurations Wise-core configurations are provided by JBoss standard inversion of control Micro Container. Wise-core read standard META-INF/jboss-beans.xml from your classpath. We suggest to put them into your jar, but also include a resources dir in your classpath is fine (and in fact is what is done in our samples). A typical jboss-beans.xml for Wise look like this one: <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"      xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"      xmlns="urn:jboss:bean-deployer">      <bean name="WSKernelLocator" class="org.jboss.wise.core.jbossmc.KernelUtil">           <property name="kernel">                <inject bean="jboss.kernel:service=Kernel" />           </property>      </bean>      <bean name="WiseClientConfiguration"           class="org.jboss.wise.core.jbossmc.beans.WiseClientConfiguration">           <property name="defaultUserName">foo</property>           <property name="defaultPassword">pwd</property>           <property name="defaultTmpDeployDir">temp</property>                </bean>      <bean name="WSDynamicClientFactory"           class="org.jboss.wise.core.jbossmc.beans.ReflectionWSDynamicClientFactory">           <property name="config">                <inject bean="WiseClientConfiguration"></inject>           </property>      </bean>      <bean name="WSConsumer"           class="org.jboss.wise.core.consumer.impl.jbosswsnative.WSImportImpl">           <property name="keepSource">true</property>           <property name="verbose">true</property>      </bean>     <bean name="WSSEHelloWorld"         class="org.jboss.wise.core.wsextensions.impl.jbosswsnative.NativeSecurityConfig">         <property name="configFileURL">integration/test/wsse/WEB-INF/jboss-wsse-client.xml</property>         <property name="configName">Standard WSSecurity Endpoint</property>     </bean>     <bean name="WSSEDefault"         class="org.jboss.wise.core.wsextensions.impl.jbosswsnative.NativeSecurityConfig">         <property name="configFileURL">integration/test/wsse/WEB-INF/jboss-wsse-client.xml</property>         <property name="configName">Standard WSSecurity Client</property>     </bean>      <bean name="EnablerDelegate"           class="org.jboss.wise.core.wsextensions.impl.jbosswsnative.ReflectionEnablerDelegate">           <property name="securityConfigMap">                <map class="java.util.HashMap" keyClass="java.lang.String"                     valueClass="java.lang.String">                     <entry>                          <key>HelloWorldBeanPort</key>                          <value>                               <inject bean="WSSEHelloWorld" />                          </value>                     </entry>                </map>           </property>           <property name="defaultSecurityConfig"><inject bean="WSSEDefault" /></property>      </bean> </deployment> Here is a description of bean configured in this file and their valid attribute: h2. 4.1 WiseClientConfiguration It contains all default values Wise could use for some common attribute during a call. Of course they can be overridden in the code. || *Property * || *Description * || | defaultUserName | It's the default user name used to call webservice requiring authentication. | | defaultPassword | I'ts the default password used to call webservice requiring authentication. | | defaultTmpDir | It's the temporary directory used by Wise to keep downloaded wsdls and wsconsume generated classes file. *It's very important to understand that this directory is cleaned when Wise perform its first call after JVM starts.* *For this reason you have to provide different tmp dirs if you plan to run wise with more than one JVM.* | | logConfig | It's the location of Wise's log4j config file. | h2. 4.2 WSDynamicClientFactory It injects the client factory implementation, deciding in fact which implementation of Wise API you are using. At the moment we provide just this reflection based implementation, but in near future we will have also a Javassist ones. Of course here you can provide your own implementation and inject it. h2. 4.3 WSConsumer It injects the WSConsumer implementation, deciding which API you are using to consume the wsdl and generate JAX-WS client classes. At the moment we are providing a org.jboss.wise.core.consumer.impl.jbosswsnative.WSImportImpl. This bean may be used also to set some general properties for class generation: || *Property* || *Description* || | verbose | boolean value to decide if wsconsume have to use verbose option printing more information during compiling and running classes | | keepSource | boolean value to decide if Wise has to keep source java files (and not only .class) in tmp directory. It may be useful to have a look at them in case of problem or debug. | h2. h2. 4.4 WSSEHelloWorld It injects a WS-Security configuration specific for the "HelloWorld" service. See section 4.6 to understand how this configuration is used and  enabled in wise-core. This bean isn't required for all WS-Security enabled services because if some service haven't specific config the default configuration is used (see section 4.5). Possible property are: || *Property * || *Descrition * || | configFileURL | It is the URL of config file used by JbossWS to enable WS-SE. For more information about this file refer to our samples and/or to JBossWS documentation (http://jbossws.jboss.org/mediawiki/index.php?title=JAX-WS_User_Guide#WS-S...) | | configName | It is the config name sed by JbossWS to enable WS-SE. For more information about this file refer to our samples and/or to JBossWS documentation (http://jbossws.jboss.org/mediawiki/index.php?title=JAX-WS_User_Guide#WS-S...) | h2. h2. 4.5 WSSEDefault It injects a WS-Security default configuration used by services which don't define a specific configuration as described in section 4.5. See also section 4.6 to understand how this configuration is used and  enabled in wise-core. Possible property are: || *Property * || *Descrition * || | configFileURL | It is the URL of config file used by JbossWS to enable WS-SE. For more information about this file refer to our samples and/or to JBossWS documentation (http://jbossws.jboss.org/mediawiki/index.php?title=JAX-WS_User_Guide#WS-S...) | | configName | It is the config name sed by JbossWS to enable WS-SE. For more information about this file refer to our samples and/or to JBossWS documentation (http://jbossws.jboss.org/mediawiki/index.php?title=JAX-WS_User_Guide#WS-S...) | h2. 4.6 EnablerDelegate It injects WS-Security configs and link them to right Ports. In other words it enables WS-Security on Ports used as key of securityConfigMap defining also which securityConfig to use for them. Possible property are: || *Property * || *Descrition * || | securityConfigMap | It inject a java.util.HashMap with PortNames as key and injectig a specif WS-Security configuration bean as value. See also section 4.4 | | defaultSecurityConfig | WS-Security default configuration used by services which don't define a specific configuration (not appearing on securityConfigMap). See also section 4.5http://jbossws.jboss.org/mediawiki/index.php?title=JAX-WS_User_Guide#W... | h1. 5. Using Wise API Wise can be used either as near zero code web service invocation framework or as an API to (interactively) explore wsdl generated objects and then perform the invocation through theselected service/endpoint/port. The first approach is very useful when Wise is integrated in a server side solution, while the second one is ideal when you are building an interactive client with some (or intense) user interaction. By the way the first approach is the one that has been used while integrating Wise in JBossESB, while the second one is the base on which we are building or web based generic interactive client of web service (Wise-webgui). h2. 5.1 One line of code invocation A sample may be much more clear than a lot of explanation: WSDynamicClient client = WSDynamicClientFactory.getInstance().getClient("http://127.0.0.1:8080/HelloWorldJDK6/HelloWorldWSJDK6?wsdl"); WSMethod method = client.getWSMethod("HelloWorldWSJDK6Service", "HelloWorldJDK6Port", "sayHello"); HashMap<String, Object> requestMap = new HashMap<String, Object>(); requestMap.put("toWhom", "SpiderMan"); InvocationResult result = method.invoke(requestMap, null); I can already hear you saying: "hey, you said just 1 line of code, not 5!!". Yes, but if you exclude lines 3 and 4 where we are constructing a Map to put in request parameters that are normally build in other ways from your own program, you can easily compact the other 3 lines in just +one line of code invocation+. By the way keeping 3 lines of code makes the code more readable, but we would remark that conceptually you are writing a single line of code. You can find a running sample called *+HelloWorld+* using exactly this code in our samples directory (both for JDK5 and JDK6). h2. 5.2 Interactively explore your wsdl objects Here too an example would be good: WSDynamicClient client = WSDynamicClientFactory.getInstance().getClient("http://127.0.0.1:8080/InteractiveHelloWorldJDK6/InteractiveHelloWorldWSJDK6?wsdl"); Map<String, WSService> services = client.processServices(); System.out.println("Available services are:"); for (String key : services.keySet()) {     System.out.println(key); } System.out.println("Selecting the first one"); Map<String, WSEndpoint> endpoints = services.values().iterator().next().processEndpoints(); System.out.println("Available endpoints are:"); for (String key : endpoints.keySet()) {     System.out.println(key); } System.out.println("Selecting the first one"); Map<String, WSMethod> methods = endpoints.values().iterator().next().getWSMethods(); System.out.println("Available methods are:"); for (String key : methods.keySet()) {     System.out.println(key); } System.out.println("Selecting the first one"); WSMethod method = methods.values().iterator().next(); HashMap<String, Object> requestMap = new HashMap<String, Object>(); requestMap.put("toWhom", "SpiderMan"); InvocationResult result = method.invoke(requestMap, null); You can find a running sample called +*IntercativeHelloWorld*+ using exactly this code in our samples directory. h2. 5.3 Go Dynamic, use Groovy Yes, Wise supports Groovy. We have a sample in our code base invoking HelloWorld from a Groovy script. We also have an example using closure to invoke a web service through Wise, just changing the input parameters to demonstrate how much Wise can be efficient caching all artifacts and having performance very similar to what you get with native use of JAX-WS client classes after the first invocation. But supporting Groovy means much more than this. Groovy is an high dynamic language and so it can be used to inspect dynamically generated classes. In other words with Groovy you can avoid to use Wise mappers, directly and dynamically using our generated classes. We will provide much more documentation and samples in next releases of Wise; until then, just use your creativity, and contribute reporting your experiments in the user forums. But why using Wise from Groovy? Haven't Groovy its own web service client? Yes, but with Wise you will have a client for Groovy certified for JAX-WS standard, supporting authentication, MTOM, standard JAX-WS handlers, and of course WS-*. h2. 5.4 Go Dynamic, use Ruby Yes, Wise supports Ruby too (through JRuby). We have a sample in our code base invoking HelloWorld from a Ruby script. We also have an example using closure to invoke a web service through Wise, just changing the input parameters to demonstrate how much Wise can be efficient caching all artifacts and having performance very similar to what you get with native use of JAX-WS client classes after the first invocation. But, as for Groovy, supporting Ruby means much more than this. With a so muchhigh dynamic language you could inspect dynamically generated classes. In other words with Ruby you can avoid to use Wise mappers, directly and dynamically using our generated classes. We will provide much more documentation and samples in next releases of Wise; until then, just use your creativity, and contribute reporting your experiments in the user forums. But why using Wise from Ruby? Haven't Ruby its own web service client? Yes, but with Wise you will have a client for Ruby certified for JAX-WS standard, supporting authentication, MTOM, standard JAX-WS handlers, and of course WS-*. h1. 6. WiseMapper: from your own object model to the generated JAX-WS model and vice versa The core idea of Wise is to permit users to call webservice using their own object model, loading at runtime (and hiding) the JAX-WS generated client classes. Of course developers who have a complex object model and/or using a webservice with a complex model have to provide some kind of mapping between them. This task is done by applying a WiseMapper which is responsible of this mapping. Mappers are applied both to WSMethod invocation and results coming from InvocationResult. Of course the first one maps from the custom model to the JAX-WS one, while the second takes care of the other way. Wise provide a http://milyn.codehaus.org/Smooks Smooks based mapper, but it should be easy to write your own. h2. 6.1 SmooksWiseMapper For any information about Smooks and its own configuration file please refer to http://milyn.codehaus.org/Smooks+Documentation its own documentation When writing a Smooks config file to use with Wise, you need to consider that the object model generated by JAX-WS tools isn't available at compile time since Wise generates it at runtime. Even if in most cases you can infer the JAX-WS generated classes and properties names from the wsdl document, sometimes it might be useful to set keepSource = true in Wise's jboss-beans.xml to have the opportunity to take a look to generated classes. We provide a sample demonstrating use of smooks mapper in our code base named +*usingSmooks*+. h2. 6.2 Writing your own Mapper You just have to implement http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WiseMapper interface. h1. 7. Adding standard JAX-WS handlers WSEndPoint class has a method to add standard JAX-WS handlers to the endpoint. Wise takes care of the handler chain construction and ensures your client side handlers are fired during any invocations. We provide two standard handlers: one to log the request/response SOAP message for any invocation and one applying Smooks transformation on your SOAP content. h2. 7.1 http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... Logging Handler This simple SOAPHandler will output the contents of incoming and outgoing messages. It checks the MESSAGE_OUTBOUND_PROPERTY in the context to see if this is an outgoing or incoming message. Finally, it writes a brief message to the print stream and outputs the message. h2. 7.2 http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... Smooks Handler A SOAPHandler extension. It applies Smooks transformations on SOAP messages. The transformation can also use freemarker, using provided javaBeans map to get values. It can apply transformation on inbound messages only, outbound ones only or both, depending on setInBoundHandlingEnabled(boolean) and setOutBoundHandlingEnabled(boolean) methods. Take a look at our unit test org.jboss.wise.core.mapper.SmooksMapperTest in test-src directory. h2. 7.3 Adding your own Handler Since Wise's handlers are JAX-WS standard handlers, you just have to provide a class that implements SOAPHandler<SOAPMessageContext> h1. 8. Extensions (WS-* and MTOM) We tried to respect the Wise's easy to use approach also designing APIs to enable and use most common extensions (MTOM and WS-*) in Wise. There are in Wise's API an interface ( http://www.jboss.org/file-access/default/members/wise/freezone/1.0/apiDoc... WSExtensionEnabler) defining a WSExtension to be enabled on an endpoint using wise-core client APIs. The basic idea is to add  all WSExtension you want to enable to a ../../../file-access/default/members/wise/freezone/1.0/apiDocs/org/jboss/wise/core/client/WSEndpoint.html WSEndpoint using addWSExtension method. WSExtension implementation are meant to  be pure declarative class delegating all their operations to a "visitor" class injected into the system with IOC Different  Visitors implement ../../../file-access/default/members/wise/freezone/1.0/apiDocs/org/jboss/wise/core/wsextensions/EnablerDelegate.html EnablerDelegate and have to take care to implement necessary steps to implement various WSExtension  for the JAXWS implementation for which they are supposed to work. A snippet of use may clarify how much simple it can be from API's user poit of view WSDynamicClient client = WSDynamicClientFactory.getInstance().getJAXWSClient("http://127.0.0.1:8080/MTOMSample/MTOMWS?wsdl"); WSMethod method = client.getWSMethod("MTOMWSService", "MTOMPort", "sayHello"); method.getEndpoint().addWSExtension(new MTOMEnabler()); It enable mtom on +MTOMPort+ endpoint. The same can be applied for example to easily enable both WSSecurity and WSAddressing on endpoint. Take a look to this amazing snippet: WSDynamicClient client = WSDynamicClientFactory.getInstance().getJAXWSClient("http://127.0.0.1:8080/AddressingAndSecuritySample?wsdl"); WSMethod method = client.getWSMethod("EndpointImplService", "EndpointImplPort", "sayHello"); method.getEndpoint().addWSExtension(new WSSecurityEnabler()); method.getEndpoint().addWSExtension(new WSAddressingEnabler()); These few lines of code and some easy configs for WSSecurity (see section 4.4, 4.5 and 4.6) are all what you need to enable WS-SE and WS-A! Take a look to our samples to get some complete working code about (section 10) We plan to support in the same manner also some other WS-* in future versions. h1. 9. JAX-RS Client Support WISE has a preliminary JAX-RS client support to allow writing clients that can invoke JAX-RS services. The code snippet below showed how this works: // Sent HTTP GET request to query customer info System.out.println("Sent HTTP GET request to query customer info"); RSDynamicClient client = WSDynamicClientFactory.getInstance().getJAXRSClient(                             "http://localhost:9000/customerservice/customers/123",                             RSDynamicClient.HttpMethod.GET, null,                             "application/xml"); InvocationResult result = client.invoke(); String response = (String) result.getResult().get(InvocationResult.RESPONSE); System.out.println(response);     // Sent HTTP PUT request to update customer info System.out.println("\n"); System.out.println("Sent HTTP PUT request to update customer info"); client = WSDynamicClientFactory.getInstance().getJAXRSClient(                     "http://localhost:9000/customerservice/customers",                     RSDynamicClient.HttpMethod.PUT, "application/xml",                     "application/xml"); JaxrsClient jaxrsClient = new JaxrsClient(); InputStream request = jaxrsClient.getClass().getResourceAsStream("resources/update_customer.xml"); result = client.invoke(request, null); response = (String) result.getResult().get(InvocationResult.RESPONSE); int statusCode = ((Integer) result.getResult().get(InvocationResult.STATUS)).intValue(); System.out.println("Response status code: " + statusCode); System.out.println("Response body: "); System.out.println(response);       // Sent HTTP POST request to add customer System.out.println("\n"); System.out.println("Sent HTTP POST request to add customer"); client = WSDynamicClientFactory.getInstance().getJAXRSClient(                     "http://localhost:9000/customerservice/customers",                     RSDynamicClient.HttpMethod.POST, "application/xml",                     "application/xml"); request = jaxrsClient.getClass().getResourceAsStream("resources/add_customer.xml"); result = client.invoke(request, null); response = (String) result.getResult().get(InvocationResult.RESPONSE); statusCode = ((Integer) result.getResult().get(InvocationResult.STATUS)).intValue();     System.out.println("Response status code: " + statusCode); System.out.println("Response body: "); System.out.println(response);   h2. 9.1 Create RSDynamicClient The main interface you need to use is the getJAXRSClient method from WSDynamicClientFactory. See below:     /**      * Return an instance of RSDynamicClient taken from cache if possible, generate and initialise if not.      *      * @param endpointURL      * @param httpMethod      * @param produceMediaTypes      * @param consumeMediaTypes      * @return an instance of {@link RSDynamicClient} already initialized, ready to be called      */     public RSDynamicClient getJAXRSClient( String endpointURL,                                            RSDynamicClient.HttpMethod httpMethod,                                            String produceMediaTypes,                                            String consumeMediaTypes ) {         ......       }   h2. 9.2 Return responses Get the response body:             InvocationResult result = client.invoke();             String response = (String) result.getResult().get(InvocationResult.RESPONSE);             System.out.println(response);   Get the response code:             InvocationResult result = client.invoke(request, null);             String response = (String) result.getResult().get(InvocationResult.RESPONSE);             int statusCode = ((Integer) result.getResult().get(InvocationResult.STATUS)).intValue();   Get the response headers:             Not supported yet in this version   h1. 10. Requirements and dependencies The current implementation depends on JBossWS. Take a look to our samples to better understand which libraries are required. A special note is needed about some JAX-WS jars included, since it have been slightly modified to make Wise and JBossWS client work properly. h2. 10.1 Special Note on jaxws-rt and jbossws-native-jaxws jars on JDK5 The problem is caused because JBossWS uses 2 different jaxws provider impl (one for tooling, the Sun's RI, and one for everything else, it's own implementation) Of course due to the spi mechanism of loading provider, you can't have both in classpath since the one loaded first takes prevalence on the other. Chaper 6.2.1 of JAX-WS 2.0 specification defines also the algorithm to load this Provider: For this reason, in order to use both implementations, Wise requires modified jar artifacts without the META-INF/services/javax.xml.ws.spi.Provider file; then the Provider implementation to be used is set in WSImporterImpl through a System property. In practise this means you have to use the version of this two libraries that we ship with Wise and not those provided by JBossWS or other sources. The problem isn't present with JDK6 since it uses its internal JAX-WS implementation (coming with the JDK) which uses the same provider used by wsconsume tool avoiding any kind of conflict. h2. h1. 11. Samples We have a set of samples demonstrating how to use wise in a standalone application. We have reported here the full list of samples, describing only ones which need some specific description. Please refer to JBossESB quickstar samples for Wise/ESB integration example of use.What you find in this section is also available in samples README.txt for your convenience. Any directory, except lib and ant ones, contains a single example. Directory name would suggest which kind of test you will find in. Only in case we think example needs a further explanation you will find a local README.txt inside its directory. lib directory contains library referred by examples. ant directory contains build.xml imported from all examples' build.xml. How to run examples? 1. Enter in specific example directory ;) 2. Edit resources/META-INF/jboss-beans.xml and change properties according to your environment (i.e defaultTmpDeployDir) if needed. 3. Edit resources/META-INF/wise-log4j.xml and change properties according to your environment if needed. 4. Edit build.properties changing "JBossHome" and "ServerConfig" property to point to your JBossAS instance 5. Start your JBossAS instance (of course it have to provide JBossWS) 6. type "ant deployTestWS" to deploy server side content (aka the ws against example will run) 7. type "ant runTest" to run the client side example 8. type "ant undeployTestWS" to undeploy server side content 9. Have a look to the code. If something changes for a specific example you will find instructions on local README.txt have fun. h2. 11.1 AddressingAndSecurity This sample demonstrate the WS-* enabler capabilities of wise-core (see section 8 for a complete description). Please focus your attention on jboss-beans.xml configuration (see section 4 for a complete description and specific subsection 4.4, 4.5, 4.6) and on the client's code. h2. 11.2 HelloWorld This the basic sample of use of wise-core using a one-line-of-code style (see section 5.1). It use JDK 5 and jbossws as its base. h2. 11.3 HelloWorldGroovy The same of previous sample, but using groovy (see section 5.3) Groovy include in its botloader directory ($GROOVY_HOME/lib) xpp.jar XML Pull Parser. It conflicts with xercesImpl.jar needed by jbossws and more general by jaxws. If it is happenning you would get this exception: Caught: java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "javax/xml/namespace/QName" java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "javax/xml/namespace/QName" To solve the problem you have to remove or rename this file before use wise directly within an interpreted script. Of course it isn't a problem if you compile script with groovyc since it will compile it in java bytecode and class loading will depend only by jvm used to launch the compiled application. Then run runGroovyJDK6.sh and have fun. If you want to see groovy's closures in action with Wise run runGroovyClosure.sh If you would use this example compiling groovy script in bytecode and then run please type "ant compileGroovy" before type "ant runTest". And please note this example have 2 different script (i.e. compiled classes that can act as Main). Select which one you would run editing locale build.xml file. h2. 11.4 HelloWorldJDK6 The same of 10.2, but using JDK6 and its own native JAX-WS client libraries. It doesen't need jbossws for client side. (see also section 9.1) h2. 11.5 HelloWorldRuby The same of 10.2, but using Ruby (see section 5.4) To run this sample edit runJRubyJDK6.sh and set your JRUBY_PATH. Then run runGroovyJDK6.sh and have fun. If you want to see groovy's closures in action with Wise edit and then run runGroovyClosure.sh h2. 11.6 InteractiveHelloWorldJDK6 This the basic sample of use of wise-core using a interactive style (see section 5.2) h2. 11.7 jaxrs AX-RS Client API Demo ====================== The demo shows how to use WISE JAX-RS client API to invoke JAX-RS services. Prerequisites ------------- Apache CXF 2.2 snapshot. WISE JAX-RS client API can work with any JAX-RS (JSR-311) compliant implementations. This sample chooses Apache CXF for the purpose of demostration. Building and running the demo using Ant --------------------------------------- 1. Download and install Apache CXF 2.2 snapshot. 2. Start CXF JAX-RS server from <CXF-installation-dir>\samples\jax_rs\basic directory. 3. From the base directory of this sample (i.e., where this README file is located), the Ant build.xml file can be used to build and run the demo. The client target automatically build the demo. Using either UNIX or Windows:   ant runTest To remove the .class files generated, run "ant clean". What Happened ------------- Examine JaxrsClient.java, compare it with the client codes used by CXF jax_rs\basic to understand how WISE JAX-RS client API can simplify the invocation of JAX-RS service. h2. 11.8 MTOMSample This sample demonstrate the MTOM enabler capabilities of wise-core (see section 8 for a complete description). Have a look also to this issue https://jira.jboss.org/jira/browse/WISE-45 https://jira.jboss.org/jira/browse/WISE-45 h2. 11.9 UsingSmooks This sample demonstrate the full power of smooks mapper (see section 6.1). Please focus your attention on smooks-config-* files. -------------------------------------------------------------- Comment by going to Community [http://community.jboss.org/docs/DOC-12896] Create a new document in Wise at Community [http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]