Wednesday, May 6, 2009


Java API for XML-Based RPC (JAX-RPC) is a Legacy Web Services Java API, it uses SOAP and HTTP to do RPCs over the network and enables building of Web services and Web applications based on the SOAP 1.1 specification, Java SE 1.4 or lower, or when rpc/encoded style must be used.

You can use the JAX-RPC programming model to develop SOAP-based web service clients and endpoints. JAX-RPC enables clients to invoke web services developed across heterogeneous platforms. Likewise, JAX-RPC web service endpoints can be invoked by heterogeneous clients. JAX-RPC requires SOAP and WSDL standards for this cross-platform interoperability.

JAX-RPC lets people develop a web service endpoint using either a Servlet or Enterprise JavaBeans (EJB) component model. The endpoint is then deployed on either the Web or EJB container, based on the corresponding component model. Endpoints are described using a Web Services Description Language (WSDL) document.(This WSDL document can be published in a public or private registry, though this is not required). A client then uses this WSDL document and invokes the web service endpoint.

JAX-RPC in J2ee 1.4 supports 4 types of stubs and invocations: static stub, dynamic proxy, Dynamic Invocation Interface (DII) and Application client.

Static Stub Client
Web service client makes a call through a stub, a local object that acts as a proxy for the remote service. Because the stub is created by wscompile at development time (as opposed to runtime), it is usually called a static stub.

Example: Invoking a Stub Client
Stub stub = (Stub) (new MyHelloService_Impl().getHelloIFPort());
stub._setProperty (javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,endpoint_address_string);
HelloIF hello = (HelloIF)stub;

Dynamic Proxy Client
In contrast, the client call a remote procedure through a dynamic proxy, a class that is created during runtime. Although the source code for the static stub client relies on an implementation-specific class, the code for the dynamic proxy client does not have this limitation.

Example: Dynamic Proxy
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);
com.example.StockQuoteProvider sqp = (com.example.StockQuoteProvider)service.getPort(portName, StockQuoteProvider.class);
float price = sqp.getLastTradePrice("ACME");

Dynamic Invocation Interface Client
With the dynamic invocation interface (DII), a client can call a remote procedure even if the signature of the remote procedure or the name of the service is unknown until runtime. In contrast to a static stub or dynamic proxy client, a DII client does not require runtime classes generated by wscompile.

Example: Dynamic Invocation Interface
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);
javax.xml.rpc.Call call = service.createCall(portName, "getLastTradePrice");
// This example assumes that addParameter and setReturnType methods are not required to be called
Object[] inParams = new Object[] {"ACME"};
Float quotePrice = (Float)call.invoke(inParams);

Application Client
Unlike the stand-alone clients, for an application client, because it's a J2EE component, an application client can locate a local web service by invoking the JNDI lookup method.

Example: Application Client
Context ic = new InitialContext();
MyHelloService myHelloService = (MyHelloService)
appclient.HelloIF helloPort = myHelloService.getHelloIFPort();

Service Endpoint Model
JAX-RPC supports a client model for the service consumer, and a service endpoint model for the service producer.

Application-Level Interaction Modes
JAX-RPC specifies three client application interaction models:
* Synchronous request-response two-way RPC
* Asynchronous (non-blocking) request-response two-way RPC
* One-way RPC


JAX-WS 2.0 is the successor of JAX-RPC 1.1 - the Java API for XML-based Web services. If possible, JAX-WS should be used instead as it is based on the most recent industry standards.

What remains the same?

Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same.

* JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire.

* JAX-WS still supports WSDL 1.1, so what you've learned about that specification is still useful. A WSDL 2.0 specification is nearing completion, but it was still in the works at the time that JAX-WS 2.0 was finalized.

What is different?

* SOAP 1.2
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.

* WS-I's Basic Profiles
JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the Web services interoperability organization.)

* New Java features
o JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
o Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's Web services novices.

* The data mapping model
o JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
o JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.

* The interface mapping model
JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
o JAX-WS's model makes use of new Java 5.0 features.
o JAX-WS's model introduces asynchronous functionality.

* The dynamic programming model
o JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
+ It introduces message-oriented functionality.
+ It introduces dynamic asynchronous functionality.
o JAX-WS also adds a dynamic server model, which JAX-RPC does not have.

* MTOM (Message Transmission Optimization Mechanism)
JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.

* The handler model
o The handler model has changed quite a bit from JAX-RPC to JAX-WS.
o JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.

Reference Origination Link:

Friday, May 1, 2009

Web-based Chating using Java Script and XMPP like gtalk

Every body will be familiar with gtalk chatting in web browser. This blog will give you a brief idea of how to implement the same with open source proven solutions.

Google, yahoo or any chatting provider will use the xmpp to implement chat application. The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.

Before starting chat implementation need to install jabber server. You can select any jabber server from link. I prefer Wildfire. Go with eJabberd if you want to support more number of chat users.

Next step download JSJaC - JavaScript Jabber/XMPP Client Library from link. Extract the archive once you download it.

Now you require a mediator application which will establish a communication channel between your jabber server and web application with javascript. That is your Jabber Http Bind (jhb) servlet. Download jhb servlet web application from link. The installed jabber server will listen on some specific port for http binding. This url can be accessed using http. But ajax can’t make cross domain communication. So you supposed to post the data to jhb servlet, then jhb intern post to your jabber server. Here you no need to change any code in jhb servlet. Jhb servlet will automatically detect your jabber server settings form requests you make.

Once all the above three are in place, open simpleclient.html from examples folder. In some browsers it will not work directly. So host the complete jsjac as a web application and then open simplechat.html. Provide below information in simplechat form.

Select HTTP Binding as Backend Type.

HTTP Base will be your JHB servlet path (ex: http://localhost:8080/JabberHTTPBind/jhb )
make sure this path will point to your jhb servlet. If every this configured propery then you will get below message once you access jhb url in browser

Jabber HTTP Binding Servlet v1.1.1
This is an implementation of JEP-0124 (HTTP-Binding). Please see for details.
Active sessions: 0

Jabber Server will be localhost or any ip address of the system on which you installed jabber server

If you are login into first time then give any username and password and check register new account check box and click on login.

Open another simpleclient.html and add another user account by repeating the above steps.

Use the usernames that you provided while user creation to start chat.

You can able to send and receive message using both user accounts. Enjoy the chatting… ;)
If you face any difficulty while configuration post your comments here

Differences between SAX and DOM parsers

Both SAX and DOM are used to parse the XML Document. Both has advantages and disadvantages and can be used in our programming depending on the situation


1. Parses node by node

2. Doesnt store the XML in memory

3. We cant insert or delete a node

4. Top to bottom traversing


1. Stores the entire XML document into memory before processing

2. Occupies more memory

3. We can insert or delete nodes

4. Traverse in any direction.

If we need to find a node and doesnt need to insert or delete we can go with SAX itself otherwise DOM provided we have more memory.

Render Webpage using XML and XSLT

Check your web applicaiton html content, you will find max of your data will be dynamic. You might be rendering the complete html on server. This will introduce load on your server and consume cpu time.
If you transform your data at client side then the size of data that to be sent to client browser will be less. Use below code snippet to transform xml and xslt at client site

<title>Web page using XML and XSLT</title>
<style>@import url("yourstylesheet.css");</style>
<script type="text/javascript">
var returnval = 0;
var stylesheet, xmlFile, cache, doc;
function init(){
// NSCP 7.1+ / Mozilla 1.4.1+
// Use the standard DOM Level 2 technique, if it is supported
if (document.implementation && document.implementation.createDocument) {

xmlFile = document.implementation.createDocument("", "", null);
stylesheet = document.implementation.createDocument("", "", null);

xmlFile.addEventListener("load", transform, false);
stylesheet.addEventListener("load", transform, false);
//IE 6.0+ solution
else if (window.ActiveXObject) {

xmlFile = new ActiveXObject("msxml2.DOMDocument.3.0");
xmlFile.async = false;
stylesheet = new ActiveXObject("msxml2.FreeThreadedDOMDocument.3.0");

stylesheet.async = false;
cache = new ActiveXObject("msxml2.XSLTemplate.3.0");
cache.stylesheet = stylesheet;

// separate transformation function for IE 6.0+
function transformData(){
var processor = cache.createProcessor();
processor.input = xmlFile;
data.innerHTML = processor.output;

// separate transformation function for NSCP 7.1+ and Mozilla 1.4.1+
function transform(){
if (returnval==2){
var processor = new XSLTProcessor();

doc = processor.transformToDocument(xmlFile);
document.getElementById("data").innerHTML = doc.documentElement.innerHTML;
<body onload="init();">
<div id="data"><!-- this is where the transformed data goes --></div>