WEBSERVICE USING APACHE AXIS -TUTORIAL-2  UNDERSTANDING APACHE AXIS
(part-1)(published in DeveloperIQ..April,2004) (www.developeriq.com)
R.S.RAMASWAMY (rs.ramaswamy@gmail.com)

We saw some simple examples for XML-RPC & SOAP  in the March,2004 issue.  However, the latest technology is Axis from Apache Software Foundation.

Apache Axis can be thought of as an improved implementation of Apache SOAP.  While Apache SOAP used DOM for XML parsing, Axis makes use of SAX and hence it is more efficient and fast.  Secondly, it supports automatic generation of WSDL (Web Service Description Language) file.  We have already seen how this is done in an earlier tutorial on utilizing JWS from ASP.NET. (see  axis1.htm ).

In that lesson, we had created a simple bean and exposed that as web service in Axis.

In this tutorial, we will create a Stateless Session Bean EJB using WebLogic-7 Enterprise server, first.  For a change, we will be using simple query as business logic rather than the customary ‘greeter’ bean.  This will also help those readers who missed the earlier installments of the EJB tutorial.

After developing the EJBean and deploying it in WebLogic-7 server, we will test it with a standalone console-mode client.  This is the correct step-by-step procedure in developing programs.  If it works well, we will create a JSP to access the EJBean.  In all our previous lessons, we had been using servlet as client for the EJB.  This is the first time that we are using JSP for accessing the EJB.

Normally, it is not a good practice to simply transfer the servlet code to JSP as scriplet, because, in that case the business logic will be exposed to the web server administrator.  If it is a servlet, the developer is deploying the class file only in the web server.  So the web server’s administrator cannot see the source code for the business logic.  But, if it is a JSP with plain scriplet, without using ‘JSPbean’, the server administrator can see the source code.  It is normally observed that except in the OSF/FSF circles, business logic is not meant to be exposed to others.  That is why it is the standard practice to use a JSPbean and refer to it in the JSP file.  It also helps in partial separation of code and presentation. (Readers can refer to the first installment of J2EE tutorial on page 110 of DeveloperIQ, October 2003 issue, for details on JSP, JSPbean etc,available in j2ee1a.htm)  .

But, in the present case, we need not follow that procedure and unnecessarily complicate things because the actual business logic is in EJB and not in JSP.  The JSP is simply the code for invoking the EJB.  This will considerably simplify things.  We will deploy the JSP and test the JSP in tomcat3.2 server.The big question now is “Why not deploy the JSP in weblogic server itself?”

After all, any J2EE container will have provision for running Servlets & JSP, as also EJB.  So it is possible and sometimes recommended.  But, it is not always essential and is sometimes to be avoided for the following reasons:

1.  It may not be desirable to get tied down to any one Enterprise server for all our requirements.  By keeping the servlet/JSP part in tomcat and using weblogic for EJB only, we achieve some degree of independent operation.  If we decide to use JBoss3.2 or JBoss4, later, we can just change a few lines of code in the reference of our file.  This type of flexibility may be necessary in real life.  Certainly, there may be some degradation in speed but what we lose in speed, we gain in simplicity & freedom of choice.  This is an architectural decision and opinions may differ. 

2.  Moreover, Apache themselves are reported to be working on the creation of an EJB server and it is certain that there will be greater synergy between tomcat and Apache EJB server when it appears. 

3.  Besides all these reasons, we have a much more important reason for using tomcat as the web-tier.  We want to expose our EJBean as an XML-webservice, using Axis and it works fine in tomcat as both are from Apache. 

Some people prefer to use simple JavaBeans in place of EJB.  But, it is not advisable…Scalability, security, load balancing, transaction support etc. are of paramount importance in enterprise and it will be most unreasonable to forego all these built-in advantages of EJBean and opt for plain bean. 

There was an interesting posting in the web by Joshua Davis on this topic as follows: (quoted below).

Misconception (1) ‘J2EE = Java Server Pages’ ‘Java Server Pages are useful for creating HTML user interfaces quickly, but that’s about it.  Projects that attempt to ‘simplify J2EE’ by using JSPs and Servlets without using EJBs inevitably end up having transaction management problems.’  Misconception (2) ‘EJBs are too complex’ ‘EJBs do not need to add significant complexity.  Stateless session EJBs are not difficult to write, and provide a simple way to expose transaction-managed functionality from an EJB server.  Home interface, remote interface, EJB implementation and deployment descriptor are easily made as templates, & no complex ‘persistence’ is coed

A reference has been made by Manoj Kothale who has written about such templates, which can be found in DeveloperIQ, October 2003 issue. It is advisable to avoid BMP beans and even CMP is being replaced gradually by JDO (Java Data Objects). Castor is one such technology, which was covered by Manoj Kothale in DeveloperIQ, March ’04 issue & there was an article on JDO by Sivakumar (DeveloperIQ, July 2003 issue).Readers may get more information about this latest and elegant technology from the book “Java Data Objects” from OReilly press,by David Jordan & Craig Russell..

In Enterprise environment, the cost of and established server like WebLogic/WebSphere/JBoss, more than offsets the expenditure, by comprehensive support and reliability with advanced features.

However, while EJB is essential for Enterprise level, it is equally important to provide for inter-operability, for at least some of the business logic.  It extends the reach of the business object to more clients.  It is able to overcome firewalls and enables interaction between programs.  And that is the topic of our present tutorial.

So, we now proceed to study, how we can ‘expose’ our EJBean as an XML-webservice, using Axis.

There are two methods, by which a bean can be exposed as a webservice in Axis. The first method is just to write the java source code and save it as a file with *.jws extension in Axis folder of tomcat ( as was done in the earlier article; please review the earlier lesson on this technique as given on page 62, DeveloperIQ, Jan-2004 issue).  This is known as ‘Drop-in Deployment’.axis1.htm

This is a very simple and quick method. 

But, this assumes that the java source file is available with us and secondly we do not mind that source code to be visible to the tomcat administrator.  Normally, it may not be desirable but in the present case, the actual business logic is in the EJBean and the source code that is placed in Axis folder of tomcat is only the code for the bean that calls the EJBean! So, there is no problem at all! And this is an ultra-simple method of exposing our EJB service as an XML-webservice!

We will do that in first demo.  Once we place this jws file in tomcat, we can easily get the automatically generated wsdl file.  This can then be used in ASP.NET or a java program.

Microsoft cannot be  wished away! Any serious enterprise has to interact with Microsoft platform. Secondly, a number of such webservices can interact with each other programmatically.

This is why Sun’s J2EE1.4 has made XML-webservice the cornerstone of its implementation!

The second method is more involved and orthodox.  This method is necessary if we do not want our source code to be visible to anyone.

In this case, we create the Axis-bean, compile it and copy the class file to Axis/web-inf/classes folder of tomcat.     Then, we proceed to create a wsdd file (web service deployment descriptor).  This is an XML file.  In the next step, we deploy the bean in tomcat.  After this, we can easily get the wsdl file.

Here again, we can either create a javabean to access our EJB and create a wsdd for that or we can skip creating such a javabean and create a wsdd directly for the EJB.  We will demonstrate both the methods, but it is said that at present, neither stateful beans nor Entity beans can be used in Axis. That may be a fact but if we adopt our method as outlined above, i.e. accessing the EBJ by an Axis bean, it may be possible! And we will also demonstrate how the web service can be accessed by a servlet and also by a WAP/J2ME client. The book “J2EE Blue Prints” from Sun Micro Systems (Pearson-Education), discusses all these possibilities.To ensure that the wsdl file works fine, we create a console mode program in java for accessing the web service and test it. 

This introductory note on what is about to be done is necessary since there are so many files here and we are likely to get confused.

It is assumed that we have already created a simple Access database named ‘telephone’ and a table1 with just two fields (name and number)(both are strings).  We should also remember to register it in ODBC.  As we have to first create the EJB, for it to be deployed, we now proceed to do it.

We are using WEBLOGIC-7.  That is being taken up in the next part of this seven part tutorial, which follows.   

Continued in axis2b.htm 

Visit  http://in.geocities.com/rsramsam