I tried today working in JDK 1.6 and to my surprise I found out that it comes shipped in with web services utilities which include JAX-WS 2.0, JAXB 2.0, JAXP2.0. This means a lot of ease in the development of web services for the developer. The benefits are:

1. There is no need to separately download the JWSDP 2.0 as I had mentioned in my tutorial
2. There is no need to remember all the different set of libraries which are required to be included in the classpath before your program has to run.
3. It eases out the development and saves your time.

Does that mean there are no Issues?

There are some. The stubs generated in the manner, I had mentioned in the tutorial won’t work if you are working in Java 6. Because I got an error when I had opened the project Eclipse after installing JDK 1.6 which stated,

java.lang.IllegalArgumentException: Expected class javax.xml.bind.annotation.XmlAccessType but found class javax.xml.bind.annotation.AccessType

In order to solve this error you have to generate your stubs once again with the same command i.e wsimport but in this case you should not use the wsimport.bat which comes in JWSDP 2.0. On the contrary you have to use wsimport.exe which is found in <JAVA_HOME>/bin where JAVA_HOME is the installation directory for JDK 1.6. For example in my case it was,

C:\Program Files\Java\jdk1.6.0_02\bin\wsimport.exe

You have to remember that JAX-WS which gets shipped with JDK 1.6 is of version 2.0. The latest offering is however JAX-WS 2.1.2 which is a part of Project Metro for GlassFish. I tried working in JAX-WS 2.1.2 but currently I think there are a lot of compatibility issues in the latest version with JDK 1.6 because I was not able to create the client in 2.1.2 in the same manner.

But I am happy to see my JDK 1.6 making my work easier. Hope to see more such nice features in the future.

Related posts:

• BEA Aqualogic Data Services Platform – First Glimpse
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• SCDJWS – mission accomplished
• Key Points for Choosing the Best framework
• XP Installation – The 34 minute hiccup

• JWSDP 2.0 pack
• JDK 1.5 or above
• The required Web Service WSDL
• Eclipse 3.1 or above

The procedure for creating the client have been broken down into 3 easy steps which are:

1. Creating the Stubs from WSDL
2. Building the Web Service Client using JAX-WS
3. Parsing the Output using JAXP

JAXWS & JAXP

JAX-WS is an API for creating as well as invoking web services. It succeeds the JAX RPC API and makes it easier by reducing the XML configurations, through the use of annotations available in Java 5. However you don’t need annotations for this tutorial.

JAXP is a wrapper API over the legacy XML parsing API’s such as DOM and SAX and leverages their usage through its generic interfaces. JAXP is typically used in a web service which is implemented with a Document Literal style. This is because such web services return an XML document and not a simple String Value. The XML Document then has to be parsed using the JAXP API.

So let us begin with the tutorial.

1. Creating the Stubs from WSDL

For this tutorial, I am going to use the Stock Quote Service available at webservicex.net. The web service demo shows you an XML document being returned when you enter in a stock ticker in the text box provided. The client which you will create in JAX-WS will invoke the GetQuote service and receive the same document which we will then parse using JAXP.

In order to invoke the GetQuote service you first need to have the stubs. The stubs can be created easily using the import.bat utility provided in the JWSDP pack. The path where you can find this utility is <JWSDP_HOME>/jaxws/bin. For using this utility you must set the JAXWS_HOME environment variable which points to the JAX-WS directory. For example I have set mine as:

C:\tomcat50-jwsdp\jaxws

Open the command prompt and go the path <JWSDP_HOME>/jaxws/bin. Use the WSDL path of the GetQuote Web Service and type in the following command,

C:\tomcat50-jwsdp\jaxws\bin>wsimport -s . http://www.webservicex.net/stockquote.
asmx?WSDL

This command generates the stubs which are required for invoking the web service, in the current directory. The -s switch is to generate source code of the stubs. We need to use these generated classes in the client.

Now open Eclipse and make a new Java Project. Name it whatever you like. Next, import all the above generated classes into the project. Remember all the classes have to be in the same package as they were generated i.e net.webservicex

2. Building the Web Service Client using JAX-WS

