Monday, December 31, 2012

WS-I Basic Profile versions

WS-I stands for Web Services Interoperability industry consortium (WS-I). WS-I provides interoperability guidance for core Web Services specifications such as SOAP, WSDL, and UDDI. 

The profile uses Web Services Description Language (WSDL) to enable the description of services as sets of endpoints operating on messages.

WS-I versions are given below:

  1. Version 1.0 of this profile was released in early 2004.
  2.  Version 1.1 published in 2006 does not have the same scope as version 1.0. The part of version 1.0 dealing with serialization of envelopes and their representation in messages has been moved to a new profile called Simple Soap Binding Profile (SSBP)
  3.  Version 1.2 was finalized in November 2010. The main new features are the support for MTOM binary attachments and WS-Addressing
  4.  Version 2.0 was also published in November 2010. It uses SOAP 1.2, UDDI 3 and WS-Addressing
To read more on WS-I please click on this link


 

XML-to-Java mappings used by JAX-WS

In this post i am not going to discuss more details on XML-to-Java object mapping used by JAX-WS.

I will describe, when JAX-WS maps, XML element or attribute declaration to Java primitive wrapper class. Most of the time, during designing/writing schema definition(XSD) for web service, we are not thinking about that XML-to-Java conversion, hence later on it will become a issue while debugging web service.

There are mainly three conditions when XML element or attribute declaration converted to Java primitive wrapper class used by JAX-WS.

  1. When element declaration contains "minCccurs=0" attribute.
  2. When element declaration contains "nillable=true" attribute.
  3. When attribute declaration contains "use=optional" attribute. 
Examples:





In the above element/attribute declaration "short/boolean" primitive datatype is converted to "short/boolean" primitive wrapper class.

Sunday, November 25, 2012

How to hide/expose namespace from element in XSD

Whenever we are talking about XSD(Schema defination), we are using namespace. Basically what is namespace? and why it is required. Is is possible to hide the namespace from element name.

This post answer all those questions.

namespace - namespaces are using to avoid element name conflicts. If you have little bit knowledge of SQL then you can understand it better way. Suppose you have two tables like 'Employee' and 'Department' and you are trying to join two table to get the employee name, employee id, department name and department id. In this case, you query should be:

select ename, department_name, id, id from Employee e, Department d where e.dept_no=d.id;

In this query there is an issue. In the select we have written two id column, but it is not clear which table's id column it is, so there is a name conflict. In this case you have to prefix the table alias. So, that it is understandable.

So, it is possible to define two element with the same name with different namespace. namespaces are declare at the begining of schema defination.





In the above example, you can see the attribute name "xmlns", this attribute is used to define XML namespace. The namespace are declared using ":" colon. The text after the ":" is called a namespace.

If keyword "xmlns" define alone with a value of http://www.w3.org/2001/XMLSchema, is called default namespace.

Basically default namespace defines the rules and regulations for the schema.

you can refer other schemas using the keyword "xmlns" prefix with the namespace name, like the above example i have refer globaltypes using the "xmlns:gtns". Later on you can simply use the namespace name before the element name.

I hope from the above discussion, you have understand what is "namespace" and why it is required.

Now, the only question remains is "Can we hide namespace name from element name?" answer is Yes.

If you closely look the above code snipet of schema defination, you found there is another attribute i.e "elementFromDetault". Basically this attibute handles to hide/unhide the namespace from the element name.

Example:
If you use the above declaration for the schema, you will get the below:

Unqualified version:
 In the above example you can see the element name is not prefix with namespace.

Qualified version:









 In the above example you can see the element name is prefix with namespace.

Hence, you can say using the attribut "elementFromDefault" you can hide/unhide namespace from the element.

Monday, October 29, 2012

AeroGear Mobile Application development.

I am very happy to say that, after a long time Jboss, Read Hat, Inc comes with a very good tool in the area of Mobile Application development.

Nowadays, Mobile Native Application development and Mobile Web development diverts the intension of developers from regular web application development. Most of the BIG companies invested lots of money in this area. Some of them are successes and some of them are still working.

AeroGear is a JBoss Community project and development is sponsored by Red Hat, Inc. AeroGear is one of the best tools for Mobile native application development and Mobile web application development. I could say, AeroGear could be a good candidate for RAD in Mobile application.

The AeroGear application can also be tested using QUnit and Arquilian. AeroGear application can also be tested in emulator; the emulator name is "BrowserSim".

The AeroGear's Mobile web application is basically a combination of HTML5 + CSS + JavaScript + REST web services. You can also plugin Hibernet in data access layer.

As I mentioned, AeroGear is a JBoss Community project, So, AeroGear is much compatible with JBoss AS7.

We can use JBoss Developer Studio for AeroGear Mobile application development. JBoss Developer Studio is an IDE for Java Application development.

