Changshin Lee's Blog

Web Services and XML Archives

JWS 2.1 vs JWS 2.0

JWS (Java Web Services) 2.1 updates JAXB and JAX-WS to 2.1 and adds WSIT to its basic layer. Now JWS 2.1 is supported by GlassFish v2 while JWS 2.0 is built in JDK 6.

One typical issue is definitely how to use JWS 2.1 on JDK 6. It's well known that you can rely on Standard Endorsed Mechanism provided by Java SE, how about updating JWS from 2.0 to 2.1 for JDK 6u1? Comparing with WCF from .NET Framework 3.0, JDK 6 doesn't support WS-* by default. JDK 7 may be a solution, but it will take long.

Web Services 2.0

After introducing "Java Web Services 2.0" at http://weblogs.java.net/blog/iasandcb/archive/2006/03/java_web_servic.html, I made up my mind to broaden the notion :-)

First of all, I felt I had to revise JWS 2.0 because JAX-WS 2.1 and WSIT came up. JWS 2.0 is a set of:

SAAJ 1.3
JAXB 2.1 + JAX-WS 2.1
WSIT

Secondly, .NET Web Services 2.0 is WCF in .NET framework 3.0. Thirdly, Interoperability 2.0 is shown by Sun and Microsoft via WSIT and WCF.

Finally, Web Services 2.0 is a combination of:

JWS 2.0
NWS 2.0
Interop 2.0

OK, as Vista and Mustang (Java SE 6) comes into the final stage, we will be happily able to enjoy WS 2.0 with MTOM, WS-*, and ease of development and use.

The first adoption of "Java Web Services 2.0"

While reading NetBeans 5.5 Beta 2 Release Information at http://www.netbeans.org/community/releases/55/index.html, I found that (Java) Web Services 2.0 was used to introduce JAX-WS.

Although the line left "Java" out, I felt really glad to see the term as I suggested at my previous blog at http://weblogs.java.net/blog/iasandcb/archive/2006/03/java_web_servic.html. Of course, I hope Java Web Services 2.0 would be widely adopted with the brand-new name ;-)

Truth about "format-pretty-output"

I got so much feedback from my recent blog at http://weblogs.java.net/blog/iasandcb/archive/2006/06/serializing_xml.html, and it inspired me to write another.

The most noticeable comment on the blog is to use JAXP transformer to serialize Document, and in fact I couldn't agree on the solution more because I also used it.

Apart from its standard feature, transformer gives you one more nice option: make your Document more human-readable with so-called "pretty-output". The option is so popular that it is almost essential when the output should be seen by a human being, not a machine.

Transformer is basically designed to visualize abstract XML infosets, so it is no wonder to have a diversity of presentations. Even though we do canonicalization on occasion, some want 2 spaces for indentation, and some want no self-closing tags, and so on.

That strength really works for serialization of Document. On the other hand, DOM L3 LSSerializer also supports "format-pretty-output", but unfortunately you can't expect it from JAXP RI, which is also built in Java SE 5 and 6. There's an issue posted for the problem and a possible solution at https://jaxp.dev.java.net/issues/show_bug.cgi?id=6. The patch was actually applied to Apache Xerces, so the option is supported by Xerces 2.8.0.

To sum them up, Transformer can be your friend if you like to control your outputs in details. In addition to that, it's worthwhile considering taking advantage of brevity from LSSerializer.

Serializing XML, not printing XML

Suppose you have an org.w3c.dom.Document instance to output, for example, to a web browser screen or just simply on a Console, then hmm... unfortunately, we used to have no standard way within DOM API (used, not now).

Even though we can take advantage of DOM L3 Load/Save from JAXP 1.3, it doesn't mean that everybody is happy with that mainly because JAXP 1.3 is fairly new and you might have no choice but to stick to JAXP 1.2 and earlier.

One fine day, I encountered an outstanding snippet of code:

System.out.println(doc);

where doc is of Document.

And the result? Yes! it works!

...

OK, then can we generalize this? Again unfortunately, in this case Document.toString() method implementation is overriden but Document API doesn't require so. In other words, behaviors of Document.toString() vary from implementation to implementation, so you can't expect it to work always.

Therefore, I'd like to recommend two things:

1. Use the DOM L3 Save feature as long as you can.
If you use JDK 5 and later, you don't have to pay a penny for that. If you need to use JDK 4 and earlier, consider that your system is able to allow you to endorse the new JAXP set.

Here's a short example of how-to.

