I and Arun presented about Metro in Glassfish at SiliconValey CodeCamp this saturday on Metro. We had some glitches with the projector during our presentation, but the spirit of the audience helped us continue with the presentation and it went well later on. Some of the audience are very familiar with JAX-WS and are trying JAX-WS 2.1.3 as well :).
|
Here is a photo showing me in action at SiliconValley CodeCamp(Thanks Arun for taking the photo). |
|
Here is a photo with the Silicon Valley JUG leaders Aaron Houston , Van Riper, Kevin Nelson chatting about the sessions and JUGs. |
|
|
Here is a photo of me with Java Posse guys [Tor Norbye (Sun Microsystems), Carl Quinn (Google), Dick Wall (Google) and Joe Nuxoll (Apple)]. I liked the session and seeing them in live with their funny hats on. |
I will be waiting for the next SiliconValley CodeCamp.
Technorati: siliconvalleycodecamp metro glassfish webservices netbeans
]]>
As you all know JAX-WS 2.1 is re-architected implementation of JAX-WS 2.0 RI that has lot of performance improvements. Currently to reap the benefits of the JAX-WS improvements, using it on JDK 6 is little tricky. To use JAX-WS 2.1, You need use the endorsed override mechanism by placing jaxws-api.jar and jaxb-api.jar in JAVA_HOME/jre/lib/endorsed. More about using JAX-WS 2.1 on JDK 6 has been described here earlier. JAX-WS 2.0 is part of JDK 6 and I can say that recently released JDK 6 Update 3 will be the last Java SE 6 release using JAX-WS 2.0.
A good news for you all, JAX-WS 2.1.1 RI FCS is being integrated to the future Update Releases. Yay, no more endorsed mechanism to use JAX-WS 2.1. An early access build of Java SE 6 Update 5 Release is available for you to try.
Technorati:
Web Services Addressing 1.0 Metadata specification produced by Web Services Addressing Working Group is now a W3C recommendation. This Metadata specification defines standard way to express the abstract properties of Web Services Addressing 1.0 core in WSDL and to express support and conformance to Web Services Addressing 1.0 in the wsdl. It also defines how WSDL Metadata is included in an Endpoint Reference (EPR).
This WS-Addressing Metadata specification replaces the previous Web Services Addressing 1.0 - WSDL Binding specification in candidate recommendation earlier. The main difference is in the way support for Addressing is expressed in wsdl and of course the namespace (change from wsaw:http://www.w3.org/2006/02/addressing/wsdl to wsam:http://www.w3.org/2007/05/addressing/metadata). In WSDL Binding specification, an WSDL extensibility element <wsaw:UsingAddressing> was used. This Metadata specification uses Web Services Policy Framework (WS Policy 1.5) and Web Services Policy - Attachment [WS Policy 1.5 - Attachment] specifications to express the support of Web Services Addressing 1.0. A new policy assertion <wsam:Addressing> is defined to express it.
New policy Assertions:
When <wsam:Addressing> is present in a Policy alternative, one is required to use WS-Addressing to communicate with the subject.
<wsam:Addressing wsp:Optional="true"> can be used to indicate support for WS-Addressing but does not require the use of it.
In these cases, there are no restrictions about the use of WS-Adressing.
Nested asertions can be used to restrict the use of WS-Addressing inside the <wsam:Addressing> assertion.
can be used to indicate that the subject requires WS-Addressing and requires the use of non-anonymous response EPRs
can be used to indicate that the subject requires WS-Addressing and requires the use of anonymous responses.
I discussed briefly in my earlier blog about including WSDL Metadata in EPR. In a future blog, I will write about how abstract Addressing properties like action and reference parameters are descibed in WSDL.
As you know, JAX-WS 2.1 did not define WSDL binding for WS-Addressing as things were in flux during the release of 2.1 specification. Now that Metadata specification is final, JAX-WS can use these standard policy assertions and description of abstract addressing properties in wsdl.
Technorati:
JAX-WS
JDK
]]>
For example,
<wsam:Addressing>
<wsp:Policy>
<wsam:NonAnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
JAX-WS
WS-Addressing
]]>
The JAX-WS Samples documentation describes steps for running samples with Glassfish and Tomcat 5.x. It suggests you to copy all web services jars to $CATALINA_HOME/shared/lib when running with Tomcat, so that these libraries can be available to all Web applications.
When you are running with Tomcat 6.x, the classloading mechanism has changed a bit from earlier versions of Tomcat. You can notice there is no common, server, shared directories in the Tomcat installation. All you see is the lib directory. It seems this is done to avoid confusion for the users. You can find more details about the Tomcat 6.0 classloading here
To run the samples with Tomcat 6 follow these steps. Edit $CATALINA_HOME/conf/catalina.properties and set shared.loader={RI Installation Directory}/lib/*.jar If you are running multiple instances of Tomcat, then edit CATALINA_BASE/conf/catalina.properties for that particular instance. The same technique can be used with Tomcat 5.x if you don't like to copy all the jars to $CATALINA_HOME/shared/lib
For the complete steps for running the samples, follow as instructions listed in the samples document.
Technorati:
JAX-WS Samples
Tomcat
]]>
I am pleased to participate in the interop testing of section 2.1 in Metadata Specification with IBM. The test plan for this feature has been approved by the WG in the last call. Though Sun's implementation of WS Addressing does n't support complete Metadata specification now, it has partial implementation to support EPR's conforming to Metadata specification. Sun has passed all the mandatory as well as optional tests related to this feature. I was pleased to work with David Illsley from IBM in the interop testing from Sun's side. Hopefuly these results will be approved by the WG and then section 2.1 will stay during the transtion from CR to PR phase.
A brief look at how this feature can be helpful when using EPRs to reference Web Services. In JAX-WS you can create proxy from an EPR if the runtime can get all the binding related information from the EPR. This enables the EndpointReference.getPort(SEI) API in JAX-WS to work, as it can get the wsdl metadata from EPR, which can be really useful when dealing with Stateful Web Services feature utilizing addressing headers and EPRS in the background.
If these results are approved by the WSA WG, Section 2.1 is going to stay in PR. Though the plans for full support for WS Addressing Metadata in JAX-WS RI are not concrete yet, this will be available in the near future. I will explain how to reference wsdl metadata in an EPR in a follow up blog.
Technorati:
JAX-WS
WSAddressing
Accessing Inbound SOAP Headers: To access all the headers (including headers that are not bound to parameters) in the endpoint implementation, one has to write a handler to access those from the SOAPMessage. Instead on can use the read-only property JAXWSProperties.INBOUND_HEADER_LIST_PROPERTY from WebServiceContext directly.
Adding Outbound SOAP Headers: Sometimes, one may need to send some additional headers that are not defined in the wsdl or bound to parameters. Instead of writing a SOAP Handler and doing the dirty work one can easily do this by downcasting the proxy to WSBindingProvider and set the Outbound headers.
HelloPort port = helloService.getHelloPort(); WSBindingProvider bp = (WSBindingProvider)port; bp.setOutboundHeaders( // simple string value as a header, likestringValue Headers.create(new QName("simpleHeader"),"stringValue"), // create a header from JAXB object Headers.create(jaxbContext,myJaxbObject) );
As you see Headers are created using com.sun.xml.ws.api.message.Headers class, which provides factory methods to create headers in different wasy easily. More information on using this feature can found in Kohsuke's blog Adding SOAP headers
Creating Stateful Web Services:
Using @HttpSessionScope:
One way to bring state to Web Services is to use Http Session cookies. Storing the state and accessing it from the HttpSession (from WebServiceContext) for each request takes multiple steps and does n't fit well with the OO way of accessing/storing it with instance fields.
One can use @com.sun.xml.ws.developer.servlet.HttpSessionScope annotation tells the JAX-WS RI to create one instance of Hello per each HTTP session. As you see this approach still relies on Http cookies but makes it easier to access state from the context just like normal instance variables.
Using @Stateful:
JAX-WS also provides a transport neutral mechanism to do this and makes use of the WS-Addressing standard. It introduces @com.sun.xml.ws.developer.Stateful to take care of maintaining all the state and the user can access it using instance variables. All the user needs to do is to add @Stateful and @Addressing to Web Service implementation. As you see, this is requires support for Addressing.
More information about using this feature can be found from stateful sample in the JAX-WS 2.1 bundle and in Kohsuke blogs Stateful web services with JAX-WS RI
and HttpSessionscope.
Logging of SOAP Messages: Web Services developers generally need to see SOAP Messages that are transferred between client and service for debugging. There are couple of SOAP Monitors for this job, but you need modify the client or server code to use those tools. JAX-WS provides logging of SOAP messages by using a System property com.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true on client-side. My blog about Monitoring SOAP Messages talks more about it. If you are using Glassfish, it provides nice GUI tools to montior SOAP messages for Web Service. Unfortunately this works only with 109 based Web Services. For Servlet based WebServices, you can use com.sun.xml.ws.transport.http.HttpAdapter.dump system property to dump the SOAP traffic.
Propagation of Server-side Stacktrace: This is a very useful feature while developing Web Services. Often the soap fault messages does n't convey enough information about the problem. JAX-WS relieves you from digging out the server logs to find out the stacktrace. Now the whole stacktrace (including nested exceptions) is propagated in the SOAP Fault and the complete exception stacktrace is visible to the client. Propation of Stacktrace is on by default, If you think its not safe for your Web Service Application to send the complete stacktrace, you can turn off this functionality by setting the System property com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace.
Support for MemberSubmission Addressing: One can use @com.sun.xml.ws.developer.MemberSubmissionAddressing or com.sun.xml.ws.developer.MemberSubmissionAddressingFeature to use member submission version of Addressing. You can follow the fromjava-wsaddressing sample in JAX-WS 2.1 bundle except that @MemberSubmissionAddressing and MemberSubmissionAddressingFeature is used instead if @Addressing and AddressingFeature.
Most interesting part, all of these features are done using extensions points provided by the JAXWS RI. You can develop similar features using JAXWS pluggability architecture and more on this can be found in my blog Extending JAX-WS With Annotations.
We hope these developer properties and features are useful and make using Web Services a bit easier. Do provide your valuable feedback to dev@jax-ws.dev.java.net
]]>