What is a namespace?

A namespace is an identifier for elements. XML and XSD use the concept of namespaces to define a relationship between the elements and their hierarchy. It means that when their are multiple elements to be defined then it might be possible that some of the elements may tend to have the same name. But having the same name often leads to collision just as the in the case of classes with same names although in different packages but referenced by name alone in a Java program. Hence the concept of namespaces is used in order to distinguish such elements.

Why are namespaces used?

XML and XSD are never meant for human reading. You have to remember that even though XML is a data representation markup language, it would be rare that you will actually be parsing through an XML file to use the data in your application through your own code.

Such parsing is often supplied through the use of API’s like SAX, DOM, JAXB, etc. You would have till now actually used these libraries while dealing with web services since it is field which uses XML, XSD to the maximum. The concept of namespace has no relevance until and unless an XML instance is associated with an XML Schema (XSD). This is because, XSD defines what do the elements in the XML instance actually mean. A standalone XML just makes the data easier to understand to you but to an XML parser it is nothing but a set of elements in some heirarchy.

For example if suppose you have the following XML format:

<employee>
<name>Alan</name>
</employee>

From this an XML parser can list out that the XML instance contains 2 elements in which employee is the root and name is the child of employee. It cannot say anything more than that. For giving more meaning to the elements, XML Schema or XSD should be provided. If you want the parser to know what kind of element employee is then you would have to provide a namespace for the element to be in as follows:

<tt:employee xmlns:tt=”http://techtracer.com/schemas/employee”>
<name>Alan</name>
</tt:employee>

How to interpret namespaces?

In an object oriented language like Java, entities of the real world are mapped to Beans. Beans have properties. And in general every application uses the beans and their properties to provide values which are taken from either a system or an end user. Such values when needed to be transferred in the XML format need some kind of hierarchy to be structured with. For this API’s come to the rescue.

But before we can supply the API with the elements in any adhoc fashion it becomes necessary that we make the API aware of the structure by providing it with the Schema without which the API won’t be able to tell you if anything has gone wrong in the hierarchy or not. Such API are said to be namespace aware API’s.

For Example, if I have an bean inside a package which is to be included into any program then you would include it when required as:

import com.techtracer.*;

//and then make the bean as

MyBean bean = new MyBean();

Now you can refer to the classes within the package successfully.

Comparing the above to namespaces consider the example.

<tt:employee xmlns:tt=”http://techtracer.com/schemas/employee”>
</tt:employee>

Here tt would be an prefix to the elements which has the value of the entire URL and it would correspond to the namespace just as a package in Java and employee would be an element just as the MyBean in Java. If you would not have provided the packages then the Java program would have given out an error. Similarly in a namespace aware XML parser if you don’t specify the namespace of the element then it would not run successfully.

Default Namespaces

java.lang.* is the default package of core java. Comparing with a XSD the default namespace is:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema”>
</xsd>

Here xsd is in the default namespace i.e. the element xsd is an element of the XSD specification. So now we can say that as java.lang is the default package of java similarly the above namespace is the default namespace of XSD. And as Object is the parent of the Java classes the element xsd is the root of the XSD specification

Custom and Target Namespaces

There are libraries in Java, which may / may NOT be required. Library means something which you can refer to when required, else not. So including it unnecessarily as a inherent feature may be disturbing since they are present for specific reasons and not to be imposed as an implicit feature of the language. Consider this example:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema”>
<employee>Alan</employee>
</xsd>

Woops, now here is an error. The element employee is NOT an element of the XSD specification. If you have an XSD validator it will blurt out with a big error message. This is because the XSD specification does not know a thing about your custom element employee. So what do you do? Somehow you should keep your employee in a safe and secure place where it can be recognized as yours. So we can keep it under a custom namespace like “http://techtracer.com/schemas/employee”. So the change required in the above fragment would be as follows:

<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema” targetnamespace=”http://techtracer.com/schemas/employee”>
<employee>Alan</employee>
</xsd>

So now when the XSD validator comes across the element employee, it just checks if you have told it where it should belong (before starting the ritual of swearing at you!). Now it knows that you have mentioned a thing called targetnamespace. So it knows that your employee actually belongs to a separate specification which is nothing but your custom XML Schema. The new URL which is mentioned in the targetnamespace is your custom namespace itself.

Conclusion

Hope that this article helps to make you understand namespaces quite easily. Feel free to ask a question if you have any doubt about namespaces. Your query will be solved at the earliest.

Related posts:

• Java 5 Generics – Changing for good
• Resolving the “Unsupported major.minor version 49.0″ Error
• J2EE or JEE, Java 5 or Java 1.5 – Is SUN Crazy?
• Java EE – Exhaustive yet Enchanting
• And I thought I Knew How Java Worked!

I would use the same analogy of my development structure as mentioned in the above linked article i.e. my development structure consists of the following directories:

1. web – place for all my JSP, HTML, JavaScripts and Stylesheets. You can provide subdirectories as required for each of the different set of files
2. src – place for my java class files consisting of POJO’s or servlets.
3. etc – place for all config files like the most common web.xml
4. lib - place for all the necessary jar files to run my application. I even have included servlet-api.jar in this directory since you may have to deploy your web application in a remote server after compiling.
5. build – a temporary directory for keeping the compiled files
6. dist – a place to put in the finally packaged war file (distribution)
7. ant- place for my build.xml file and external properties file

All these directories are present in a parent directory called “WebApp“. The three things you have to keep in mind for making an Ant build file are -

1. tasks - which correspond to your command line tasks like javac, war etc. A group of tasks can be executed in a sequence by specifying targets.
2. target – It is like a function where you put reusable tasks so that it can be called later without duplicating them.
3. property – this element is used to define variables in your build file which is useful when the value like project_name or folder_name keeps on changing.

One of the most awesome features of Ant is that you can keep the properties file externally inside of defining all the variables within the build file. This properties file consists of all the required variables and their values in the form of name-value pairs and is simple text file. In this tutorial I would be using an external properties file.

For the tutorial I have used the following:

1. Java version 1.5
2. Apache Tomcat 5.0
3. Apache Ant 1.6.5

Okay we are now good to go with the great Ant tutorial. For this make a file with the name “build.properties“. This would be our external variables file.

root.dir=..
lib.dir=lib
src.dir=com
conf.dir=etc
web.content=web
project.name=WebApp
build.dir=build

NOTE: you must hit the ENTER key for starting a new line after the last line or Ant will give you an error “BUILD FAILED for some unknown reason”

It is not necessary to put in the name with the dot. You can have a name as “projectName” but there should be no quotes for the value. i.e it should NOT be projectName=”WebApp”

To make a build file we have to remember what is to be done for the deployments. To make things simple just make the modules (targets) necessary for the complete web application deployment which are

1. clean – remove all prior deployments of the same application if made
2. init – make the necessary structure for deployment as per the vendor’s
3. compile – compile your servlets or POJO‘s
4. copy – put the compiled files and web content in the deployment structre as created during init
5. war – make the war file and open the browser

Start making the build.xml file in the ant folder as follows:

<project name="AppBuilder" default="war" basedir="..">
	<property file="ant/build.properties"/>
</project>

Now we have to set the classpath for the servlet-api.jar to compile our servlets so put the servlet-api.jar in the lib directory of your development structure. Check the property “default” in the <project> element. It states the LAST module (target) inside the build file. In our case it is “war”

All the following XML elements will now go inside the <project></project> element created above. So put the classpath setting element,

<path id="classpath">
 	<fileset dir="${lib.dir}" includes="servlet-api.jar"/>
</path>

Here you need to set all the necessary jars to your classpath for successful compilation of the java source files. ${lib.dir} is used to retrive the value of the “lib.dir” i.e lib

Now we will start with out targets (modules) as mentioned in the list above :

1. clean

<target name="clean">
	<echo>Cleaning the ${build.dir}</echo>
	<delete dir="${build.dir}"/>
</target>

Here I am removing my build dir in case it was present earlier with compiled files
The <echo> element is only for displaying what you are doing in the command line.

2. init

<target name="init" depends="clean">
	<echo>Creating the build directory</echo>
	<mkdir dir="${build.dir}/WEB-INFclasses"/>
	<mkdir dir="${build.dir}/WEB-INFlib"/>
</target>

Here I am creating the normal deployment structure required for tomcat namely WebApp/WEB-INF/classes, etc. It doesn’t matter if the folder WEB-INF existed before making the folder classes. Ant automatically creates all the necessary parent folders if they don’t exist.

3. compile

<target name="compile" depends="init">
	<echo>Compile the source files</echo>
	<javac srcdir="${src.dir}" destdir="${build.dir}/WEB-INF/classes">
		<classpath refid="classpath"/>
	</javac>
</target>

Most important step and the most error giving step. Make sure that all the classpath have been set in the above <path> element. If all are proper then the all files in “src.dir” will be compiled successfully and moved to the build\WebApp\WEB-INF\classes. Just check the property “depends” of the <target> element here. This property is used to chain the modules (targets) in a sequential manner.

4. copy

<target name="copy" depends="compile">
	<copy todir="${build.dir}/WEB-INF">
		<fileset dir="${conf.dir}"/>
	</copy>
	<copy todir="${build.dir}">
		<fileset dir="${web.content}"/>
	</copy>
	<copy todir="${build.dir}/WEB-INF/lib">
		<fileset dir="${lib.dir}"/>
	</copy>
</target>

Here I am just copying my complied classes and web content files inside the corresponding deployment structure.

5. war

<target name="war" depends="copy">
	<echo>Building the war file</echo>
	<war destfile="${dist.dir}/${project.name}.war" webxml="${build.dir}/WEB-INF/web.xml">
		<fileset dir="${build.dir}"/>
	</war>
</target>

This is the final module (target) in my build.xml file which makes the WebApp.war required for the deployment. “war” is an Ant task for which you provide the path of the web.xml file and the directory which contains the deployment structure i.e in our case “build” directory. The destfile is the final location and name of the war file which would become dist\WebApp.war after the script has run.

Running the above script
Keep the build.properties and build.xml files in the ant folder. Make sure that the ANT_HOME environment variable is set to your ant‘s installation bin directory. Now, all you have to do is run the ant command on the build file as,

C:\> cd WebAppant\ant
C:\WebAppant\ant> ant

That’s it. If successful your development will finally become a fully packaged WebApp.war.

Final Words
Thus, we have made a complete packaged war file from our source with a single XML file and the wonderful Ant tool which is ready to be deployed in the tomcat manager. We can further dig deeper and make complex build.xml using the complete set of elements that Ant provides. But this tutorial was just to get you started with using Apache Ant. If you have any difficulty in understanding the individual elements please read their detailed explanation in the Apache Ant documentation.

Resources
If you have any problem in making the build.xml or build.properties please download them from here. (Right click and select “Save as ….”)

• build.xml
• build.properties

Related posts:

• Impressive Google Chart Generator Scripts
• The Technique of Virtual Deployment in Tomcat
• The Great Hibernate Tutorial – a great jump start for beginners
• Mozilla’s New Killer App – The WebRunner
• Working With JAX-WS in JDK 1.6

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

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