DOMImplementation implementation= DOMImplementationRegistry.newInstance()
.getDOMImplementation("XML 3.0");
DOMImplementationLS feature = (DOMImplementationLS) implementation.getFeature("LS",
"3.0");
LSSerializer serializer = feature.createLSSerializer();
LSOutput output = feature.createLSOutput();
output.setByteStream(System.out);
serializer.write(doc, output);

2. If your situation is inevitable, choose XMLSerializer in Xerces without depending on Document.toString(). Although it's not a standard approach, it has been working since its inception for many XML guys :-)

Here's also a short example of how-to.

XMLSerializer serializer = new XMLSerializer();
serializer.setOutputByteStream(System.out);
serializer.serialize(doc);

3. I got valuable input from commentators. It's very coincidental that I just recognized that I used the same method as them :-)

TransformerFactory transformerFactory = TransformerFactory
.newInstance();
Transformer transformer = transformerFactory.newTransformer();
transformer.setOutputProperty("indent", "yes");
transformer.transform(new DOMSource(node), new StreamResult(System.out));

#1 and #3 uses JAXP API, so if you're concerned about portability of your code, those choices can help you.

JAXB 2.0 TCK

You can download it from https://jaxb.dev.java.net/tck.html . It's still beta, but I hope we can see a final version as JAXB 2.0 spec and RI is also finalized (very soon).

Terms in JWS 2.0 - PAWSDL vs PUWSDL and GISC vs GASC

EWS 1.2 introduces two types of WSDL:

PAckaged WSDL - PAWSDL (paw sdle): WSDL files packaged in a module.
PUblished WSDL - PUWSDL (poo sdle): WSDL files published during deployment.

While JAX-RPC uses interface (java.xml.rpc.Service) for clients, JAX-WS uses class:

GenerIc Service Class - GISC (g sc): javax.xml.ws.Service
GenerAted Service Class - GASC (gas c): generated service classes extending javax.xml.ws.Service

Let's talk about JWS with some efficiency :-)

JWS ME 2.0

While I introduced the term JWS (Java Web Services) 2.0, I realized that the same notion can be applied to Java ME, i.e. JWS ME 2.0:

JWS ME 1.0

JSR 172 J2ME Web Services

JWS ME 2.0

JSR 279 Service Connection API for Java ME
JSR 280 XML API for Java ME

Mirae means "future", but Apache Mirae means "now"

I just posted a snapshot of Apache Mirae 1.0 to http://people.apache.org/~ias/mirae/ . "Mirae" in Korean means "future" and I used the word to name a project for implementing JSR 172 J2ME Web Services in Apache.

The project launched two years ago, but has gone through many things: lack of participation (and use as well), TCK delivery, and holes of JSR 172, and so on. However, around the beginning of this year, I got quite stimulating responses from both developers and users of Mirae and finally feel ready to release its very first version.

Open source software targeted at Java ME has narrower playground than the other platforms mainly because the platform itself is sort fo "closed", or rather tightly controlled by telco carriers and phone vendors. For example, java.* and javax.* are not permitted to install by users on some devices, which prevents from using Mirae WS(Web Services, an implementation of JSR 172 JAX-RPC subset).

Knowing this irresistible situation, we still (and ever) want our devices to be connected based on a notation called "service oriented architecture", and JSR 279 Service Connection API for Java ME and JSR 280 XML API for Java ME shed light here. Even as an implementor of JSR 172, the JAX-RPC subset was pretty disappointing, especially when it came to real usages.

What I'd like to lead through Mirae is to let people make full use of their daily information devices. That's the future.

NGWeb2006 - Introducing Ajax and Widgets

My first entry in java.net weblogs

Finally! I have written stuffs about Java on http://www.iasandcb.pe.kr/blog/, but felt that java.net would be a better place to share them. My short bio can tell you roughly who I am, so before posting serious entries, I'd like to introduce myself with a bit more details.

Currently I'm working for TmaxSoft, the biggest middleware company in Korea, and responsible for implementing web services of Java EE 5 for JEUS, a web application server from Tmax. Therefore, I usually play with JAX-RPC 1.1, JAX-WS 2.0, SAAJ 1.3, WSM (JSR 181) 1.1, and EWS (JSR 109) 1.2 :-)

Some might notice my name (or alias, Ias) because Eduardo mentioned about me at his blogs regarding GlassFish and Fast Infoset. However, I started my open source involvement in Apache and am still leading Apache Mirae project for Java mobile web services.

I'll write about Java, particularly web services in general and mobile. At last, I'd like to thank Eduardo for having led me to have such a great opportunity of being a weblogger in java.net.

This work is licensed under a Creative Commons License.