I have created an object to pass dynamic data to and from Web Services. I am blogging it because I want to know how others feel about this type of object.

The Need

Versioning of Web Services is difficult with many different factors to consider, which is beyond the scope of this blog. Lets say it is safe to say that you need to make Web Services backwards compatible for as long as possible. To do this you cannot change an existing operation, parameter, or return object. Also, you want to keep a concise operation list. So if you had an operation named getXYZ() which returns an object which you are certian will change to meet the business needs how do you do this?

Options

I considered a couple of different options. Some listed below.

Empty Fields
Array of Strings
An array of String with the attribute, name, and value delimited within it
2D Array
2 Arrays of String
Collection
SDO (JSR-235)

Each didn't work for one reason or another.

Empty Fields - How many do you add and what do you name them because they will never be the name of the data you will need. Besides that it's just a bad idea.
Array of Strings - They would always have to be in the same order and there is the possibility of getting an index out of bounds exception, I don't like exceptions.
An array of String with the attribute, name, and value delimited within it - What do you use as a delimiter that you know for a fact will never show up in a String representation of an object.
2D Array - Same as above but doubled and not supported by JAX-RPC.
Collection - Not supported by JAX-RPC.
SDO - Too much overhead and didn't like it.

Solution

Self Describing Data Object (SDDO) This object uses a Map, HashMap to be exact, to hold the data and an array of KVData (Key Value Data) Objects which is used to fake out the XML parser to think that the data is an array. In the get method for the data array it converts the values in the Map to KVData objects and puts them into an array and returns them. In the set method for the data array it simply puts the data back into the Map for easier data access.

The KVData object is a simple object which only holds 3 Strings key, value, and dataType. The key is the key name for the data, the value is the data value, and the dataType is the value.getClass().getName(). To instantiate the data on the other side I use reflection to create the object and set the data using the getDeclaredConstructor(String.class) method. Using this method you can recreate any object that can be created with the same String value the object returns from the toString() method. Since Calendar and Date are JAX-RPC data objects and they do not have a String constructor I had to treat these as special cases.

To insure proper operations and to avoid null pointers I choose to return a blank String if a requested key value is not found. This allows you to even remove data from the object without worrying about this object getting null pointers. This is a safe guard for the unexpected. We have created a Web Service Contract which all Web Services must abide by.

"A Web Service cannot remove or change existing operations. A Web Service cannot remove or change parameters, or return values."

Considering that the SDDO is not changed and the attributes within the SDDO are only added to making an addition to the SDDO attributes does not break this contract.

We also create Web Service Clients for our Web Services for use internally. With the SDDO a client will operate correctly as long as the contract is adhered to. In fact with a little care the client will operate correctly even if attributes are removed from the SDDO.

The Good

This object solves a couple of difficult problems with Web Services without versioning the service.

You can dynamically add data to Web Service parameters or return values.
You can remove data from a Web Service parameter or return value. This is dangerous though because you don't know what the clients are doing with this data.
Client code does not have to be changed to account for additional attributes added to the SDDO if the client does not care about the additional data.
This eases versioning changes due to data changes when the SDDO is used.
You can create wrappers for the SDDO for a set of attributes, such as an account, and have it still look like a pojo.
A wrapper can act as the attribute documentation of the SDDO.

The Bad

With all good there is the bad.

XML size is close to trippled for the SDDO because the need of passing the key and dataType values.
An SDDO without an clearly defined set of attributes will be very difficult to understand, this is a design issue though.
If you use a wrapper to make the SDDO look like a pojo it will take some extra work, using an IDE such as NetBeans though you can minimize that work.

Other Considerations

This object is not meant to be used with a set of data such as an address. An address has a clearly defined set of fields which do not change and therefor does not need a dynamic object such as this. An SDDO is not meant to be a replacement for good object design.

Voice your opinion

Please voice your opinion by commenting to this topic. If there is enough interest in seeing the source I will post it also.

JBoss - The Basics

Posted by ddevore on April 20, 2006 at 01:52 PM | Permalink | Comments (0)

This is not for the experienced JBoss application server user. It is meant to give the JBoss beginner the basics to running and deploying applications to JBoss 4.0.3 SP1. There is also information on how to improve efficiency when working with NetBeans and Creator.

JBoss Layout

JBoss is easy to understand if you know the way the directories are setup and how to work with them. First everything you will do to JBoss is in the install directory.

bin directory

The most important one here is the run.bat or run.sh. This will run the application server and display debug and information messages to the user in the session it is started in. To start JBoss simply use the run command from this directory. To stop the server do a CTRL-C in the session it was started in. There are also some other files there but this is the basics only so I will not discuss them.

lib directory

This is the "root" server lib directory. You don't usually have to nor want to do anything with these libs.

server directory

This is where the directories for the server instances are. This is where you will do most of your work.

default directory

The default directory is the directory for the default instance. This is the instance which is started if you do not specify an instance. If you are in need of multiple instances then you will need to duplicate this directory. So if you think that you will need more instances do yourself a favor and make a backup of this directory before doing anything else.

I will go through this directory and tell you a little about it and give you a little information which may come in handy in the future.

conf

This is where all the configuration files for the paticular instance reside. These are more or less needed but you don't need to do much with them to work with the server. The only one I have changed in this directory is the log4j.xml because I wanted to add some different appenders to keep more concise logs.

