Sun has recently enhanced its Java Technology and Web Services web site. The new site has been totally revamped with "tabbed" navigation, making it easier to learn about Sun's Web Services offerings.
The new site's Overview tab is the perfect landing place to see what is the latest and greatest in Sun's Web Services offerings.
From the new site you can learn about WSIT, JAX-WS, JAXB, JAXP, JAX-RPC, SAAJ, and XWSS on the Technologies tab. The Reference tab provides links to all the underlying web services technologies and their related specifications. The Community tab shows various links so that you can become involved in Sun's web services community and even get involved in the development effort if you so choose. The Support
tab gives links to where you can file bugs for and get help with the various technologies. Finally, the
Downloads tab is a convenient place to be able to download the various web services technologies.
JAX-WS 2.1 was written dependent on the
Web Services 1.0 - WSDL Binding candidate recommendation fully expecting this CR to become are recommendation. However, after JAX-WS 2.1 was approved by the EC, the Web Service Addressing Working Group decided to replace the WSDL Binding CR with a new Web Services Addressing 1.0 - Metadata working draft. We felt that it would be prudent to respin the JAX-WS 2.1 specification to remove all dependencies on the WSDL Binding specification. In doing so, none of the JAX-WS APIs will be removed or modified with the exception of the described behavior. Therefore, the revised JAX-WS 2.1 APIs will be binary compatible with the original version. However, since there is no longer a standard way to represent the use of WS-Addressing in a WSDL, using Addressing in a portable manner will be somewhat more burdensome with the revised APIs. The revised JAX-WS specification will not reference the new Metadata specification at this time as it is not yet a recommendation. However, a future version of JAX-WS will reference the final Metadata specification and using addressing will be easier to use once this is done. JAX-WS 2.1 implementations are free to insert non-standard extensibility elements into the WSDL to reflect the use of Addressing.
I was hoping to announce the availability of the Maintenance Release of JAX-WS 2.1 specification before the RI was released, but the RI has once again proven that it is "Too Fast and Too Furious" as it was released last Friday before we could get the JSR 224 page updated. To see how fast the RI is, check out Vivek Pandey's Blog: JAXWS 2.1 FCS - Fast and Furious.
If you would like to read the JAX-WS 2.1 specification or JavaDocs, they can be found at: JAX-WS 2.1 Maintenance Release.
The JAX-WS 2.1 MR focuses on integrating WS-Addressing into the JAX-WS specification. By integrating WS-Addressing into JAX-WS, the web service developer can now utilize EndpointReferences to identify a particular endpoint. An EndpointReference is an opaque object to the web service developer that can be used in conjunction with new APIs on the JAX-WS service interface to get a proxy or Dispatch object for the endpoint referred to by the EndpointReference. The EndpointReference may also contain wsa:referenceParameters that the web service endpoint can use to implement stateful web services.
Another important addition in JAX-WS 2.1 is a solution for the type substitution problem. In JAX-WS 2.0, type substitution did not work mainly because JAX-WS and JAXB were not aware of all the types that an application might use. For example, you may have a WSDL that defines additional types via type substitution that are not referenced directly by a particular service. These additional types could not be marshalled properly by JAX-WS because it was not possible for JAX-WS to know about these additional types. Likewise, when starting from Java, a service endpoint interface may use a base class as a method parameter but at runtime expect to be able to marshall subclasses. Again, JAX-WS did not have any way of knowing about these subclasses and hence could not marshall them. JAXB 2.1 (which has also been submitted for review) introduces the @XmlSeeAlso annotation that can be used to tell JAX-WS and JAXB about additional types that they should be aware of.
JAX-WS 2.1 introduces the notion of "features". A feature is associated with a particular functionality or behavior. Some features may only have meaning when used with certain bindings while other features may be generally useful. JAX-WS 2.1 introduces three standard features, AddressingFeature, MTOMFeature and RespectBindingFeature as well as the base WebServiceFeature class. The AddressingFeature is used to control whether WS-Addressing is enabled or not. The MTOMFeature controls the use of MTOM and the
RespectBindingFeature is used to improve portability by forcing JAX-WS implementations to respect wsd:binding extensions. A JAX-WS 2.1 implementation may define its own features but they will be non-portable across all JAX-WS 2.1 implementations.
A JMS transport project for JAX-WS 2.1 has been added as a subproject of JAX-WS. This project contains a JMS plugin that can be used with JAX-WS 2.1. The project is open source and includes a runnable sample. Check it out!
If you are interested in developing a transport plugin for JAX-WS, please send an email to owner@jax-ws.dev.java.net.
Currently, JAX-WS does not support type substitution in cases where Java types are used at runtime that are not directly or indirectly referenced by the SEI. The reason for this is because you must specify all of the types that will be used at runtime at the time the JAXBContext is created. Since JAX-WS can only introspect the SEI there is no way to determine what other classes the developer may use at runtime. Take the following SEI for example.
@WebService
public interface MyEndpoint {
public Shape echo(Shape);
}
abtract class Shape {}
but the following classes are also used by the application:
class Square extends Shape;
class Circle extends Shape;
In the current JAX-WS implementation only the Shape class can be used.
We have the same problem when starting from WSDL and schema; only the schema types referenced by the wsdl:Port will be visible to the JAX-WS runtime.
In short, we need to solve two related problems:
How can we allow the Java application developer to specify additional classes that should be used by a JAX-WS application?
When importing a WSDL, how can we tell the JAX-WS and JAXB runtime that there are additional Java types available that are not referenced by the generated SEI?
JAX-WS 2.1 proposes the following solution:
JAXB 2.1 has already defined the following @XmlSeeAlso annotation.
package javax.xml.bind.annotations;
@Target({ElementType.TYPE})
public @interface XmlSeeAlso {
Class[] value();
}
This annotation will be allowed on any JAXB-bound type, and when JAXB binds that type, classes listed in @XmlSeeAlso will be also bound. So this can be used like this:
@XmlSeeAlso({Bar.class,Zot.class})
abstract class Foo {}
class Bar extends Foo {}
class Zot extends Foo {}
and "JAXBContext.newInstance(Foo.class)" will include all three classes. (Without @XmlSeeAlso annotation on Foo, JAXBContext.newInstance(Foo.class) will include only Foo.)
JAX-WS 2.1 will allow developers to place this annotation on a SEI.
JAX-WS will then read this annotation at runtime making sure to pass all
of the classes referenced by this annotation to the JAXBContext.
When importing a WSDL that contains types that are not directly
referenced by the endpoint definition, JAX-WS 2.1 will generate
@XmlSeeAlso annotation on the SEI. This @XmlSeeAlso annotation will
reference all of the ObjectFactories generated by JAXB. For example
@WebService
@XmlSeeAlso({package1.ObjectFactory.class, package2.ObjectFactory.class})
public interface MyEndpoint {
...
}
Technorati: JSR JCP JAX JAXWS Web Services Glassfish
With the announcement of JAX-WS 2.1 MR, it is apparent that versioning JAX-WS web service is important. As the 2.1 MR will add additional functionality and will potentialy introduce new annotations, it will become imperative that JAX-WS tools allow the web service developer to specify the target version of JAX-WS. The JAX-WS RI for example, will add targetVersion options to wsimport to control what code will be generated. The default value will be JAX-WS 2.1, but if the web service developer wants to target 2.0, he will be able to specify -targetVersion 2.0 to the wsimport command. By specifying the -targetVerion 2.0 option, then the generated code will run on a JAX-WS 2.0 implementations. Without specifying this option, 2.1 annotations might be generated making it impossible to run the application on a 2.0 implementation.
The question I would like to ask the community, is there a desire for a standard way to specify the targetVersion? For example, a customization could be defined for targetVersion. This would allow web service developers to specify this options in a standard way that would work across JAX-WS implementations.
Work has begun on the JAX-WS 2.1 Maintenance Release. I will be the JAX-WS 2.1 MR spec lead and Arun Gupta will co-lead. The main purpose of this MR is to add WS-Addressing capabilities to JAX-WS as Arun mentioned in his blog. Some other problems will also be addressed such as the type substitution problem that some JAX-WS developers have encountered.
You should be seeing an some development of the 2.1 version of the RI in the near future.
Technorati: JSR JCP JAX WSA JAXWS WSAddressing Web Services
You may be wondering how does this relate to JAX-WS. I am pleased to announce that JAX-WS is the core component to WSIT. In fact, WSIT is really a set of extensions to JAX-WS. To support the WS-* technologies that are part of WSIT better and to improve performance, the JAX-WS RI has been rearchitected. At this time I can tell you that the the first nightly build of the rearchicted RI is now available for download. This is a an EA version and there are still some JAX-WS 2.0 functionality that we have not ported to the new architecture. You can download this nightly from the RI download page. This nightly build does not include the WSIT (WS-*) technologies at this time but that download should be available in the weeks to come.
If you want to learn more about WSIT, please visit the
WSIT project on Java.net.
JAX-WS and WSIT is part of the Glassfish community.
We are pleased to announce that the JAX-WS 2.0 Final Realease of the reference implementation is finally available on java.net.
It has been a long haul to get to this point and the JAX-WS teams would like to thank everyone that kicked the tires and gave us valuable feedback to make JAX-WS a success.
John Yates wrote an great article on JAX-WS. He does a very good job of describing the architecture of JAX-WS and how to use JAX-WS. He shows how a Web Service and be published with JAX-WS and then creating a client for that Web Service. You can even download his code to try for yourself.
The JAX-RPC sources for Glassfish are now on Java.net. The JAX-RPC sources used to be hosted in the jax-rpc-sources project on java.net but the jax-rpc-sources repostitory was never used actively and the sources were rarely updated.
As of today, all JAX-RPC development will use the cvs repository under the JAX-RPC project on Java.net. The direct link to the sources is
here.
JAX-WS 2.0 has been open source on Java.net for nearly a year. The JAX-WS teams is looking for Content Developers and Contributors to make JAX-WS a better technology.
Content Developers can contribute content for the JAX-WS web site on Java.net. This content can be in the form of whitepapers, tech tips, FAQs or anything else one can think of to make using JAX-WS easier to understand.
Contributors can commit code patches for bugs.
Developers have CVS write access to the source repositories.
JAX-WS has simplified the development of Web Service clients when compared to JAX-RPC. Both technologies
have a tool for importing a WSDL to generate client
side artifacts. JAX-RPC's tool is wscompile, JAX-WS' tool is wsimport.
To use wscompile a config.xml file must be created to
pass to wscompile. A simple config.xml file would look something like:
This config.xml would import the WSDL located at http://localhost:8080/helloservice?wsdl"
and place the generated artifacts in the helloservice package.
You would then run wscompile with the following command-line:
wscompile -gen:client config.xml
To do the same thing with JAX-WS' wsimport
the command-line would be:
So with wsimport there is no need for the config.xml file.
The biggest advantage of JAX-WS clients over JAX-RPC clients is portability. JAX-WS generates 100% portable artifacts, while JAX-RPC generated artifacts are not all portable. Also, since JAX-WS is now included in Java SE 6 (Mustang), client applications are much smaller.
The EA3 version of JAX-WS or the JAX-WS released in JWSDP 2.0, supports the publishing and use RESTful Web Services. Here is an example that shows how to publish a RESTful Web Service using JAX-WS.
Publishing a RESTful Web Service with JAX-WS starts by creating an implementation of the javax.xml.ws.Provider<T> interface. The Provider interface is the dynamic alternative to a standard endpoint implementation class. It is analogous to the javax.xml.ws.Dispatch interface used on the client. You will notice that Provider<T> is a generic class. It can support Provider<javax.xml.transform.Source> and
Provider<javax.xml.soap.SOAPMessage> with the SOAP/HTTP binding, or Provider<javax.activation.DataSource> and
Provider<javax.xml.transform.Source> with XML/HTTP binding. When creating an
implementation of Provider you choose which form the requests and response messages will be processed by your implementation.
The example Web Service we are going to create is very simple, it will add two numbers and return the result ad we will use Provider<Source> for our Provider implementation and we will use the XML/HTTP binding.
The first step in writing a the AddNumbers Provider implementation is to declare the AddNumbers class.
public class AddNumbersImpl implements Provider {
}
The next step is to declare a @Resource annotation that will be used by the JAX-WS runtime to inject a WebServiceContext into our AddNumbersImpl instance.
public class AddNumbersImpl implements Provider {
@Resource
protected WebServiceContext wsContext;
}
The next step is to implement the T Provider.invoke(T request) method. To do this we will first declared the following method declaration which has a simple try-catch block to handle exceptions. Notice that this method takes a Source object as the request and returns a Source object as the response. This corresponds to the type of Provider that we created.
public class AddNumbersImpl implements Provider {
@Resource
protected WebServiceContext wsContext;
public Source invoke(Source request) {
try {
} catch(Exception e) {
e.printStackTrace();
throw new HTTPException(500);
}
}
}
For this example, the AddNumbers web service will accept requests by extracting the numbers to be added from either the the URL path or from an HTTP query. The query string and path string can be retrieved from the MessageContext which is retrieved from the WebServiceContext wsContext that will be injected into our AddNumbers object. The following code can be used to retrieve the PATH_INFO from the URL and check to see if it is in the proper format.
The createResultSource(String str) method simply creates a Source object from a properly formatted MessageContext.PATH_INFO string, by extracting the two numbers to be added from the path and adding them together and calling the createResultSource(int sum)method. The source for these two methods are:
private Source createResultSource(String str) {
StringTokenizer st = new StringTokenizer(str, "=&/");
String token = st.nextToken();
int number1 = Integer.parseInt(st.nextToken());
st.nextToken();
int number2 = Integer.parseInt(st.nextToken());
int sum = number1+number2;
return createResultSource(sum);
}
private Source createResultSource(int sum) {
String body =
"<ns:addNumbersResponse xmlns:ns=\"http://java.duke.org\"><ns:return>"
+sum
+"</ns:return></ns:addNumbersResponse>";
Source source = new StreamSource(
new ByteArrayInputStream(body.getBytes()));
return source;
}
So our example invoke method looks like the following.
public Source invoke(Source source) {
try {
MessageContext mc = wsContext.getMessageContext();
// check for a PATH_INFO request
String path = (String)mc.get(MessageContext.PATH_INFO);
if (path != null && path.contains("/num1") &&
path.contains("/num2")) {
return createResultSource(path);
}
throw new HTTPException(404);
} catch(Exception e) {
e.printStackTrace();
throw new HTTPException(500);
}
}
You will notice that if the proper MessageContext.PATH_INFO is not found, the example throws a HTTPException(404). Instead of throwing this exception, our example endpoint can instead check the query string for the method arguments. Like the MessageContext.PATH_INFO, the query string can be retrieved from the MessageContext with the following code.
Given this we can either pass the query string to the
createResultSource(String str) method which will parse the parameters from the query string or we
can use the standard ServletRequest object to extract the query arguments if we are deploying to a servlet container as we are for this example. If we were to deploy a Java SE based endpoint we would have to use the MessageContext.QUERY_STRING.
The following code extracts the num1 and num2 query values, adds them together and invokes the createResultSource(int sum) method to create the Source object that will be returned from the invoke method.
ServletRequest req = (ServletRequest)mc.get(MessageContext.SERVLET_REQUEST);
int num1 = Integer.parseInt(req.getParameter("num1"));
int num2 = Integer.parseInt(req.getParameter("num2"));
return createResultSource(num1+num2);
So far, our AddNumbers class looks like the following.
public class AddNumbersImpl implements Provider {
@Resource
protected WebServiceContext wsContext;
public Source invoke(Source source) {
try {
MessageContext mc = wsContext.getMessageContext();
// check for a PATH_INFO request
String path = (String)mc.get(MessageContext.PATH_INFO);
if (path != null && path.contains("/num1") &&
path.contains("/num2")) {
return createResultSource(path);
}
String query = (String)mc.get(MessageContext.QUERY_STRING);
System.out.println("Query String = "+query);
ServletRequest req = (ServletRequest)mc.get(MessageContext.SERVLET_REQUEST);
int num1 = Integer.parseInt(req.getParameter("num1"));
int num2 = Integer.parseInt(req.getParameter("num2"));
return createResultSource(num1+num2);
} catch(Exception e) {
e.printStackTrace();
throw new HTTPException(500);
}
}
private Source createResultSource(String str) {
StringTokenizer st = new StringTokenizer(str, "=&/");
String token = st.nextToken();
int number1 = Integer.parseInt(st.nextToken());
st.nextToken();
int number2 = Integer.parseInt(st.nextToken());
int sum = number1+number2;
return createResultSource(sum);
}
private Source createResultSource(int sum) {
String body =
"<ns:addNumbersResponse xmlns:ns=\"http://java.duke.org\"><ns:return>"
+sum
+"</ns:return></ns:addNumbersResponse>";
Source source = new StreamSource(
new ByteArrayInputStream(body.getBytes()));
return source;
}
}
To finish off the AddNumbers, we need to declare some annotions on the class that instruct the JAX-WS runtime how to use this class. The @WebServiceProvider annotation specifies that this class is a Provider based endpoint rather than a service endpoint implementation class that would be annotated with @WebService. The final annotation we add is @BindingType(value=HTTPBinding.HTTP_BINDING). This annotation specifies that AddNumbers endpoint should be published using the HTTPBinding.HTTP_BINDING as opposed to a
SOAPBinding.SOAP11HTTP_BINDING or a SOAPBinding.SOAP12HTTP_BINDING binding. The resulting class looks like the following.
@WebServiceProvider
@BindingType(value=HTTPBinding.HTTP_BINDING)
public class AddNumbersImpl implements Provider {
@Resource
protected WebServiceContext wsContext;
public Source invoke(Source source) {
try {
MessageContext mc = wsContext.getMessageContext();
// check for a PATH_INFO request
String path = (String)mc.get(MessageContext.PATH_INFO);
if (path != null && path.contains("/num1") &&
path.contains("/num2")) {
return createResultSource(path);
}
String query = (String)mc.get(MessageContext.QUERY_STRING);
System.out.println("Query String = "+query);
ServletRequest req = (ServletRequest)mc.get(MessageContext.SERVLET_REQUEST);
int num1 = Integer.parseInt(req.getParameter("num1"));
int num2 = Integer.parseInt(req.getParameter("num2"));
return createResultSource(num1+num2);
} catch(Exception e) {
e.printStackTrace();
throw new HTTPException(500);
}
}
private Source createResultSource(String str) {
StringTokenizer st = new StringTokenizer(str, "=&/");
String token = st.nextToken();
int number1 = Integer.parseInt(st.nextToken());
st.nextToken();
int number2 = Integer.parseInt(st.nextToken());
int sum = number1+number2;
return createResultSource(sum);
}
private Source createResultSource(int sum) {
String body =
"<ns:addNumbersResponse xmlns:ns=\"http://java.duke.org\"><ns:return>"
+sum
+"</ns:return></ns:addNumbersResponse>";
Source source = new StreamSource(
new ByteArrayInputStream(body.getBytes()));
return source;
}
}
To deploy our endpoint on a servlet container running with the JAX-WS RI we need to create a WAR file. For this example, we will name the WAR file jaxws-restful.war. The WAR file needs a very simple web.xml file to configure the JAX-WS RI servlet. The following will work.
You will notice in the web.xml and sun-jaxws.xml the presence of a
<url-pattern>/addnumbers/*</url-pattern> element
and a url-pattern="/addnumbers/*" attrbute,
these are specified so we can match any extra arguments that might be in the path (e.g. .../num1/10/num2/20).
You will also notice from the sun-jaxws.xml deployment descriptor that a wsdl file is specified. This is currently necessary to tell the JAX-WS RI not to try to generate a WSDL for this endpoint. The contents of AddNumbers.wsdl is simply the following.
Once the AddNumbers endpoint has been deployed, you can test it by entering the following URLs into a browser (slight modifications maybe necessary depending on your own configuration).
http://localhost:8080/jaxws-restful/addnumbers/num1/10/num2/20
Should return the following:
This is the release has been extensively tested and only a one known bug exists. Hopefully this will be the last early access release before the specification goes final, so this is your last chance to download JAX-WS and tell us what you think.
In this release new support for RESTful Web Services has been added. A simple restful sample application is included in the samples to show how a RESTful web service can be created and invoked.
For more information on JAX-WS, check out the JAX-WS project on java.net.
JAX-WS development issues discussed on dev mailing list
In an effort to be more open about the development of JAX-WS, discussions about changes to JAX-WS are now happening on dev@jax-ws.dev.java.net. Up until recently, such discussions had been going on internally within Sun.
We encourage those interested in participating in these discussions to join the mailing list.
To subscribe to the list, send a message to:
dev-subscribe@jax-ws.dev.java.net
Create a JAX-WS 2.0 Web Service and Client in Minutes
If any of you have wanted to try JAX-WS but are not sure
where to get started, this white paper gives you step-by-step instructions on configuring NetBeans to run JAX-WS and building a simple Web Service endpoint and a Web Service Client. The paper also tells you how you can debug both the server side Web Service and the client in NetBeans.
The wsimport tool of JAX-WS has added a -p option. This option is used to specify the package that the generated artifacts should be generated into. This option eliminates the need to write a customization to do the same task.
For example, two customization files to specify that the package for a WSDL would be similar to the following:
custSchema - customizes the package that generated artifacts from schema use.
<bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="http://localhost:8080/jaxws-external-customize/addnumbers?wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws">
<package name="external_customize.client"/>
</binding>
custWsdl - customizes the package that artifacts generated from the WSDL use.
<bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://java.sun.com/xml/ns/jaxb"
version="1.0">
<bindings schemaLocation="http://localhost:8080/jaxws-external-customize/addnumbers?xsd=1" node="/xsd:schema">
<schemaBindings>
<package name="external_customize.client"/>
</schemaBindings>
</bindings>
</bindings>
This would be passed to wsimport using the -b option:
For example: wsimport -b custSchema -b custWsdl http://localhost:8080/jaxws-external-customize/addnumbers?wsdl"
With the new -p option, the same thing can be accomplished with:
wsimport -p externa_customize.client http://localhost:8080/jaxws-external-customize/addnumbers?wsdl"
You can see a working sample code using both of these approaches in the external-customize and wsimport_catalog samples included in the nightly build of JAX-WS available here.
Sun plans to implement the WS-* specifications that will greatly improve interoperability with .Net and the Windows Communication Framework (WCF/Indigo). The implementation of these specifications will be built on top of JAX-WS.
You can read the press release from Sun about this at:
http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051104.1.html.
JAX-WS has been feature complete for a couple of months now and is becoming very stable. You can download the specification, APIs and JavaDocs for JAX-WS
here. You can download the nightly builds of the JAX-WS RI here.
A new JAX-WS project has been created on Java.net. This project is for the reference implementation of JSR 224 that Java API for XML Web Services.
Originally JAX-WS 2.0 was named JAX-RPC 2.0 and was part of the JAX-RPC Java.net project. Even after JAX-RPC 2.0 was renamed to JAX-WS 2.0 (see my blog) the two projects continued to share the JAX-RPC project. To clarify that these are in fact two seperate projects and to remove some confusion about them, we have created a JAX-WS project to focus solely on JAX-WS.
JAX-WS is the next generation standard for Java Web Services. It has significant advantages and improvements over JAX-RPC. One of the biggest wins for developers is that JAX-WS will be included in Mustang (Java SE 6). This means that writing JAX-WS clients will not add additional libraries to the client application. In addition to the features I mentioned in
my
JAX-WS 2.0 EA blog a number of other features are also included in the new feature complete implemenation.
These features include:
MTOM
SOAP 1.2
XML/HTTP
XML centric apis Dispatch and Provider
Java SE based Endpoints (no need for a servlet container for lightweight endpoints)
All of this and JAX-WS produces significantly smaller
applications than JAX-RPC.
The JAX-WS project can be found at http://jax-ws.dev.java.net.
The users@jax-ws.dev.java.net mailing list will be used to discuss issues related to JAX-WS. To subscribe to the list, send a message to:<users-subscribe@jax-ws.dev.java.net>
JAX-WS is an open source project with the CVS repository accessible from the JAX-WS project along with the API documentation, source and nightly builds of the JAX-WS source.
The JAX-WS 2.0 Proposed Final Draft (JSR 224) is now available on the JCP website JSR 224 PFD. It can also be viewed from the JAX-WS project on java.net under the specification link.
From this page you can also download the JavaDocs for the APIs as well as the source code.
The JAX-WS development team is proud to announce that JAX-WS 2.0 is now feature complete and the team has entered bug fixing mode. To obtain the highlest level of quality the team wishes to enlist all developers interested in Web Services to get the lastest JAX-WS bits and kick the tires. If you find issues with JAX-WS please let us know. You can provide feedback in the
JAXB 2.0 and JAX-WS 2.0 forum.
You can download weekly drops of JAX-WS here
JAX-WS 2.0 Generates up to 85% less code than JAX-RPC 1.1
To highlight the savings in generated code with JAX-WS 2.0 compared to JAX-RPC 1.1, I ran the WS-I Sample application WSDL files through JAX-RPC's wscompile and JAX-WS's wsimport. The results are very good.
JAX-RPC 1.1 generated 128 files that were 365KB in size.
JAX-WS 2.0 generated only 61 files for a total size of 83KB. That is a 52% reduction in the number of files generated and a 77% reduction in the size of the generated files.
You can download the early access 2 of JAX-WS 2.0 here. You can read the online documentation here.
JAXB 2.0 and JAX-RPC 2.0 forum renamed to JAXB 2.0 and JAX-WS 2.0
The JAXB 2.0 and JAX-RPC 2.0 java.net forum has been renamed to JAXB 2.0 and JAX-WS 2.0 to be consistent with the rename of JAX-RPC 2.0 to JAX-WS 2.0. To read about the JAX-RPC 2.0 rename to JAX-WS 2.0 read my blog entry here.
The JAXB and JAX-WS developement teams had worked very hard to release early access 2 of these technologies yesterday. Please download
JAXB 2.0 EA2 and JAX-WS 2.0 EA2 and tell us what you think using the JAXB 2.0 and JAX-WS 2.0 forum.
The JAX-WS 2.0 Public Review version of the specifcation has been posted
to the JCP and is open for review until 18 July 2005.
Please
download it and let us know what you think. You can send an email to: jsr224-spec-comments@sun.com, or post a message to the JAXB 2.0 and JAX-RPC 2.0 forum on java.net.
JAX-WS 2.0 Early Access 2 is now available. This version of JAX-WS provides support for SOAP 1.2, MTOM and Swaref. This is also the first implementation of a dynamic runtime that does not rely on non portable artifacts.
We have removed the wsdeploy tool since we no longer generated non portable artifacts. We have redefined the RI's deployment descriptor used on stand alone servlet containers (not a J2EE). With this deployment descriptor, a developer can create their own deployable WAR file that can be run on any JAX-WS enabled servlet container.
The JAX-WS 2.0 CVS repository is now active on java.net.
JAX-WS 2.0 was formerly known as JAX-RPC 2.0. For more information on this rename, please read my previous blog.
JAX-WS will now be fully developed using a CVS repository in the jax-ws-sources project. You can get access to this project and repository by going the the JAX-RPC project page and following the links under the Message from the owner(s) or click here.
Also with this change weekly binary builds of JAX-WS 2.0 will be available from the JAX-RPC project page.
JAX-RPC 2.0 (Java API for XML Based RPC) has been renamed to JAX-WS 2.0 (Java API for XML Web Services).
This was done for a number of reasons, but the main reasons are:
The JAX-RPC name is misleading, developers assume that all JAX-RPC is about is just RPC, not Web Services. By renaming JAX-RPC to JAX-WS we can eliminate this confusion.
JAX-RPC 2.0 uses JAXB for all databinding. This has introduced a number of source compatibility issues with JAX-RPC 1.1 because the bindings are different. The migration from JAX-RPC 1.1 to JAX-RPC 2.0 is not cookie cutter as generated Java code and schemas will be different than those generated by JAX-RPC 1.1. Although the renaming does not ease this migration, it does let the developer know that these are two separate technologies, hence the more difficult migration is more palatable.
Maintaining binary compatibility with the JAX-RPC 1.1 APIs, was hindering our goal of ease-of-development. Because we had this binary compatibility requirement, many legacy APIs were exposed such as the various methods on javax..xml.rpc.Service and the javax.xml.rpc.Call. Having these legacy APIs around would confuse developers. By renaming JAX-RPC 2.0 to JAX-WS 2.0 we no longer have this binary compatibility requirement and we can rid the APIs of these legacy methods and interfaces and we can focus on a new set of APIs that are easier to understand and use.
For more information on JAX-RPC and JAX-WS 2.0 check out the JAX-RPC project
For more information on JAXB check out the JAXB project
The JAX-RPC 2.0 SI has been re-architectured since 1.1. The new architecture will make it easier to add new capabilities in the future.
The new architecture allows for:
Multiple Transports
- EA currently supports HTTP
Multiple Encodings
- EA supports XML as text.
- The next EA will include MTOM/XOP and Fast Infoset
Multiple Protocols
- EA supports SOAP 1.1
- The next EA will include SOAP 1.2
The next EA due out before JavaOne will also have a dynamic runtime. This means no more stubs/ties,
serializers, deserializers etc. All artifacts generated
by the JAX-RPC SI will be 100% portable to other JAX-RPC
2.0 implementations. I will blog about this again when the next release is available.
Arun Gupta has blogged about how the current JAX-RPC 2.0
EA can be deployed ontop of JWSDP 1.5. You can read his blog at: JAX-RPC 2.0 EA on JWSDP 1.5
The JAX-RPC 2.0 Standard Implementation Early Access has just been released to the JAX-RPC project and you can download it here.
I would like to highlight some of the new features available in this release here.
JAXB data binding
JAXB 2.0 Early Access is also available. JAX-RPC 2.0 uses JAXB for all of its data binding. This means that much more of XML Schema can be handled compared to JAX-RPC 1.1. Although JAXB 2.0 has not completed bindings for all of XML Schema in this release, it will do so by FCS.
You can access the standalone early access of JAXB 2.0 at the JAXB Project on Java.net.
Metadata
Annotations from JSR 181 are used to allow customizations in the mapping from Java to WSDL. Many JAX-RPC 1.X users complained that the SI generated meaningless part names like: String_1. Now developers can customize these names using the WebParam annotation. Of course there are many more customizations available that allow the developer to control most of the mapping to WSDL. Here is an example of an annotated endpoint implementation class.
@WebService(targetNamespace="http://duke.org", name="AddNumbers")
@SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public class AddNumbers {
@WebMethod(operationName="add", action="urn:addNumbers")
@WebResult(name="return")
public int addNumbers(
@WebParam(name="num0")int number1,
@WebParam(name="num1")int number2) throws RemoteException, AddNumbersException {
if (number1 < 0 || number2 < 0) {
throw new AddNumbersException("Negative number cant be added!",
"Numbers: " + number1 + ", " + number2);
}
return number1 + number2;
}
}
JAXB 2.0 also defines a number of annotations that can be used to customize the mapping of Java types to XML Schema.
Customizations
Customizations allow the developer to customize the mapping from WSDL to Java. For those of you that are familiar with JAXB 1.0 customizations, JAX-RPC customizations will look familiar as they are model after JAXB customizations. In fact, you can embedded JAXB customizations within a JAX-RPC customization giving you the ability to customize both WSDL and XML Schema.
Improved Handler Framework
JAX-RPC 2.0 allows for the use of both logical and protocol handlers. Protocol handlers have access to the entire message, while logical handlers only have access to the payload of the message. So in the case of a SOAP message a protocol handler can access the entire SOAP envelope, while a logical handler will only have access to the contents of the SOAP body.
Handler chains can now be configured on a per-port, per-protocol, or per-service basis.
Dynamic Client
JAX-RPC 2.0 has added a new Dispatch interface. This interface is the follow on to the 1.1 Call interface. This inteface gives the developer much more control over what is sent over the wire in a web service invocation. It allows the client developers to with either java.lang.transform.Source, javax.xml.soap.SOAPMessage or a JAXB data bound object. The developer can also choose to work with the entire message or just the payload of the message.
Dynamic Server
The Provider interface is provided as a counter part to the Dispatch interface. It allows server developers the same choices as the Dispatch developers do when writing a client.
Asynchronous Clients
Asynchronous clients are now supported on both stubs and the new Dispatch interface. Clients can choose between polling or callback techniques. For example, a standard invocation of a addNumbers operation on a stub would look like:
private void invokeSynchronous() throws RemoteException{
int number1 = 10;
int number2 = 20;
System.out.println("\nInvoking synchronous addNumber():");
int result = port.addNumbers(number1, number2);
System.out.printf("The result of adding %d and %d is %d\n", number1, number2, result);
}
Here is the same operation invoke asynchronously using polling.
private void invokeAsyncPoll() throws InterruptedException, ExecutionException{
int number1 = 10;
int number2 = 20;
System.out.println("\nInvoking Asynchronous Polling addNumbersAsync():");
javax.xml.rpc.Response resp = port.addNumbersAsync(number1, number2);
Thread.sleep(2000);
AddNumbersResponse output = resp.get();
System.out.printf("The result of adding %d and %d is %d\n", number1, number2, output.getReturn());
}
And here it is using the the callback mechanism.
private void invokeAsyncCallback() throws InterruptedException{
int number1 = 10;
int number2 = 20;
System.out.println("\nInvoking Asynchronous Callback addNumbersAsync():");
AddNumbersCallbackHandler callbackHandler = new AddNumbersCallbackHandler();
Future response = port.addNumbersAsync(number1, number2, callbackHandler);
Thread.sleep(2000);
AddNumbersResponse output = callbackHandler.getResponse();
System.out.printf("The result of adding %d and %d is %d\n", number1, number2, output.getReturn());
}
java.net RSS Feeds