Create a package com.ws.client where we will place our client code. Make a Java Class called StockQuoteClient. You would now have to import a large set of JAR’s which would be required for running the client. The JAR’s which are needed are:

• jaxws-api.jar, jaxws-rt.jar, jsr181-api.jar present in jaxws/lib
• jaxb-api.jar, jaxb-impl.jar present in jaxb/lib
• saaj-api.jar, saaj-impl.jar present in saaj/lib
• resolver.jar, activation.jar present in jwsdp-shared/lib
• jsr173_api.jar, sjsxp.jar present in sjsxp/lib
• jaxp-api.jar present in jaxp/lib

That’s too much indeed! But trust me, you wouldn’t have your web service client running without these libraries. Now write the following code inside the main method of StockQuoteClient

 StockQuote service = new StockQuote();
 StockQuoteSoap port = service.getStockQuoteSoap();
 String quote = port.getQuote("INFY");	
 System.out.println(quote);

The code is simple. You first create a service instance of StockQuote. Then you get the port on which you want the function to be invoked. Here I have invoked the StockQuoteSoap port.

Once you get the port you are ready to invoke the service which is done by calling port.getQuote(“INFY”) where INFY is the stock ticker symbol for the company INFOSYS.

Now run this program as a Java Application in Eclipse. You would see a long running line of XML returned as a string which contains the details related to INFY stock.

3. Parsing the Output using JAXP

The returned XML output is undesirable since it cannot be read out easily. So now we have to use some API which would easily help us to get the required details in a nice and clean manner. This is where we would use JAXP. Now instead of printing out the output as it is, make a function parseQuote with which we will parse the XML returned. For this, in the main method, change

System.out.println(quote);

to

List<String> items = new ArrayList<String>();
items.add("Last");
items.add("Date");
items.add("Time");
items.add("Change");
 
parseQuote(quote, items);

You may be wondering what the List of items is used for. Well, instead of making the method for displaying all the information contained within the XML fragment, we would create the method more nicer, which will only display the contents of the tags actually needed. Hence we pass the tag names in a List as a second argument.

 
public static void parseQuote(String quote, List<String> items) throws Exception{	
	}

Its been made static so as to access it directly. You can either throw an Exception from the method or implement a try-catch inside the method. Use the below code inside the parseQuote method.

 
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(false);
DocumentBuilder builder = factory.newDocumentBuilder();

In the code DocumentBuilderFactory and DocumentBuilder instances are used to get hold the document which we want to parse. The document is nothing but the XML output stored in the quote object. But in order to read the string, we would require to use it as

Document document = builder.parse(new InputSource(new StringReader(quote)))

and not directly. If used directly you would get a java.net.MalformedURLException exception. After getting a hold of the document we use a for in loop to check which items are required to be displayed.

for(String content:items){
	NodeList list = document.getElementsByTagName(content);
	Node item = list.item(0);
	System.out.println(content + " : " + item.getTextContent());	
}

The function to look out for is getElementsByTagName() which itself finds the tag names and gives the content within them. Remember for using this function, the tag name provided, must be any leaf element or else you would get a javax.xml.stream.XMLStreamException error.

Final Words

This is a very basic way in which you can build a web service client using JAX-WS and JAXP. The tutorial is aimed for getting started with these two API’s together. Further down from here, you can begin exploring in depth the wonderful features that these API’s provide.

You can copy paste the entire code provided here and use directly in your application.

Related posts:

• Working With JAX-WS in JDK 1.6
• SCDJWS preparation – a kick start guide
• Ajax Frameworks – Server side versus Client side
• SCDJWS – mission accomplished
• Eclipse Europa Has Ruined My Day

Annotations – a boon or a curse?
Due to the above situation, the influence on the usage of annotations is steadily rising. It is but natural that programmers would try to do their work quickly without having to waste the time in learning the XML Schema’s required for deployment. Annotations are purposely aimed at this programmer’s dilemma. In fact when I was working in JAX RPC, I used to think as to when I would get a tool to code those ugly descriptors in an easier fashion. With annotation based web services creation in JAX-WS, half of my work is done when I put them in the POJO itself.