data

This directory I have never done anything in and never even navigated to tell I decided to write this. The only think I could see of any interest is the wsdl directory which will hold a sub directory for each archive which holds a web service which holds the wsdl and wsdd files for each service.

deploy

This is the most important directory. It contains all the deployed applications archive files and the jbossweb-tomcat55.sar directory, if you ready my other blogs you will see references to the jbossweb-tomcat55.sar directory. The most important thing in the jbossweb-tomcat55.sar directory is the server.xml. This is the file which will need to be modified if you are going to have multiple instances running. If you do run multiple instances make sure you change the listening ports in the server.xml, refeer to the JBoss site for information on changing ports. To run a server with a different name use this command run -c instance_name. The next important directory is lib. It is where the archive files need to be put for the instance to find them. For instance if you are going to be using databases the database lib goes here. The log directory is next, it is where the logs for the instance get put. The temp and work are where the applications get expanded to and run from.

others

There are other directories but these are all you really need to worry about when getting started.

JBoss Deployment

Under my normal development I use NetBeans and Creator with JBoss. I don't normally use the deploy ability of NetBeans, Creator does not currently support JBoss, because of the ease of doing a manual deployment. I have found that if I open a command prompt and run the copy command it is faster to deploy than through NetBeans. Since JBoss hot deploys new applications it works very will for me. I simply build the project and then use a script to deploy it from a command prompt. If you are going to use this method do not have the command prompt open in the dist directory because it will lock the directory and cause a Clean and Build to fail.

If you have any questions or need any more information please see JBoss.org or add a comment.

Databases with JBoss

Posted by ddevore on April 20, 2006 at 07:48 AM | Permalink | Comments (1)

This is not a difficult topic but one which I needed to include to have a more complete JBoss enterprise setup.

Needed Information

JNDI Name
Connection URL
    Server Name
    Port
    Database Name
Driver Class
User Name
Password

The ???-ds.xml file

JBoss provides all kinds of ???-ds.xml files ready to be customized in the JBOSS_INSTALL/docs/examples/jca directory. There is one for just about every database you would ever need. For the most part they use the information mentioned above with some of them needing a little more. JBoss did a good job with giving descriptive names where the XML does not explicitly state what it is looking for. They all have the standard start of the Connection URL also such as jdbc:oracle:thin:@ for Oracle and jdbc:mysql:// for MySQL as well as the default port. So if you don't change the default port on the database all you need to do is change the Server Name, Database Name, Driver Class, User Name, and Password and in most cases the Driver Class will not need to be changed either. Once this information is correct put the ???-ds.xml file in the deploy directory for the server you need the Database connection on.

The Library

You will need to add the jar for the Database you are using in the lib directory for the server you need the Database connection on. This is in the
JBOSSS_INSTALL/server/SERVER_INSTANCE/lib directory.

Happy Connections

You should now have a connection to the Database you need.

DataSources with Sun Java System Creator and JBoss

Posted by ddevore on April 19, 2006 at 02:15 PM | Permalink | Comments (0)

We are currently using Creator to create a testing and QA front end for the enterprise application we are developing. After success with working with services we finally needed to hit a configuration database to show all the configuration options available to different applications and users.

The Data Source

We started by putting 2 simple drop down on the screen and tried to attach a data source to them. Since we are using MySQL for this configuration database we had to add the data source, which is very simple. Select the Servers tab and right click on the Data Sources and you will see an Edit... button to the right of the drop down for the Server Type select this and in the dialogue which comes up select New on the bottom left. Then simply browse to the jar file for the data source you are adding, for us it is mysql-connector-java-3.1.12-bin.jar, and select Open. Give it a name and for MySQL put in com.mysql.jdbc.Driver for the Driver Class Name, if you select suggest it will suggest an older driver named org.gjt.mm.mysql.Driver. In the URL Template put in the following jdbc:mysql://#HOSTNAME:3306/#DATABASE changing the 3306 to the appropriate port and select close. Give the data source a name and fill in the fields with the proper information and select Add.

The JBoss XML

For JBoss to work correctly with your datasources from Creator you need to tell JBoss the references for the data sources. To do this you need a jboss-web.xml file in the creator_project/web/WEB-INF directory. Create this file, or download below, and put it in the creator_project/web/WEB-INF directory.

<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <resource-ref> <res-ref-name>jdbc/myDataSource</res-ref-name> <jndi-name>java:/myDataSource</jndi-name> </resource-ref> </jboss-web>

Make sure to change the myDataSource name to the actual jndi name in your JBoss configuration. Don't forget the "/" in the front of the datasource without this it will not work correctly.

The Binding

Once this is done you are ready to bind the data to the drop down. Simply put a drop down on your page and right click in and select Bind to Data.. Select Add Data Provider and select the proper table from your data source. Make sure that it selected the correct value and display fields and select OK.

Clean and Build

If you have not gotten any errors up to this point you should be able to clean and build the project and deploy to your JBoss directory. If you get errors under deploying make sure you set the data source correctly in JBoss Databases with JBoss and setup JBoss to work with creator How to setup JBoss to work with Sun Java Studio Creator

Happy Creating

Download jboss-web.xml file

Powered by
Movable Type 3.01D

java.net RSS Feeds