The AeroGear is available in two flavors, mentioned below:
AeroGear Mobile Web application development - library name is "AeroGear.js"
  1. AeroGear Mobile Native application development - It has two flavours
    1. AeroGear ios - version 1.0.0
    2. AeroGear Android - Coming soon.
Currently AeroGear emulator for following devices for testing:
  1. Apple iPad 2
  2. Apple iPhone 3
  3. Apple iPhone 4
  4. RIM BlackBerry Bold Touch 9900
  5. Samsung Galaxy S
  6. Samsung Galaxy S II
  7. Samsung Galaxy Nexus
  8. Samsung Galaxy Tab 10.1
I will you give you a demo on AeroGear in my next blog.


 

Friday, September 7, 2012

SSL is not enough for Web Services

SSL is not enough for Web Services, below mentioned are the reasions:

  • Intermediaries - SSL provide point-to-point whole message encription. Intermediaries need encription of parts of messages so that part can be read.
  • Two-way-authentication - Client side SSL required for two way credential management however is very deficult to manage, hence SSL is not suitable for authenticating all kind of web services clients.
  • Authorization - SSL does not handle authorization issues at all.
  • Federation - SSL has no mechanism of federation of web services security credentials which is very necessary in distributed web services environments.

Thursday, August 16, 2012

Java object Describer instead of toString() method

Consider you have a JavaBean/DTO/VO, It has some properties. Sometime at runtime we are trying to print object's properties's value with property name, just for debugging purpose.

In this situation, most of the time we override the toString() method of Object class and for the shake of convenience, we just use the object name in the print method.

If you notice carefully, you have to write code for that feature. The solution is to create some generic solution for that, so that that can be used everywhere.

I have created an Interface named Describable and it has one menthod named describe().







Also, created an abstract class named ValueObject that implements Describable and Serializable interface.



 Test program would be given below:




















This way you can reduce your duplicate coding and this is used by almost all java class.

If you wish to use the utility, you can download the binary and use.

Sunday, May 6, 2012

How to get JVM PID(Process ID) from Java Program.

As you all know each and every process running in the Operation System has an unique ID. In Unix/Linux it is easy to find the PID from java using Runtime class, but in Windows, earlier versions of Java it difficult to get the PID of the JVM. In Java5.0, it is easy to find the OS Process ID assigned to the JVM.
There is an utility that is ment to return the PID of all running JVM on the machine or remote machine. This utility is not only ment for PID, you can also get the argument and complete package name.

The good thing with this tool is you can monitor any JVM on the network just you have to have the IP of that machine.

Let's discuss about the utility.

In the binary folder you can find an executable file named "jps.exe". The complete name is "JVM Process Status tool", this utility takes some parameters and work as per that option.

Syntax:

jps [options] [hostid]

Here options is the list of options and hostid is the IP of the remote machine for which you want to monitor.

"jps" options are listed below:
  • -l Output the full package name for the application's main class or the full path name to the application's JAR file.
  • -m Output the arguments passed to the main method. The output may be null for embedded JVMs.
  • -q Suppress the output of the class name, JAR file name, and arguments passed to the main method, producing only a list of local VM identifiers.
  • -v Output the arguments passes to the JVM.
  • -help Returns the syntax of this tool.

You don't need to use the "hostid" command argument, if you want to list JVM processes on the local machine. But to list JVM processes on a remote, you need to use "hostid" to specify how to connect to the remove machine.

Getting Help : jps.exe -help

Getting only PID : jps.exe -q

Getting only main Class name : jps.exe -m

Getting with complete package name : jps.exe -l

Getting with argument : jps.exe -v

Hope this program will helps you to understand the utility.

Monday, April 9, 2012

Setup Clustered Message Queue for MDB

This blog Demonstrate how to setup a Clustered JMS message Queue in JBoss4.2.3 Application server, that is used by Message Driven Bean. The setup process may be diffent in other versions of JBoss.

There is a Queue previously setup by JBoss team. Those Queues are used by various purpose inside the JBoss Application Server.

There is an XML configuration file for setup the Destination Queue. That file is available in All mode of JBoss application server.

The path could be JbossAS/server/all/deploy/jboss-messaging.sar/destinations-service.xml

Open this file in any editor





and add Queuq name and add an attribut named "Clustered" as shown in the above picture.

Sunday, April 8, 2012

Setup Message Queue in JBoss Application Server.

Here we are trying to setup a brand new Message Queue in JBoss4.2.3 Application server. The setup process may be diffent in other versions of JBoss.

There is a Queue previously setup by JBoss team. Those Queues are used by various purpose inside the JBoss Application Server.

There is an XML configuration file for setup the Destination Queue. That file is available in All mode of JBoss application server.

