Originally posted by Naren Chivukula:
1. Can we still rely on J2SDK1.4.2 to work on the J2EE Web Services?
If a platform is J2EE 1.4 certified it has to have at least support Java 2 1.4 and JAX-RPC 1.1. So JAX-RPC 1.1 has to work in a Java 2 1.4 environment.
JAX-WS on the other hand requires Java SE 5.
That being said, the
Sun Java System Application Server PE 8.2 actually uses the 1.5 JVM which is how it can support the
JWSDP 2.0.
2. Is there any relationship between the usage of JWSDP2.0 with J2EE1.4?
You cannot use the JWSDP 2.0 in a strict J2EE 1.4 environment. JWSDP 1.6 was the last one that only needed the 1.4.2 JVM (though it was never sanctioned for production use anyway).
It seems that Sun has withdrawn the complete JWSDP 1.6 download. However the documentation lists the
components of the JWSDP 1.6.
You should be able to find these parts separately on dev.java.net. Examples:
JAX-RPC 1.1 source JAXB 1.0.x
3. What are the advantages of JAX-WS over JAX-RPC? Can JAX-WS fulfil all the programming concepts that we typically do using JAX-RPC?
As the name implies JAX-RPC was primarily focused on using web service interfaces as a remote procedure call protocol (which is a paradigm easily understood by programmers) - even though there is some support for document-orientation (which is immediately undermined by JAX-RPC tools that try to turn these documents automatically into java objects and methods - some concerted effort is required to build document-oriented web services with JAX-RPC
properly - see
Strategy: Integration with JAXB). Basically JAX-RPC was recognized as being fragile and overly complicated for what it does (See:
RMH: JAX-RPC is Bad, Bad, Bad!).
So first the name had to change: JAX-WS (Web services. RPC is gone - from the name at least). IIRC JAX-WS doesn't support the dreaded RPC/encoded messaging style that usually is implemented with the
Section 5 SOAP Encoding. Good riddance, as that was an interoperability nightmare anyway.
However JAX-WS introduced web service annotations which was often cited as the biggest improvement. In fact this reinforced RPC-thinking in the specification. Microsoft had introduced web service attributes with the first .NET version of Visual Studio and BEA was pressing hard to get something equivalent into the Java specifications. They are popular because they give the developer the illusion that they can happily design/specify service-oriented artifacts in the object-oriented domain - and hopefully save them from the burden of learning all about, XML, XML-Schema and WSDL because the
service interface and contract are automatically derived from the Java artifacts. In practice this usually creates service interfaces and contracts that are not as clear as they could be for other third party tools and developers using other platforms. This also completely ignores the fact that you need to design your service interaction separately from any object model that may be present inside the services and clients. The object models may be different or there may not even be an object model. Just as you design an object model for your application, you need to design a services-model on the next higher level - you can't simply imply it from the lower level.
JSR 181: Web Services Metadata for the JavaTM Platform JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.0 This is why web service annotations are being called
web service magic pixie dust. (Now annotations that contain hints on how to bind to an
existing contract - that might be genuinely helpful.)
So in a way JAX-WS still doesn't "get it".
RMH: JAX-WS is Bad, Bad! RMH: Redeemed! JAX-WS still sucks! All in all the RPC mindset needs to be broken; SOAP based web services will be around for a while but most of the ones that will stick around will be documented-oriented. One big feature of document-oriented:
there is no method/operation name in the SOAP message. Basically the document is submitted to the endpoint and that is it. The endpoint has to figure out what to do with the document either based on the document type or the document content; there is no method to give it a "hint".
Then of course there is the fact that the use of SOAP is in fact total overkill for many applications.
RMH: WS* vs. REST / Intelligence vs. Wisdom Tim Ewald: I finally get REST. Wow. JAX-WS acknowledges that by including a way to build REST web services (Example:
Publishing a RESTful Web Service with JAX-WS). However once again it seems overly complicated and elaborate (an
enterprise edition syndrome). If you are going with REST you are probably better of with something like
Restlet.