All of this can be attributed as a boon to the presence of annotations. But the point of worry is, whether all those annotations which are pushed in the POJO to do work in an easier manner are really worthwhile? What has happened to the age old technique wherein a POJO by nature would remain a POJO such that it could be used wherever required without having to change the code in future.

Degradation of POJO’s
You have to remember that the ugly deployment descriptors which we swear at are the actual components in an application which give us the power of code flexibility and code reuse. They are here to make changes and configurations during runtime without having to touch the class files. But with the presence of annotations I fear that people would become slaves to them and all of the configuration code would be pushed into the POJO’s.

According to the POJO definition, a POJO doesn’t remain a POJO anymore, once it relies on any kind of API or framework which makes it dependent on an environment other than the JVM. According to Wikipedia, a POJO should not have to,

1. extend prespecified classes
2. implement prespecified interfaces
3. contain prespecified annotations

An annotation may not change a POJO’s behavior but it makes it dependent on the environment. If you try to compile a POJO in your JVM it won’t get compiled. This is because an annotation also requires an environment to get translated into its specific configuration file. So the question is how would you attribute a normal POJO behavior to the one with annotations. They are not the same.

The problem in using Annotations
A framework which makes use of the normal POJO without changing them would be a truly flexible framework. If we try to compare EJB 3.0 with the Spring framework we would immediately come to know the difference. In EJB 3.0 you declare a bean with an annotation in a POJO whereas in a Spring framework an XML file is used for weaving the POJO’s to make a flow control or give them special functionalities.

Nathan has stated in his tech blog,

In conclusion, annotated objects, for the simple reason that you can’t compile them without needing external resources, are not truly “Plain Ordinary Java Objects.” They have been made un-plain and un-ordinary by their annotations.

This is the same point that I am trying to make through the above comparison that annotations might be great but they make a dependency in your POJO functionalities. The rule of thumb in the application development domain is to always keep the business functionality away from the technicalities of the framework or any of the 3rd party API’s. And annotations do the exact opposite. How can one guarantee that the annotated POJO’s would be useful in another container which does not have the annotation related classes?

A cause for worry
Even though the above problem exists we cannot give away with annotations, because we don’t have time time enough to learn the humongous amount of XML schema’s to make our configurations. In this case we would either require a lightweight framework which does not heavily rely on XML descriptors like Spring as compared with those in EJB 2.1. Or the round about manner is the use the annotation only in those classes where the special functionality is to be attributed to the POJO. This is a similar to following patterns such as the factory or the decorator pattern.

But who would guarantee that all the programmers would be following such methods? Not everyone understands the depth of technology. Normally people work with the things taught to them . But if they are only taught annotations as per the current trends, it wouldn’t be much late before our age old methods to keep POJO’s as POJO would fail because with annotations, they would become dependent and later we would need something which would once again make them flexible as earlier. Doesn’t it seem like we are reinventing the wheel?

Related posts:

• Java EE – Exhaustive yet Enchanting
• Eclipse Europa Has Ruined My Day
• JAX-WS + JAXP Tutorial – Building A StockQuote Web Service Client
• Designing Enterprise Applications – Approaches and Patterns
• Inversion of Control – for easy integration

XML is document-oriented and JSON is data-oriented. So if you want to deal with highly structured documents that requires a complex structure, binary data, exact ordering of elements and be able to render itself then use XML. If you are focused on light-weight data exchange then JSON is the way to go.

In my opinion too JSON is handy only for light weight data transfer and nothing more than that. But with more nesting of data JSON can get utterly complex than XML. With XML you can define Schemas, form standardized document structures , extend exisiting document structures or import them when needed. The namespaces concept of XML has been very well established and incorporated in today’s applications and libraries.

XML Dominance
XML got more acceptance due to the already well established markup languages like HTML. Due to standardization by W3C it got quickly incorporated into the big vendors tools. Even a well documented JSP is purely XML. The main advantage of XML success is the XML Schema defintion language (XSD) which has given rise to numerous other standards like SOAP, WSDL etc. It is a very flexible and extensible language.

If you look behind the scenes a bit, XML has been reigning from the past and its usage in the industry has become massive. You might not be aware but all the big applications use XML either for storage, transfer, presentation or configuration of data and also meta data. MS SQL uses XML to transfer data from one database to other. MS WORD uses XML to provide formatting of user input content in the documents.

JSON- Some Facts
Coming back to JSON, the main fact which goes against JSON is it is not standardized. But now if JSON wants to establish its presence then the only field in my opinion would be SOA web services and AJAX where, it has received a lot of attention. Lately the debate on using web services with JSON has started. XML being heavy puts somewhat a hindrance on the acceptance of web services since the network infrastructure needs to get upgraded to get quicker adoption of XML RPC web services. With JSON, if web services give a higher throughput then it might be time to cash upon its acceptance for data transfer. Alexander writes about JSON pros and cons in his blog MyArch,

One of the keys to SOA success is that it should be easy to consume a service, i.e., the entry barrier for service consumers must be low to support “grass root” SOA adoption. While a top-down SOA effort may succeed, it will certainly take longer than bottom-up (“grass-root”) approach when developers are able to consume services as they see fit. AJAX/JSON fits this bill perfectly – it is easily understood by developers and it does not require any Web services -specific tools or infrastructure.So overall I’m pretty enthusiastic about JSON.

Advantages of JSON
The advantage of using JSON instead of XML is in the inheritent quality of data structuring in JSON. JSON is more closer to being a HashMap as in java or an associative array in some other languages like PHP. Hence it does not require parsing libraries in an application as XML does. The time spent however, on parsing XML into the native language, is not so much significant considering the fast processing power of machines today.

The comparison of XML and JSON lies more on the network bandwidth aspect. JSON can take almost half of the bandwidth as XML for transferring the same data. It can achieve the same throughput as passing simple objects in the network in a distributed computing environment.

JSON Web Services?
It would be interesting to see how would a SOAP message with JSON look like. You have to remember that WSDL is an extensible language and till date only HTTP Bindings and SOAP Bindings have been defined for it. It wont be long before we see JSON Bindings coming into the WSDL documents. Who would not want a quick data transfer while using web services into the application?

AJAX with JSON has got accepted well since JavaScript has the inbuilt capability to handle JSON data and if JSON web services start getting acceptance it might get well flourished to reach the popularity charts as XML did. Is the web service industry looking for a paradigm shift or are we just building a castle in the air?

Related posts:

• BEA Aqualogic Data Services Platform – First Glimpse
• Web and Desktop Apps – the 3rd World War!
• SCDJWS preparation – a kick start guide
• SCDJWS study material and resources – The most searched thing
• Working With JAX-WS in JDK 1.6

1. Whizlabs Test Simulator:
This is a good simulator which gives a feel of the real exam. But you should remember that this simulator is more tough than the actual exam. You would not fare well in this since it includes minute depths of the topics. But you shouldn’t feel that you are not prepared. Its the actual the other way round. If you do manage to get through this with a good score then you should be confident enough to pass the real one with flying colors.

Whizlabs isnt a free product. It costs around $21 and proves its worth in making you strong in the overall area of web services. If you want to try it out before purchasing then Whizlabs comes with a mini demo exam for free. It has a fixed set of questions.

2. xyzws.com – If you are in pocket crunching situtation the xyzws guys are to the rescue. They provide an online mock exam and its completely free. You have to register in their site and you can give as many times the mock test as desired. One more advantage of this mock is that there are about 200 questions which are chosen in a random order everytime you take this test. So don’t be surprised to see a new question even though you are repeating the test. After submission an explanation is provided for each question and the options for it and also a link is provided in case you want to clarify any doubt. Seriuosly, without this test I wouldnt have felt confident any more. It is quiet a balanced test and represents the same depth as the actual exam but beware, the same question may or may not be there in the actual exam. I had got only 3-4 questions from this test in the actual exam.

3. JAVARANCH Forums : You often come across a series of confusions when you begin your journey in the web services arena and in particular, with SCDJWS. So is there anybody to help you out? Of course there are many and they are all united in a single place. The name of the place is . This is a friendly place for any sort of discussions you might like to have not only in web services but also in any field of J2EE and Java. You are given prompt replies to solve your queries and also they will share a drink in your name once you clear the test!

4.Techtracer- else why would you have come here?
Techtracer will always keep a trace of the web services area since it is hip and happening and also would keep updating the information on the topics related to the SCDJWS exam. More information is coming up. So bookmark this right now!

Related posts:

• SCDJWS preparation – a kick start guide
• SCDJWS study material and resources – The most searched thing
• SCWCD – The 3 Steps to Success!
• SCDJWS – mission accomplished
• SCWCD – Mission Accomplished 2

The resources which I have considered for clearing SCDJWS are:
1. J2EE web wservices, by Richard Monson Haefel (RMH) – Its the bible.

Excellently written, simple language, indication of BP 1.0 in places where required and excellent code snippets for a good practice. It helps in studying the all the standards used in web services and also all the API’s in JWSDP 1.6 pack on which the certification is based on(except JAXB, Web services Security, Architecture Design, Patterns and Security).

2. www.xyzws.com – It is a very good online resource which provides a nice and detailed information on all the aspects concerned with SCDJWS. Of course, you will refer RMH for most of the things, but if you want to read the same things from a second resource , this is the one. The additional things which you will find here not covered in RMH are JAXB and Web services Security. Still you won’t find Architecture design concepts and patterns.

3. J2EE Blueprints (Service Endpoint Design) – The blueprints are a good and provided from those who make the certifications i.e Sun Micro systems. They are available in pdf format and online version as well. But as they are used for production environment, they are vast and boring if you read them in entirety. But if you are keeping in mind the SCDJWS objective and have gone through the above, then you don’t have to go through everything. The only aspect which was missing in the above two resource was Service Endpoint Design (Architecture Design). Yes, you should only read this one chapter because it neatly explains you about the layers in a web service environment. That should help in building the architect within you!

4. WS-I Basic Profile 1.0 (BP) - read it entirely for the issues and their corresponding solutions. You would come across the references of BP in RMH in most of the cases. But you won’t probably remember those at once and not all are mentioned in RMH. So glance over all the BP points because it is not only concise but is actually interesting to read. Many people feel bored to read a lengthy page of specifications, but BP is completely different. If you have worked in a web services then reading BP will make you feel as it is some cheat sheet or hacks to make your work easier and better. It is nothing but solutions to commonly faced problems which involve making web services efficient, inter operable and using a combination of open standards of web services in the right manner.

2. java.boot.by – Finally in the last week of the actual exam, you would probably be exhausted with the whole gamut of reading you did. So it is just not advisable to revise them again if you hadn’t made notes of important points and code snippents. Well its a good point when you can refer to someone else’s notes and which have been properly revised and used by many to pass the exam. These notes are from Mikalai Zaiken! They are the ultimate notes when it comes to revising your entire process. RMH does not include patterns used in web services, so it is advisable to prepare from these notes since they are very precise and cover almost all the aspects which will be required for SCDJWS in a rather point to point terms. So a final day revision would be best done through Mikalai’s notes.

Coming up – Need a list mock tests or help?

Related posts:

• SCDJWS mock tests and help – tried and tested
• SCDJWS preparation – a kick start guide
• SCDJWS – mission accomplished
• SCWCD – Mission Accomplished 2
• SCWCD – The 3 Steps to Success!

First Step – Getting Started.
The first and the foremost thing you have to do before you can get started with the preparation is to learn the W3C standards which prepare the foundation for implementing the web services. They are:
1. XML 1.0 – for representing data
2. XSD 1.0 – structure for the data
3. SOAP 1.1 – protocol to transfer the data
4. WSDL 1.1 – contract for the service access
5. UDDI 2.0 – registry for your listing services

Of course they might be too overwhelming to start with rather than learning the API’s but remember, getting acquainted with the standards will make your half job done in the preparation. Once you get to know the standards learning the API’s will be much more easier than trying them out in the first place.

Second step – Making a mark
The second step is the most fascinating one where you will be learning about the API’s to create the web services. You will be requiring the SUN JWSDP 1.6 pack (latest is 2.0, but the test refers to 1.6) which includes the following API’s
1. JAX-RPC – for creating a web service and its WSDL or its client
2. SAAJ – for handling of SOAP messages
3. JAXP – for parsing/ transforming XML data
4. JAXB - for advanced handling of XML and XSD
5. JAXR – for inquiring and communicating with UDDI

It would be beneficial if you follow the order mentioned here in learning the API’s. Its not a mandate however, just a comfortable approach to cover all the API’s without having to get entangled in learning them all at the same time.

Third Step – Rising from the fall
The third step is tightly bound to the second step. First let me tell you what this steps includes learning.
1. Basic Profile 1.0 – for solving your headaches
2. J2EE blueprints (Service Endpoint Design) – for giving you relief from the pain
3. Web service Security – to protect your services

Well these things actually are meant to be learnt before you actually do a SOA web service project but I am telling you to learn them after the API’s. Why? because it will embed in your minds the problems which you might encounter in the future if you didn’t have the Basic profile and the blueprints at all. You might call it reinventing the wheel. Why should you learn them after facing problems when they are present to solve them. Well, the first thing is that learning them in theory is boring and you wouldn’t even know what they mean in practicality if you never had been in the mentioned situation. Well its just like you learn to avoid slippery places only after you know what might happen if you fall. After learning to implement web services and use the API’s you would really appreciate why the Basic Profile and Blueprints have been created.

Fourth and final step – Taking the plunge
So now that you armed with the power to defeat and destroy.. umm..err.. give the test, you might as well get some first aid in the form of mock tests. They help you point out which area you might have been neglecting all the while and also brush up and strengthen the stuff that you have learnt. Give mock test 2 to 3 times so that you have to aim for the 100% when you are giving it for the 3rd time. A 90+ score in the 3rd time will indicate that you are almost ready for the actual test. Well, there’s no stopping you from scoring a 90+ in the first and second time, but from an average point of view, I am indicating that you might require 3 times. I did!

And finally BEST OF LUCK for the grand finale- the SCDJWS test! It would be truly a moment to rejoice when you clear the exam as I have felt. Just like you won a big war!

Coming up : Materials to use for SCDJWS preparation

Related posts:

• SCDJWS study material and resources – The most searched thing
• SCDJWS mock tests and help – tried and tested
• SCDJWS – mission accomplished
• SCWCD – Mission Accomplished 2
• SCWCD – The 3 Steps to Success!

BEA AL-DSP 2.5 takes it more further ahead by leaps and bounds utilising all the power of XML communication and combines the usage of XML, XSD, XPATH and XQUERY to give a complete package which can be used as a whole new kind of abstraction layer which can amalgamate data from different kind of data sources. The data sources which can be used to collect data in DSP is currently from JDBC sources, Web services, JAVA functions, XML data and Delimited (CSV) formatted data.

A layer of DSP site above the underlying different physical sources and all the developer needs to do is to configure all the different sources into the DSP Workshop IDE and then define the unified data which he wants to retrive and then create functions by which the required elements have to be mapped to the underlying elements. DSP does the complex job of validation, authentication upto the element level and gives a collective unified data which further can provide in the form of plain XML or in the form of web service. The knowledge of XQuery is required in case you want to customize the data returned. Although I have not been able to get the submit function of web service created from the data services working making a read only web service is the game of a single right click !!!

DSP even provides some remarkable features of modelling of the data coming from different sources, generating crystal reports with graphical representation and even direct transfer of data to the BEA Aqualogic Service Bus 2.5 which is an ESB for routing mechanisms. Working with DSP has opened my eyes to a whole new world of information transfer. Gone are the days when I needed to create a JDBC connection and code for the data retrieval process. This is surely fun and extremely fruitfull for a large application having distributed and different data resources.

Related posts:

• BEA Dev2Dev TechDays – An Experience
• Effects of Oracle BEA Acquisition
• Author
• JSON Web Services – the XML JSON debate further ahead
• SCDJWS preparation – a kick start guide