The path could be JbossAS/server/all/deploy/jboss-messaging.sar/destinations-service.xml

Open this file in any editor

and add your Queuq.




Name - sould be your Queue name.

Sunday, February 12, 2012

How to use JBossCache

<< JBossCache Overview
There are a number of way you can implement the JBossCache. Those implementations are totally depends on your application requirement. In this document I am discussing about JBossCache with MBean, because this implementation is widely used.

This is for demo purpose,  so do not use any configuration for production deployment.


Requirements :
1. JBoss Application 4.2.3
2. Ecliple IDE.
3. Java 1.5 or above.


Required Jars:
1. jboss-cache-jdk50.jar - this is already ships with JBoss 4.2.3
2. jbossall_client.jar - this is also ships with JBoss4.2.3

 Some knowledge required on MBean.


MBean implementation of JBossCache is very straight forward. Only one file is required to be setup a JBossCache. This file is an XML file. This file is called a MBean deployment descriptor file. The file name is depends to you but most of the cases the file name will be jboss-service.xml 
  



























JBossCache Overview

JBossCache: JBoss Cache is a replicated and transactional  cache that can be used to store Java Objects. JBoss Cache is a fully featured distributed cache framework that can be used in any application server environment and standalone.

Today's large-scale enterprise applications, where scalability and high performance are required in-memory caching has a lead role to play. An in-memory cache can store either application state information or database query results. As many enterprise applications run in clustered environments, cache needs to be replicated across the cluster. Further, if greater reliability is needed, the cache should also be persisted to the hard disk or database.

JBoss Cache provides a powerful and easy to use system for caching frequently accessed data. JBoss Cache eliminates the time-consuming process of accessing the database for each request.

Types of JBossCache: There are two flavor of JBossCache

  1. JBoss Core Cache(fks - Tree Cache)
  2. JBoss Pogo Cache(fks - Tree CacheAOP)
Tree Cache: Tree Cache is a tree structured replicated transactional cache, that can be used to replicate data transactionally across multiple processes. So if we add an element to one tree, it will appear in all the trees in the cluster. A cache can either be local or replicated. 
Replication can be either asynchronous or synchronous. A synchronous replication blocks the caller until all trees in a cluster have been updated where as the synchronous replication simply puts the modification(s) on the bus and returns immediately, with replication going on in the background. JBossCache can be used transactionally, meaning that if you have a transaction, JBossCache will collect all modifications and only replicate at the end of the transaction. 
We can configure the JBoss cache though a configuration xml file or we can set it programmatically through it’s get/set methods.

Tree CacheAOP: TreeCacheAop extends the functionality of TreeCache but behaves as a true object cache providing transparent and finer-grained object mapping into internal cache. TreeCacheAop is a subclass of TreeCache, that uses instrumentation of class code to know when the state of an object has been changed. This helps to track changes to objects in the TreeCacheAop, and only replicate the changes at the end of a transaction. So if we have a big object and if we want to make some small changes in the object, so far we would have had to serialize the entire object and send it across the wire, wasting bandwidth and CPU cycles for serialization. In the TreeCache AOP case since we track changes to this object, only the changes will be replicated. So this will give us good performance, and not because AOP is so fast, but because we can reduce serialization and unnecessary network traffic.

Tree Cache Basics: The structure of a TreeCache is a tree with nodes. Each node has a name and zero or more children. A node can only have 1 parent. A node can be reached by navigating from the root recursively through children, until the requested node is found. It can also be accessed by giving a fully qualified name (FQN), which consists of the concatenation of all node names from the root to the node.

A TreeCache can have multiple roots, allowing for a number of different trees to be present in a single cache instance. Note that a one level tree is essentially a HashMap. Each node in the tree has a map of keys and values. For a replicated cache, all keys and values have to be Serializable.

A TreeCache can be either local or replicated. Local trees exist only inside the Java VM in which they are created, whereas replicated trees propagate any changes to all other replicated trees in the same cluster. A cluster may span different hosts on a network or just different JVMs on a single host.
The first version of TreeCache was essentially a single HashMap that replicated. However, the decision was taken to go with a tree structured cache because 
(a) it is more flexible and efficient and 
(b) a tree can always be reduced to a map, thereby offering both possibilities. The efficiency argument was driven by concerns over replication overhead, and was that a value itself can be a rather sophisticated object, with aggregation pointing to other objects, or an object containing many fields. A small change in the object would therefore trigger the entire object (possibly the transitive closure over the object graph) to be serialized and propagated to the other nodes in the cluster. With a tree, only the modified nodes in the tree need to be serialized and propagated. This is not necessarily a concern for TreeCache, but is a vital requirement for PojoCache (as we will see in the separate PojoCache documentation).

Structure of a Tree Cache: