SOA & Web Services Tutorials

SOA and Web Services
SOA and Web Services Tutorials in this site helps you learn more about service-
oriented architecture (SOA) and web services. So, why wait learn SOA & Web
Services now.
1. What is SOA (Service Oriented Architecture)?
An introduction to the Service Oriented Architecture.

2. Web Services - An Introduction
The next generation of distributed computing has arrived. A Web service is a unit
of managed code that can be remotely invoked using HTTP, that is, it can be
activated using HTTP requests.

3. Why Web Services?
In this section of WebServices tutorials series we will understand why Web
Services are developed and what are the benefits of using Web Services for the
development of Enterprise applications.

4. J2EE Web Service Development with Attachments Using Axis
This article discusses the development of a java web service that takes DIME or
MIME attachment as input and returns the output as an appropriate attachment.
(Author: Murthy Vaddiparthi)

Building a Simple Web Service by Jeevaraj Gnanaselvan Dhanaraj
(jeevaraj_1970@yahoo.com)
5. Developing Simple Web Service
In this tutorial we will create a simple web service and a client web application
using eclipse IDE along with Lomboz plug in. We will also deploy and test the
web service on Tomcat 5.5.4 web application server. This application, while
simple, provides a good introduction to Web service development and some of the
Web development tools available.

Web Services Tutorials by R.S.RAMASWAMY (rs.ramaswamy@gmail.com)
6. Exposing a javabean (jws) from Tomcat/Axis
In this experiment, we attempt exposing a javabean (jws) from Tomcat/Axis and
consuming that service in an ASP.net program.

7. Understanding Apache Axis
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.

8. Creating and testing an EJB in WebLogic Server
In this section you will learn how to create and test an EJB in WebLogic Server.

9. Drop-In Deployment in Apache AXIS
This tutorial discusses about drop-in deployment in Apache AXIS.

10. Apache AXIS-Deployment using WSDD File
In this part, we will follow the WSDD method. We have already created
sqlaxisbean.java as explained in the last article. We used it as sqlaxisbean.jws
(drop-in method). There was no necessity to compile this file.But in WSDD
method (web-service deployment descriptor), we should compile this file.Next,
we create the WSDD file. Then, we deploy this bean to tomcat. We may have to
restart the tomcat4.1 webserver.

11. Exposing EJB as XML-Webservice
In this web service tutorial you will learn how to expose an EJB as XML-
Webservice using Axis.

12. Accessing ejb-webservice through WAP
This tutorial discusses how to Access ejb-webservice using WAP (Wireles-
Application Protocol)

13. J2ME CLIENT FOR EJB & EJB-WEBSERVICE
In the previous section,we've dealt with how to write WAP client for accessing
ejb. In the same way, we are going to see how to write J2ME client for ejb.
Developing and deploying Web Services on Apache Geronimo Application

Server
14. Understanding Apache Geronimo Application Server
Apache Geronimo is a open source JavaEE( or J2EE, old name) application
server. This section introduces you with the Apacehe Geronimo Application
Server.

15. Developing Axis Web services with XML Schemas.
Developing SOAP based web services (Note: If you are looking for RESTful web
services, please refer Axis2 ) with Axis1.4 is pretty easy, if the consuming clients
are purely java. The real challenge comes if you want to make your web services
interoperable with wide range of clients including .Net, Perl, C++ and Flash MX
etc.
What is Service-Oriented Architecture?

Service Oriented Architecture or SOA for short is a new architecture for the development
of loosely coupled distributed applications. In fact service-oriented architecture is
collection of many services in the network. These services communicate with each other
and the communications involves data exchange & even service coordination. Earlier
SOA was based on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is
based on the Web Services.
Broadly SOA can be classified into two terms: Services and Connections.
Services:
A service is a function or some processing logic or business processing that is well-

defined, self-contained, and does not depend on the context or state of other services.
Example of Services are Loan Processing Services, which can be self-contained unit for
process the Loan Applications. Other example may be Weather Services, which can be
used to get the weather information. Any application on the network can use the service
of the Weather Service to get the weather information.
Connections:
Connections means the link connecting these self-contained distributed services with
each other, it enable client to Services communications. In case of Web services SOAP
over HTTP is used to communicate the between services.
The following figure is a typical example of the service-oriented architecture. It shows

how a service consumer sends a service request to a service provider. After accepting the
request, service provider send a message to the service consumer. In this case a service
provider can also be a service consumer.
Different Technologies Used:
SOA is much different from point-to-point architectures. SOA comprise loosely coupled,
highly interoperable application services. These services can be developed in different
development technologies (such as Java, .NET, C++, PERL, PHP), the software
components become very reusable i.e. the same C# (C Sharp) service may be used by a
Java application and / or any other programming language. WSDL defines an standard,
which encapsulates / hides the vendor / language specific implementation from the
calling client / service.
SOA definitions
(From http://en.wikipedia.org/wiki/Service-oriented_architecture )
Term Definition / Comment

service (Ideally) a self-contained, stateless business function which accepts one
or more requests and returns one or more responses through a well-
defined, standard interface. Services can also perform discrete units of
work such as editing and processing a transaction. Services should not
depend on the state of other functions or processes. The technology used
to provide the service, such as a programming language, does not form
part of this definition.
orchestration Sequencing services and providing additional logic to process data. Does
not include data presentation.
stateless Not depending on any pre-existing condition. In a SOA, services should
not depend on the condition of any other service. They receive all
information needed to provide a response from the request. Given the
statelessness of services, service consumers can sequence (orchestrate)
them into numerous flows (sometimes referred to as pipelines) to
perform application logic.
provider The function which performs a service in response to a request from a
consumer.
consumer The function which consumes the result of a service supplied by a
provider.
discovery Service oriented architecture relies on the ability to identify services and
their capabilities. Therefore, a SOA depends on a directory which
describes the services available in its domain.
binding The relationship between a service provider and consumer is dynamic; it
is established at runtime by a binding mechanism.
Why SOA?
SOA architecture enables seamless Enterprise Information Integration. Here are some of
the Benefits of the Service Oriented Architecture:
 Due to its platform independence, it allows companies to use the software and
hardware of their choice .
 There is no threat of vendor lock-in
 SOA enables incremental development, deployment, and maintenance.
 Companies can use the existing software (investments) and use SOA to build
applications without replacing existing applications
 The training costs are low, so the available labor pool can be used for running the
applications
Web Services - Web Services Tutorials
In this section of the Web Services tutorial you will be familiarized with the Web
Services.
Introduction
The next generation of distributed computing has arrived. A Web service is a unit of
managed code that can be remotely invoked using HTTP, that is, it can be activated using
HTTP requests.
Historically speaking, remote access to binary units required platform-specific and

sometimes language-specific protocols. For example, DCOM clients access remote
COM types using tightly coupled RPC calls. CORBA requires the use of tightly coupled
protocol referred to as Internet Inter-ORB Protocol (IIOP), to activate remote types.
Enterprise JavaBeans (EJBs) requires a Remote Method Invocation (RMI) Protocol
and by and large a specific language (Java). Thus each of these remote invocation
architectures needs proprietary protocols, which typically require a tight connection to the
remote source.
One can access Web services using nothing but HTTP. Of all the protocols in existence
today, HTTP is the one specific wire protocol that all platforms tend to agree on. Thus ,
using Web services, a Web service developer can use any language he wish and a Web
service consumer can use standard HTTP to invoke methods a Web service provides. The
bottom line is that we have true language and platform integration . Simple Object
Access Protocol (SOAP) and XML are also two key pieces of the Web services
architecture.
What is a Web Service
Web services constitute a distributed computer architecture made up of many different

computers trying to communicate over the network to form one system. They consist of a
set of standards that allow developers to implement distributed applications - using
radically different tools provided by many different vendors - to create applications that
use a combination of software modules called from systems in disparate departments or
from other companies.
A Web service contains some number of classes, interfaces, enumerations and structures
that provide black box functionality to remote clients. Web services typically define
business objects that execute a unit of work (e.g., perform a calculation, read a data
source, etc.) for the consumer and wait for the next request. Web service consumer does
not necessarily need to be a browser-based client. Console-baed and Windows Forms-
based clients can consume a Web service. In each case, the client indirectly interacts with
the Web service through an intervening proxy. The proxy looks and feels like the real
remote type and exposes the same set of methods. Under the hood, the proxy code really
forwards the request to the Web service using standard HTTP or optionally SOAP
messages.
Web Service Standards
Web services are registered and announced using the following services and protocols.
Many of these and other standards are being worked out by the UDDI project, a group of
industry leaders that is spearheading the early creation and design efforts.
Universal Description, Discovery, and Integration (UDDI) is a protocol for describing

available Web services components. This standard allows businesses to register with an
Internet directory that will help them advertise their services, so companies can find one
another and conduct transactions over the Web. This registration and lookup task is done
using XML and HTTP(S)-based mechanisms.
Simple Object Access Protocol (SOAP) is a protocol for initiating conversations with a
UDDI Service. SOAP makes object access simple by allowing applications to invoke
object methods or functions, residing on remote servers. A SOAP application creates a
request block in XML, supplying the data needed by the remote method as well as the
location of the remote object itself.
Web Service Description Language (WSDL), the proposed standard for how a Web
service is described, is an XML-based service IDL (Interface Definitition Language) that
defines the service interface and its implementation characteristics. WSDL is referenced
by UDDI entries and describes the SOAP messages that define a particular Web service.
ebXML (e-business XML) defines core components, business processes, registry and
repository, messaging services, trading partner agreements, and security.
Implementing Web Services
Here comes a brief step-by-step on how a Web service is implemented.
 A service provider creates a Web service

 The service provider uses WSDL to describe the service to a UDDI registry
 The service provider registers the service in a UDDI registry and/or ebXML
registry/repository.
 Another service or consumer locates and requests the registered service by
querying UDDI and/or ebXML registries.
 The requesting service or user writes an application to bind the registered service
using SOAP in the case of UDDI and/or ebXML
 Data and messages are exchanged as XML over HTTP
Web Service Infrastructure
Even though Web services are being built using existing infrastructure, there exists a
strong necessity for a number of innovative infrastructures. The core architectural
foundation of Web services are XML, XML namespaces, and XML schema. UDDI,
SOAP, WSDL, ebXML and security standards are being developed in parallel by
different vendors
Web Services Technologies and Tools
There are a number of mechanisms for constructing Web services. Microsoft has come
out with a new object-oriented language C# as the development language for Web
services and .NET framework. Microsoft has an exciting tool called Visual Studio .NET
in this regard. The back end database can be Microsoft SQL Server 2000 in Windows
2000 Professional.
Sun Microsystems has its own set of technologies and tools for facilitating Web services
development. Java Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJB)
architecture and other Java 2 Enterprise Edition (J2EE) technologies play a very critical
role in developing Web services.
There are a number of tools for developing Web services. They are Forte Java IDE,
Oracle JDeveloper, and WebGain Studio.
Sun Microsystems has taken an initiative called Sun ONE (Open Network Environment)
and is planning to push Java forward as a platform for Web services. It is developing Java
APIs for XML-based remote procedure calls and for looking up services in XML
registries - two more JAX family APIs: JAX/RPC (Java API for XML Remote Procedure
Calls) and JAXR (Java API for XML Registries). These will wrap up implementations of
Web services standards, such as SOAP and UDDI.
IBM also for its part has already developed a suite of early-access tools for Web services
development. They are Web Services Toolkit (WSTK), WSDL Toolkit, and Web
Services Development Environment (WSDE).
Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol")

submission to W3C.
From the draft W3C specification:

SOAP is a lightweight protocol for exchanging structured information in a decentralized,
distributed environment. It is an XML based protocol that consists of three parts: an
envelope that defines a framework for describing what is in a message and how to
process it, a set of encoding rules for expressing instances of application-defined
datatypes, and a convention for representing remote procedure calls and responses.
Apache Axis is an Open Source SOAP server and client. SOAP is a mechanism for
inter-application communication between systems written in arbitrary languages, across
the Internet. SOAP usually exchanges messages over HTTP: the client POSTs a SOAP
request, and receives either an HTTP success code and a SOAP response or an HTTP
error code. Open Source means that you get the source, but that there is no formal support
organization to help you when things go wrong.
Conclusion
For the last few years, XML has enabled heterogeneous computing environments to share
information over the Web. It now offers a simplified means by which to share process as
well. From a technical perspective, the advent of Web services is not a revolution in
distributed computing. It is instead a natural evolution of XML application from
structured representation of information to structured representation of inter-application
messaging.
Prior to the advent of Web services, enterprise application integration (EAI) was very
difficult due to differences in programming languages and middleware used within
organizations. This led to the situation where interoperability was cumbersome and
painful. With the arrival of Web services, any application can be integrated as long as it
is Internet-enabled.
It is difficult to avoid the popularity and hype that is surrounding Web services. Each
software vendor has some initiative concerning Web services and there is always great
speculation about the future of the market for them. Whichever way it turns out, Web
service architectures provide a very different way of thinking about software
development. From client-server to n-tier systems, to distributed computing, Web service
applications represent the culmination of each of these architectures in combination with
the Internet.
Why Web Services?

In this section of WebServices tutorials series we will understand why Web Services are
developed and what are the benefits of using Web Services for the development of
Enterprise applications.
Why Web Services?
Here are the benefits of using Web Services:
Exposing the function on to network: A Web service is a unit of managed code that can
be remotely invoked using HTTP, that is, it can be activated using HTTP requests. So,
Web Services allows you to expose the functionality of your existing code over the
network. Once it is exposed on the network, other application can use the functionality of
your program.
Connecting Different Applications: Web Services allows different applications to talk

to each other and share data and services among themselves. Other applications can also
use the services of the web services. For example VB or .NET application can talk to java
web services and vice versa. So, Web services is used to make the application platform
and technology independent.
Standardized Protocol: Web Services uses standardized industry standard protocol for
the communication. All the four layers (Service Transport, XML Messaging, Service
Description and Service Discovery layers) uses the well defined protocol in the Web
Services protocol stack. This standardization of protocol stack gives the business many
advantages like wide range of choices, reduction in the cost due to competition and
increase in the quality.
Low Cost of communication: Web Services uses SOAP over HTTP protocol for the
communication, so you can use your existing low cost internet for implementing Web
Services. This solution is much less costly compared to proprietary solutions like
EDI/B2B.
Support for Other communication means: Beside SOAP over HTTP, Web Services
can also be implemented on other reliable transport mechanisms. So, it gives flexibility
use the communication means of your requirement and choice. For example Web
Services can also be implemented using ftp protocol (Web services over FTP).
Loosely Coupled Applications: Web Services are self-describing software modules

which encapsulates discrete functionality. Web Services are accessible via standard
Internet communication protocols like XML and SOAP. These Web Services can be
developed in any technologies (like c++, Java, .NET, PHP, Perl etc.) and any application
or Web Services can access these services. So, the Web Services are loosely coupled
application and can be used by applications developed in any technologies. For example,
I have heard of people developing Web Services using Java technologies and using the
Web Services in VB or .NET applications.
Web Services Sharing: These days due to complexness of the business, organizations
are using different technologies like EAI, EDI, B2B, Portals etc. for distributing
computing. Web Services supports all these technologies, thus helping the business to use
existing investments in other technologies.
Web Services are Self Describing: Web Services are self describing applications, which
reduces the software development time. This helps the other business partners to quickly
develop application and start doing business. This helps business to save time and money
by cutting development time.
Automatic Discovery: Web Services automatic discovery mechanism helps the business
to easy find the Service Providers. This also helps your customer to find your services
easily. With the help of Web Services your business can also increase revenue by
exposing their own Web Services available to others.
Business Opportunity: Web Services has opened the door to new business opportunities
by making it easy to connect with partners.
J2EE Web Service Development with

Attachments Using Axis
Summary
This article discusses the development of a java web service that takes DIME or MIME
attachment as input and returns the output as an appropriate attachment. It also discusses
the client implementation for these web services. It uses the open source Apache Axis
implementation of the web services. The whole source code can be downloaded from
source zip file. Author expects that the intended audience for this article have a basic
understanding of J2EE web service development.
Introduction
Attachments are becoming increasingly popular in the web service development

especially in the world of interoperable environment where the language is not at all a
barrier and thanks to the Service Oriented Architecture (SOA). DIME attachments are
used with a lot of web services developed in C# in the .NET world. Using DIME
attachments we can send various binary files, XML fragments and other SOAP messages.
These attachments are becoming increasingly popular often with the Health Insurance
and Life Insurance sectors that follow the ACORD standards for transferring the
prescription data in XML.
As a developer very often one faces the following challenges in the context of J2EE web
service development with attachments:
1. Developing a web service that handles the attachments.

2. Developing a client for accessing such web service.
3. Develop the code to deal with the attachments used in such web services.
In this article, I have shown the implementation for all the above three tasks by using
Apache Axis and Tomcat. I have used XML string as an attachment.
During the later half of last year I worked on a project implementing a client to access a
web service written in C# that takes a big chunk of XML string as a DIME attachment.
Recently I implemented a web service with attachments using Axis. While going through
the process I found that there is very little documentation using Apache Axis especially in
implementing the code that handles the attachments and I have decided to share my
experience with the rest of the community.
Web Service Implementation
I have used Tomcat 5.x as the web server to install the web application and uses axis
1.2.1. To implement a web service that takes either a MIME or DIME attachment, we
have to define an operation that takes a parameter javax.activation.DataHandler as a
parameter. I have defined two operations -- one that handles a DIME attachment and
sends a DIME attachment and another one that handles a MIME attachment and sends a
MIME attachment as shown in Listing 1.
Listing 1. Method signatures in the web service
public Object getDimeData(DataHandler dh)

throws InputValidationException,
AttachmentServiceException
public Object getMimeData(DataHandler dh)

throws InputValidationException,
AttachmentServiceException
Whether it is a DIME attachment or MIME attachment the way we get the data from the
attachment is similar. But it is very important to make an input data validation at every
point. The very first step in the getDimeData() or getMimeData() is to check whether
the attachment we received is of correct type or not. If the attachment is not of the
expected type we can throw an InputValidationException. Listing 2 shows the code
to handle the DIME attachment.
Listing 2. Checking the DIME attachment
MessageContext msgContext =
MessageContext.getCurrentContext();
Message rspmsg =
msgContext.getResponseMessage();
log.info("org.apache.axis.attachment
s.Attachments.SEND_TYPE_DIME : "
+
org.apache.axis.attachments.Attachme
nts.SEND_TYPE_DIME);
int inputAttachmentType =
rspmsg.getAttachmentsImpl().getSendT
ype();
log.info("inputAttachmentType : " +
inputAttachmentType);
if (inputAttachmentType !=
Attachments.SEND_TYPE_DIME){
String failMsg = "Attachment
passed is not a DIME attachment,
please check.";
throw new
InputValidationException("Invalid
input data error : " + failMsg);
}
Listing 3 shows the code to handle the MIME attachment.
Listing 3. Checking the MIME attachment
MessageContext msgContext =
MessageContext.getCurrentContext();
Message rspmsg =
msgContext.getResponseMessage();
log.info("org.apache.axis.attachment
s.Attachments.SEND_TYPE_MIME : "
+
org.apache.axis.attachments.Attachme
nts.SEND_TYPE_MIME);
int inputAttachmentType =
rspmsg.getAttachmentsImpl().getSendT
ype();
log.info("inputAttachmentType : " +
inputAttachmentType);
if(inputAttachmentType !=
Attachments.SEND_TYPE_MIME){
String failMsg = "Attachment
passed is not a MIME attachment,
please check.";
throw new
}
After checking for the correct type of attachment, we need to some how
get the contents in the attachment. We need to get the byte array in the
attachment. Although attachment can be used to send images and various
other types of content, in our current problem we are just dealing with
an XML string. Listing 4 shows the code to get an array of bytes from the
DataHandler object. The procedure to get the byte array is similar what
ever may be the attachment.
Listing 4. Getting the byte array from any attachment
public static byte[]

getBytesFromDataHandler(DataHandler
data) throws IOException {
InputStream in = null;
byte out[] = null;
in = data.getInputStream();
if(in != null) {
out = new
byte[in.available()];
in.read(out);
} else {
out = new byte[0];
}
return out;
}
Once we have the byte array it is easy to get the actual content if we
know the type of content. Since it is a String in the current scenario,
we can use UTF-8 charset to convert it to the original String. Listing 5
shows the code to get the input String passed by the client from the
attachment.
Listing 5. Getting the client's input String from attachment
private String
getInputString(DataHandler dh)
throws InputValidationException {
String failMsg = null;
if (dh == null ) {
failMsg = "Attachment
is null -- missing attachment.";
throw new
data error : " + failMsg);
} else {
byte[] responseBytes
= null;
try {
responseBytes
= Utils.getBytesFromDataHandler(dh);
log.info("responseBytes
length : " + responseBytes.length);
} catch(IOException
e) {
failMsg =
"Error occured while parsing the
input XML, please check the input.";
throw new
}
if(responseBytes ==
null) {
failMsg =
"null data received while parsing
the input XML, please check the
input.";
throw new
}
String inputStr =
null;
try {
inputStr = new
String(responseBytes, "UTF-8");
log.info("inputStr : " +
inputStr);
}
catch(UnsupportedEncodingException
e) {
failMsg =
"Please check the encoding attribute
value of the input XML, it should be
UTF-8.";
throw new
}
return inputStr;
}
}
After getting the input String, we can use this input String to do the
necessary operations such as database retrieval or update. After
performing the necessary operations according to business need, we now
have an output file let's say output.xml. In this article I have used an
output String created from an output.xml for an illustration and in a
real application this output can be any String generated by any process.
Now our goal is to return this result to the client as an appropriate
attachment i.e., if the input is DIME attachment we have to return the
output String as a DIME attachment and if the input is a MIME attachment
we have to return output String as a MIME attachment. Listing 6 shows the
procedure to send the output String as a DIME attachment.
Listing 6. Sending output as a DIME attachment.
log.info("setting the DIME

type of attachment as the
sender sends it as
DIME.");
rspmsg.getAttachmentsImpl(
).setSendType(org.apache.a
xis.attachments.Attachment
s.SEND_TYPE_DIME);
ByteArrayDataSource
dataSource = new
ByteArrayDataSource(result
, "UTF-8");
dh = new
DataHandler(dataSource);
return dh;
Listing 7 shows the procedure to send the output String as a DIME

attachment.
Listing 7. Sending output as a MIME attachment.
log.info("setting the
MIME type of attachment
as the sender sends it as
MIME.");
rspmsg.getAttachmentsImpl
().setSendType(inputAttac
hmentType);
// Create temp file.
File temp =
File.createTempFile("Mime
Output", null);
// Delete temp file when
program exits.
temp.deleteOnExit();
// Write to temp file
BufferedWriter out = new
BufferedWriter(new
FileWriter(temp));
out.write(result);
out.close();
dh = new DataHandler(new
FileDataSource(temp));
You might be wondering why a temporary file is used in case of a MIME

attachment. Technically whether it is a DIME or MIME the same code
should work in the context of creating an output DataHandler object.
But, when using the Apache axis implementation it will not work for MIME
attachment. If we use the same procedure we will get
javax.mail.MessagingException. I observed this problem with Apache AXIS,
you might not get the problem with other implementations and in that
case you can use the same code for both DIME and as well as MIME
attachments. This might be a bug in one of the open source
implementation and the work around for this is to use a temporary file
for constructing DataHandler and of course these temporary files will be
deleted whenever the server restarts if you use the above code.
Deployment of web Service
After developing the web service it is time to build the war file and deploy the
application. The src.zip file contains all the source code. The required jar files are
activation.jar, axis.jar, commons-discovery.jar, commons-logging.jar, jaxrpc.jar,
log4j.jar, saaj.jar, soap.jar and wsdl4j.jar. I used Maven to build the war file and you can
find more info on Maven at maven site. You can find the actual version of the jar files
used in project.xml in my source distribution. You can build the war file by using your
favorite build procedure, but make sure that you include all the required jar files in the
final war distribution. Once you have the war file, you can just deploy on any web server.
I have used Tomcat as the web server. After you deploy the war file in Tomcat, you will
see an error in the AttachmentService.log file saying 'unable to find the config file'. Do
not worry about it, we are going to create server-config.wsdd by using the deploy.wsdd
file. Listing 8 shows the contents of deploy.wsdd file.
Listing 8. Contents of deploy.wsdd file.
<deployment
xmlns="http://xml.apa
che.org/axis/wsdd/"
xmlns:java="http://xm
l.apache.org/axis/wsd
d/providers/java"
xmlns:ns1="Attachment
Service">
<service
name="AttachmentServi
ce"
provider="java:RPC">
<parameter
name="className"
value="webservices.at
tachments.AttachmentS
ervice"/>
<parameter
name="allowedMethods"
value="getDimeData,ge
tMimeData"/>
<operation
name="getDimeData"
returnQName="returnqn
ame"
returnType="ns1:DataH
andler">
<parameter
name="dh"
type="ns1:DataHandler
"/>
</operation>
<operation
name="getMimeData"
returnQName="returnqn
ame"
returnType="ns1:DataH
andler">
<parameter
name="dh"
type="ns1:DataHandler
"/>
</operation>
<typeMapping
deserializer="org.apa
che.axis.encoding.ser
.JAFDataHandlerDeseri
alizerFactory"
languageSpecificType=
"java:javax.activatio
n.DataHandler"
qname="ns1:DataHandle
r"
serializer="org.apach
e.axis.encoding.ser.J
AFDataHandlerSerializ
erFactory"
encodingStyle="http:/
/schemas.xmlsoap.org/
soap/encoding/"/>
</service>
</deployment>
After installing axis application on Tomcat web server, execute the

following command in /src/conf/ directory.
On Windows
java -cp %AXISCLASSPATH%
org.apache.axis.client.AdminCl
ient
-lhttp://localhost:8080/axis/s
ervices/AdminService
deploy.wsdd
On UNIX
java -cp $AXISCLASSPATH
org.apache.axis.client.AdminCl
ient
-lhttp://localhost:8080/axis/s
ervices/AdminService
deploy.wsdd
Please follow the guidelines listed on the axis user guide at Installing new
WebServices.
Running the above command creates the server-config.wsdd file in the

webapps/AttachmentServices/WEB-INF directory. If you have trouble creating WSDD
file, you can just use the server-config.wsdd file included in the source distribution as it
is. If you reached this stage means our web service is ready to be accessed for outside
world. You can check WSDL file for this service at
http://localhost:8080/AttachmentServices/services/AttachmentService?wsdl. If you
encounter an error, it may be caused by problem during deployment of the war file or
running the AdminClient. Double check all the steps listed in axis installation user guide.
Client implementation
Once the web service is ready we can write a client application for accessing this. There
are two approaches for building the client application. One is to create some wrapper
classes using some utility classes provided by axis and using these wrapper classes you
can create simple main method. Another approach is to write a client application on your
own. I used the latter approach because it will be more useful in understanding what
parameters were actually passed to the Call object before invoking the web service.
Practically, I found it to be more useful to know what is happening rather than using the
wrapper classes generated by some utility classes.
First, create the org.apache.axis.client.Call object as shown in Listing 9 :
Listing 9. Creating Call Object for the service.
Service service =
new Service();
Call call = (Call)
service.createCall
();
After creating the call object, set various parameters that are needed
before accessing the service as shown in Listing 10 :
Listing 10. Client program to access the web service.
private static void

testDataRetrieval(Call
call, String
operation) throws
IOException {
//Set the
target service host
and service location.
call.setTargetEndpoint
Address(new
URL(WEB_SERVICE_URL));
//This is the
target services method
to invoke.
call.setOperationName(
new
QName(WEB_SERVICE_NAME
, operation));
QName
qnameAttachment = new
QName(WEB_SERVICE_NAME
, "DataHandler");
DataHandler
dhSource = new
DataHandler(new
FileDataSource(INPUT_X
ML));
call.registerTypeMappi
ng(dhSource.getClass()
, //Add serializer for
attachment.
qnameAttachment,
JAFDataHandlerSerializ
erFactory.class,
JAFDataHandlerDeserial
izerFactory.class);
call.addParameter("sou
rce", qnameAttachment,
ParameterMode.IN);
//Add the file.
call.setReturnType(qna
meAttachment);
try {
Object
ret = call.invoke(new
Object[]
{dhSource}); //Add the
attachment.
log.info("ret : " +
ret);
if(ret ==
null) {
log.info("null
response received.");
} else
if(ret instanceof
String) {
String
errorMsg =
(String)ret;
log.info("errorMsg : "
+ errorMsg);
} else
if(ret instanceof
DataHandler) {
DataHandler dh
= (DataHandler)ret;
log.info("dh.getName()
: " + dh.getName());
byte[]
responseBytes =
Utils.getBytesFromData
Handler(dh);
log.info("responseByte
s length : " +
responseBytes.length);
String
responseStr = new
String(responseBytes,
"UTF-8");
log.info("responseStr
: " + responseStr);
}
}
catch(RemoteException
e) {
log.error("AttachmentS
erviceException :" ,
e);
}
}
As seen in the client code in the source distribution, the only difference
between sending a DIME attachment and a MIME attachment is setting
Call.ATTACHMENT_ENCAPSULATION_FORMAT property.
Conclusion
As I have shown in this article, writing a web service that can handle attachments and the
client to access the web service using Apache Axis implementation is not a very difficult
task, but there is not enough documentation at one place to accomplish this complete
task. Even though this article talks about deploying in Tomcat web server, it should work
on any J2EE web server. All you need to do is to deploy the war file on the server and
create server-config.wsdd.
Download
Download the source code of this article: Source Code
Resources
 For more information on Apache Axis and installation, refer to Axis Installation.
 For more information on processing attachments using JAX-RPC handlers, refer
to Process attachments using JAX-RPC handlers.
 For creating web services with Apache Axis, refer to Creating Web services with
Apache Axis.
 For more information on DIME attachments, refer to an article on DIME

attachments.
Building a Simple Web Service – A Tutorial
 By Jeevaraj Gnanaselvan Dhanaraj (jeevaraj_1970@yahoo.com)
(Jeeva has over 7 years of experience in designing and developing enterprise class
web applications using JAVA and J2EE technologies.
He currently works for Itreya Technologies, Bangalore, leading a team of over 10
programmers and designers, developing a multi-user, distributed, web-based
workflow application)
 Introduction
In this tutorial we will create a simple web service and a client web application using
eclipse IDE along with Lomboz plug in. We will also deploy and test the web service on
Tomcat 5.5.4 web application server. This application, while simple, provides a good
introduction to Web service development and some of the Web development tools
available.
 Environment
J2SDK 1.4.2
http://java.sun.com/
Eclipse 3.1
http://www.eclipse.org/
Tomcat 5.5.4
http://tomcat.apache.org/
Lomboz 3.1RC2
http://lomboz.objectweb.org/
 Installation
Install JDK (in D:\j2sdk1.4.2_04)
Install Tomcat (in E:\Tomcat5.5)
Install Eclipse (in E:\Eclipse3.1)
Install Lomboz (in E:\Eclipse3.1)
 Setting up
1. Set up the installed JRE in eclipse (Windows -> Preferences -> Java -> Installed JREs)

2. Set up the installed runtime for server in eclipse (Windows -> Preferences -> Server ->
Installed Runtimes)

3. Set up the Server view in eclipse (Windows -> Show View -> Other)

4. Set up the Tomcat Server by right clicking and selecting New -> Server option from the
Server view in eclipse

 Creating a Web service
1. Create a new Dynamic Web Project in eclipse (File -> New -> Other)

2. Enter name as “WebServiceTutorial”, select project location as “E:\Test” and select

Apache Tomcat v5.5 as the Target server.

3. Now create a new Java class from the Project Explorer (Dynamic Web Projects -> Java
Source -> New -> Class)

4. Enter name as “Hello” and package as “com.tutorial”.
5. Add a simple method in the “Hello” class as below.
public String sayHello(String name){
return "Hello " + name;
}

6. Save and build the project.

7. Create a new Web service in eclipse (File -> New -> Other)
8. Select Generate a proxy.

9. Select Test the Web service.
10. Select Overwrite files without warning.

11. Select or enter the Bean name as “com.tutorial.Hello”. This is the java class that we just
now created.

12. Continue the wizard by clicking Next and finish.

13. On Finish, the Tomcat server starts up and launches the Test client.
14. Verify the generated contents. Look for Hello.class and the generated JSPs as below.

15. Verify the Tomcat folder and ensure the newly created web applications –
WebServiceTutorial, WebServiceTutorialClient.

16. We can also run the following url from the browser to access/test the Web service.
http://localhost:8080/WebServiceTutorialClient/sampleHelloProxy/TestClient.jsp
17. If servlet error “org.eclipse.jst.ws.util.JspUtils cannot be resolved or is not a type” is

thrown on the browser, then copy the webserviceutils.jar file from the E:\Eclipse3.1\
eclipse\plugins\org.eclipse.jst.ws.consumption_0.7.0 into the WEB-INF\lib folder of the
WebServiceTutorialClient application and restart the Tomcat server.
18. The browser displays the methods available in the web service.

19. Click on the sayHello(..) method, enter your name (for e.g. “Jeeva”) in the inputs section
and click “Invoke”.
20. The browser greets using the web service.

21. The WSDL for the Hello Web service can be found in E:\Test\WebServiceTutorial\
WebContent\wsdl\Hello.wsdl. On double-click, the WSDL opens in a graphical editor.

22. Right-click on the WSDL file and explore the options to test the web service / publish the
WSDL file / generate client / etc.

 Conclusion
In this tutorial we learned how to create a simple web service and a client web application
using eclipse IDE along with Lomboz plug in. We also deployed and tested the web service
on Tomcat 5.5.4 web application server. This application, while simple, provides a good
introduction to Web service development and some of the Web development tools available.
WEBSERVICE USING APACHE AXIS TUTORIAL-1

Using Java XML-WEBSERVICE from ASP.net.
( published in DeveloperIQ January-2004)( www.developeriq.com)
R.S.RAMASWAMY (rs.ramaswamy@gmail.com)
Sri.Manoj Kothale, has written a fine piece in DeveloperIQ(Nov'03) on exposing an EJB
as an XML-WebService, using Axis and JBOss. In this experiment, we attempt exposing
a javabean (jws) from Tomcat/Axis and consuming that service in an ASP.net
program.This is much simpler.
Inter-operability is one of the two aims of Xml-webservice paradigm,while the other aim
is tackling the firewall problem. (Since ASP.net runs only in Win2000, switch over to
Win2000. before beginning this experiment).The emphasis is on the procedure, in
laboratory experiment fashion).
Kindly , ensure that correct versions of software , are used, as mentioned.It is presumed
that DotNet SDK has already been installed and tested,for running asp.net programs.
1) axis1.1 was installed in c:\axis11
2) tomcat4.1 from march-2003 issue of Dev IQ.
was installed as c:\tomcat41
3) We will find a folder named 'axis' in c:\axiss11\webapps.
Copy this ('axis') folder to c:\tomcat41\webapps folder.
4) We must copy activation.jar to:
c:\tomcat41\webapps\axis\web-inf\lib folder. (This file is available in jboss3.2\

server\all\lib folder
and jboss3.2 was given in NovemberCD.)
5) We set JAVA_HOME for tomcat as follows:
c:\tomcat41\bin>set JAVA_HOME=D:\jdk141 (because, we have installed

jdk1.4.1 in D-drive).
6) We should uncomment the 'admin servlet' part in
the web.xml file in c:\tomcat41\webapps\axis\web-inf folder.
7) We start tomcat server:
c:\tomcat41\bin>startup
8) This starts tomcat4.1 and we wait till, it is fully started.
9) We create our own folder c:\axisdemo

In this folder, we create a simple javabean greeter.java as given below.
// c:\axisdemo\greeter.java
public class greeter
{
public String greetme(String s)
{
return "How are you?……………….."+s;
}
}
10) we copy greeter.java as greeter.jws
into c:\tomcat41\webapps\axis folder.
(we did this while tomcat41 was running!).No problem!
11) We start the browser and type the URL as:
'http://localhost:8080/axis/greeter.jws'
and we get a link to the wsdl file for the above service. When we click this link,
we get a wsdl file .
(wsdl -> webservice description language).
12) We save this wsdl file in d:\inetpub\wwwroot folder as greeter.wsdl
13) Our aim is to create a C# file from this wsdl file.
The following command does that.
d:\inetpub\wwwroot>wsdl greeter.wsdl
This command created greeterService.cs file!
( carefully note that the name has been appended with 'Service')
The next step is to compile this source file into a dll.
14)..wwwroot>csc /t:library
/r:System.dll,System.Web.Services.dll,System.Xml.dll
greeterService.cs
(type this in continuous line).
( t -> target & r -> reference)
This command created greeterService.dll
15) Now copy this dll file to d:\inetpub\wwwroot\bin folder.
( If there is no such 'bin' folder create it.).
Now create greeterService.aspx as given below.
( in d:\inetpub\wwwroot folder)
<%@ page language="c#" %>
<script runat=server>
public void job1(Object o, EventArgs e)
String a = text1.Text;
greeterService greeter = new greeterService();
String s = greeter.greetme(a);
Response.Write(s);
}
</script>
<html>
<body>
<form runat=server>
<asp:Textbox id=’text1’ runat=server />
<asp:Button onclick=job1 text="Click" runat=server />
</form>
</body>
</html>
( Normally, IIS-5 will be running . If not, start it.)
After this, type the URL in browser as:
'http://localhost/greeterService.aspx'
Remember that the tomcat server is running and supplying the 'greeter.jws'.
After some delay ( due to compiling time), we get a form.Type your name in the textbox
( say, ‘sam’ )& click the button to invoke the service. We get 'How are you?…..sam’
message from the java web service. We get correct result . We can also create a
standalone C# client by just appending a main() to the greeterService.cs and naming it as
‘greeterConsole.cs’.
Ref: AXIS..by RominIrani & JeelaniBasha (wrox press). Tutorual-2 continues in

axis2a.htm
Visit http://in.geocities.com/rsramsam
WEBSERVICE USING APACHE AXIS -TUTORIAL-2

UNDERSTANDING APACHE AXIS
(part-1)(published in DeveloperIQ..April,2004) (www.developeriq.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

(part-2)
published in DeveloperIQ..April,2004) (www.developeriq.com)
R.S.RAMASWAMY(rs.ramaswamy@gmail.com)
Creating and testing an EJB in WebLogic Server.Let us begin by creating our working
folder as
c:\sam.
We then edit the three files for EJB in that folder.
sqlremote.java
sqlhome.java)
sqlbean.java
// sqlremote.java
import javax.ejb.*;
import java.rmi.*;
public interface sqlremote extends EJBObject
public String showdata(String s) throws RemoteException;
//sqlhome.java
import javax.ejb.*;
import java.rmi.*;
public interface sqlhome extends EJBHome
public sqlremote create() throws RemoteException,CreateException;
// sqlejbbean.java
import java.sql.*;
import javax.ejb.*;
import java.rmi.*;
import javax.naming.*;
public class sqlejbbean implements SessionBean

{
public sqlejbbean()
{}
public String showdata(String s)
{
String r=" ";
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
String url="jdbc:odbc:dbdemo";
Connection con=DriverManager.getConnection(url);
Statement st=con.createStatement();
ResultSet rs=st.executeQuery(s);
while(rs.next())
{
r=r+rs.getString(1)+"\n"+rs.getString(2)+"\n"+"-------";
}
}catch(Exception e1)
{System.out.println(" "+e1);}
return r;
}
public void ejbCreate() {}
public void ejbRemove() {}

public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
}
Please note that Weblogic7 will work only in Windows 2000. So, we are now working in
Windows 2000.
Let us now set HOMEPATH & CLASSPATH.
c:\sam>set JAVA_HOME=d:\jdk1.4.2
(We have installed jdk1.4.2 in d :\)
c:\sam>set WL_HOME=d:\bea\weblogic700
c:\sam>set path=c:\windows\command;d:\ jdk1.4.2\bin;
d:\bea\weblogic700\server\bin;
c:\sam>set classpath=c:\sam;
d:\bea\weblogic700\server\lib\weblogic.jar;
We now compile files in c:\sam folder.
c:\sam>javac *.java
Create a subfolder named META-INF as follows:
( it should be capital letters!)
c:\sam>md META-INF
c:\sam>cd META-INF
c:\sam\META-INF>
In META-INF folder, create the following two Deployment-Descriptor files (XML
files). These files are MOST IMPORTANT. XML files are case-sensitive.
// ejb-jar.xml
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC
"-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN"
"http://java.sun.com/dtd/ejb-jar_1_1.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>sqlejbbean</ejb-name>
<home>sqlhome</home>
<remote>sqlremote</remote>
<ejb-class>sqlejbbean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
//weblogic-ejb-jar.xml
<!DOCTYPE weblogic-ejb-jar PUBLIC
"-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN"

"http://www.bea.com.servers/wls700/dtd/weblogic-ejb-jar.dtd">
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>sqlejbbean</ejb-name>
<jndi-name>sqlejbJndi</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
Now, revert back to c:\sam folder.
Create the jar file as follows:
sam>jar cf sql.jar *.class META-INF\*.xml
This command will create sql.jar.
The next step is to create sql1.jar for deployment in weblogic server.
sam>java weblogic.ejbc sql.jar sql1.jar
This will create sql1.jar. We may get some warning messages, which can be ignored.
Finally, we get the message ‘ejbc successful’.
Now copy sql1.jar to the following folder:
d:\bea\user_projects\mydomain\Applications Start weblogic server by the following

procedure:
Startmenu->programs->
bea weblogic platform->user projects->mydomain->startserver
Give username: system
password: administrator
Wait till you get the message: ‘started for Running mode’. Minimize this window. That
completes the job of deployment in ejb server. We should now create a console-mode
client for the ejbean
// sqlConsoleClient.java
import java.ejb.*;
import java.rmi.*;
import javax.rmi.*;
import java.io.*;
import java.util.*;
public class sqlConsoleClient
public static void main(String args[])
{
try
{
Properties props=new Properties();
props.put
(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
String url="t3://127.0.0.1:7001";
props.put(Context.PROVIDER_URL,url);
Context context=new InitialContext(props);
System.out.println("context ok..");
sqlhome home=(sqlhome)context.lookup("sqlejbJndi");
System.out.println("home ok..");
sqlremote remote=home.create();
System.out.println("remote ok..");
a=remote.showdata(s);
System.out.println(a);
}
catch(Exception e1)
{System.out.println(“”+e1);}
}
}
Now compile the client file:
C:\sam>javac sqlConsoleClient.java
Let us now run the client program:
>java sqlConsoleClient “select * from table1”
We will get a few names and numbers.We now proceed to create the jsp file .
// sqljspclient.jsp
<html>
<body>
<%@ page import=”javax.ejb.*” %>
<%@ page import=”java.rmi.*” %>
<%@ page import=”javax.rmi.*” %>
<%@ page import=”javax.naming.*” %>
<%@ page import=”java.util.*” %>
<%@ page import=”java.io.*” %>
<%
String sql= request.getParameter(“text1”);
Out.println(“please wait”);
props.put
String url="t3://127.0.0.1:7001";
out.println(a);
%>
</body>
</html>
Create the corresponding html file to invoke the above jsp.
// sqljspclient.htm
<html>
<body>
<form method=post
action=’sqljspclient.jsp’ />
sql
<input type=text name=’text1’ size=60>
<input type=submit>
</form>
</body>
</html>
We have installed tomcat3.2 in e: drive. Copy sqljspclient.jsp & sqljspclient.htm to e:\

tomcat\webapps\root.
To start the tomcat server, cd to
e:\tomcat\bin>set JAVA_HOME=D:\JDK1.4.2
>SET CLASSPATH=%CLASSPATH%;c:\sam;
d:\bea\weblogic700\server\lib\weblogic.jar
>startup
This will start the webserver. Start the browser and type the URL
as:‘http://localhost:8080/sqljspclient.htm’. We get a form. Type the sql and submit. We
get the correct result (tested and found ok). Thus, we have created a stateless session
EJB, tested it in console mode and also as a jsp deployed in tomcat3.2. We now proceed
to expose our ejb as an XML-WebService, using AXIS by two methods:
a. as *.jws (known as Drop-in Deployment).( part-3)

b. by using wsdd file etc.(part-4)
The next article discusses these aspects in detail.
Continued in axis2c.htm Visit http://in.geocities.com/rsramsam

(part-3) (published in DeveloperIQ..April,2004)(www.developeriq.com)
R.S.RAMASWAMY(rs.ramaswamy@gmail.com)
DROP-IN DEPLOYMENT IN AXIS
First and foremost, we need to install Axis1.1 for Windows, in our system. The January
2004 issue of DeveloperIQ dealt with Apache and the CD also carried a lot of Apache
software. But ‘Axis1.1 for windows’ was missing there. So, we have to download it
from the Apache website (http://xml.apache.org).It has been installed as c:\axis11. (The
unzipped folder is about 30MB.).
Secondly, we need tomcat4.1, for deploying axis. (It has been given in the March-2003
CD of DeveloperIQ.) It has been installed as d:\tomcat41.
We will find a folder, named ‘axis’ in ‘c:\axis11\webapps’ directory.Copy this ‘axis’

folder to: ‘d:\tomcat41\webapps’ directory.
We need ‘activation.jar’. Copy activation.jar to:
d:\tomcat41\webapps\axis\web-inf\lib’
(tomcat4.1\common\lib)
After completing these preliminary steps, we create ‘sqlaxisbean.java’ in c:\sam folder,

as given. (If we carefully study the code for the ConsoleClient, jsp and this bean, we will
find that all of them are similar.)
// sqlaxisbean.java
import java.sql.*;
import java.util.*;
import javax.ejb.*;
import java.rmi.*;
public class sqlaxisbean
{
String a;
public sqlaxisbean()
{
a="";
}
public String callejb(String s)
{
try
{
props.put
String url="t3://127.0.0.1:7001";
return a;
}
As we are now studying ‘Drop-in Deployment’, we just copy this source file’ into: ‘d:\
tomcat41\webapps\axis’ folder as ‘sqlaxisClient.jws’ Carefully note that we have
changed the file extension from *.java to *.jws.
Let us now start tomcat4.1 as follows:
d:\tomcat41\bin>set JAVA_HOME=D:\JDK141
d:\tomcat41\bin>
set path=c:\windows\command;d:\jdk141\bin;
d:\tomcat41\bin>startup
After the tomcat server is fully started (you get the messages as ‘jk running’) we can test
out Axis installation over tomcat as follows: Start the browser and type the URL
as:‘http://localhost:8080/axis/index.html’.We get the Axis welcome page:
If we type the URL as:‘http://localhost:8080/axis/AxisServlet’, we get another page

saying: ‘there is a webservice here’.After satisfying ourselves that things are alright, we
type the URL as: ‘http://localhost:8080/axis/sqlaxisbean.jws’. We get a link and when
we click on this link, we get a wsdl file automatically generated. This is an XML file.
Search this file to checkup whether the name of our method, namely ‘callejb’ occurs
there. It will be there! So, our ejb axis service is up and running. It is now time to create
a simple Console-Client in java to satisfy ourselves that our ejb is really available to be
accessed by using the wsdl file.
So, we now create the Console-Client for the webservice as shown.
// sqlaxisbeanClient.java
import java.net.*;
import javax.xml.rpc.ParameterMode;
import org.apache.axis.client.Service;
import org.apache.axis.client.Call;
import org.apache.axis.encoding.XMLType;
import javax.xml.namespace.QName;
public class sqlaxisbeanClient
{
{
try
{
System.out.println("Start");
Service service= new Service();

System.out.println("Service ready");
Call call= (Call)service.createCall();
System.out.println("call ready");
URL url=new URL("http://localhost:8080/axis/sqlaxisbean.jws");
call.setTargetEndpointAddress(url);
call.setOperationName("callejb");
call.addParameter("something", XMLType.XSD_STRING,ParameterMode.IN);
call.setReturnType(XMLType.XSD_STRING);
String r = (String)call.invoke(new Object[]{args[0]});
System.out.println(r);
}
catch(Exception e1){System.out.println(""+e1);}
}
}
We have to set correct classpath for the window to include a number of files required for
Axis.As it will be tedious to type it every time, we have created a batch file named
‘setcpath.bat’. Please note that it should be typed in a single line continuously as
given.
// setcpath.bat
set classpath=c:\sam; d:\bea\weblogic700\lib\weblogic.jar;
c:\axis11\lib\axis.jar;
c:\axis11\lib\jaxrpc.jar;
c:\axis11\lib\saaj.jar;
c:\axis11\lib\commons-logging.jar;
c:\axis11\lib\commons-discovery.jar;
c:\axis11\lib\wsdl4j.jar;
c:\tomcat4.1\common\lib\activation.jar;
c:\tomcat4.1\common\lib\xerces.jar
After creating this file, we can simply type at the prompt,sam> setcpath. This will
create the correct classpath for the working window. We will now be able to compile
jwsclient.java. After compiling, we can execute the program:>java jwsclient “select *
from table1”. We will get names and numbers. This was tested and found to be ok.Thus,
we have developed and ejb, and accessed it as an xml webservice!
In the next article of this seven-part tutorial, we will take up the wsdd method.
Continued in axis2d.htm
visit http://in.geocities.com/rsramsam

(part-4)(published in DeveloperIQ..April,2004) (www.developeriq.com)
APACHE AXIS-DEPLOYMENT USING WSDD FILE
In this part, we will follow the WSDD method. We have already created
sqlaxisbean.java as explained in the last article. We used it as sqlaxisbean.jws (drop-in
method). There was no necessity to compile this file.But in WSDD method (web-service
deployment descriptor), we should compile this file.Next, we create the WSDD file.
Then, we deploy this bean to tomcat. We may have to restart the tomcat4.1 webserver.
We can then create a java-console client and test the webservice. So, this is the step-by-
step procedure. We will now go into the details involved here.We are now in c:\sam.
We give correct path, classpath etc. as in part-3.

set path=c:\windows\command;d:\jdk141\bin;
style='border-collapse:collapse;border:none;mso-border-alt:solid windowtext .5pt; mso-

yfti-tbllook:480;mso-padding-alt:0in 5.4pt 0in 5.4pt;mso-border-insideh: .5pt solid
windowtext;mso-border-insidev:.5pt solid windowtext'>
// setcpath.bat
set classpath=c:\sam; d:\bea\
weblogic700\lib\weblogic.jar;
c:\axis11\lib\commons-
logging.jar;
c:\axis11\lib\commons-
discovery.jar;
c:\tomcat4.1\common\lib\
activation.jar;
c:\tomcat4.1\common\lib\xerces.jar
// sqlaxisbean.java
import java.sql.*;
import java.util.*;
import javax.ejb.*;
import java.rmi.*;
public class sqlaxisbean
String a;
public sqlaxisbean()
{
a="";
}
public String callejb(String s)
{
try
{
props.put
String url="t3://127.0.0.1:7001";

return a;
}
c:\sam>javac sqlaxisbean.java
so we get sqlaxisbean.class.
Copy this file to ‘d:\tomcat4.1\axis\web-inf\classes’ folder. (Note the difference from

part-3 carefully.
In part-3, we just copied the file ‘sqlaxisbean.java’ to d:\tomcat4.1\webapps\axis folder.

But, now we copy the class fil e to ‘d:\tomcat4.1\axis\web-inf\classes’ folder. We
should now restart the tomcat server. Next, we create the WSDD file in c:\sam folder
Carefully note the following values that we have given:
a. service name “ejbsqlaxis”
b. provider “java:RPC”
c. class name “sqlaxisbean”
d. method name “callejb”
//c:\sam\sqlaxis.WSDD
<deployment
xmlns=”http://xml.apache.org/axis/WSDD/”
xmlns:java=”xml.apache.org/axis/WSDD/providers/java” >
<service name=”ejbsqlaxis”
provider=”java:RPC” >
<parameter name=”className”
value=”sqlaxisbean” />

<parameter name=”methodName”
value=”callejb” />
</service>
<deployment>
In Axis, a provider (also known as a pivot handler) is used for invoking the webservice
class.
Axis provides the following provider types
i. RPC-based provider java:RPC
ii Message-based provider java:MSG
iii EJB provider java:EJB
(Currently, work is going on for developing COM provider.)
In the present demo, we are using RPC based provider.The next step is to deploy the bean
in tomcat server. Please refer to page 38 of Axis by Romin Irani & Geelani Basha.
WROX Press for further details.
c:\sam>java
org.apache.axis.client.AdminClientsqlaxis.WSDD
lhttp://localhost:8080/axis/services/AdminService
(Note: This is ‘l’ as in long and not ‘one’.)
(Remember that tomcat should be running. If tomcat server is not running, this command
won’t work.)Wait till the message ‘Done Processing’ is displayed. It is essential to verify
whether the bean has really been deployed correctly by the following command:
c:\sam>java org.apache.axis.client.AdminService list
–lhttp://localhost:8080/axis/services/AdminService
We will get the WSDD files of all the beans deployed. (If there are too many items, we
can send the result to log.txt by the command :> (as before)> log.txt .We can then see
log.txt and locate the ejbsqlaxis service, its classname and method name.Actually, our
job is over. We can, now checkup, whether the bean is available as a webservice typing
the URL in browser as: ‘http://localhost:8080/axis/services/Ejbsqlaxis?wsdl’
(ejbsqlaxis is the name given by us as the name of service in the WSDD file.) We will
get the wsdl file (an xml file).Search for the occurrence of the port-type name as
‘sqlaxisbean’ and operation name as ‘callejb’.If these are found, it means that everything
is fine.
Now we want to check up whether we can really use this service. For this, we create the
following java console-mode program .
style='background:maroon;border-collapse:collapse;border:none;mso-border-alt: solid
windowtext .5pt;mso-yfti-tbllook:480;mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-border-
insideh:.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>
// sqlaxisconsoleclient.java
import java.net.*;
import javax.xml.rpc.
ParameterMode;
import org.apache.axis.client.
Service;
import org.apache.axis.
client.Call;
import org.apache.axis.
encoding.XMLType;
import javax.xml.
namespace.QName;
public class
sqlaxisconsoleClient
public static
void main(String args[])

{
try
{
System.out.println
("Start");
Service service= new

Service();
System.out.println
("Service ready");
Call call=

(Call)service.createCall();
System.out.println
("call ready");
URL url=new

URL("http://localhost:
8080/axis
/services/ejbsqlaxis");
// the last parameter is
service name & not class name!
call.setTargetEndpointAddress(url);
call.setOperationName("callejb”);
call.addParameter
("something", XMLType.XSD_STRING,
ParameterMode.IN);
call.setReturnType
(XMLType.XSD_STRING);
String r=
(String)call.invoke(new Object[]
{args[0]});

System.out.println(r);

{System.out.println(""+e1);}
}
If you carefully compare this file with the earlier jwsclient.java, you will find that except
for the URL of the end-point, everything else is the same.We now compile this file.
c:\sam>javac sqlaxisconsoleclient.java
This compiles correctly.We can run this program:
c:\sam>java sqlaxisconsoleclient “select * from table1 where name like ‘d%’ “
We get the correct result. Now just a little explanation for the code!
1. We begin by defining the endpoint URL, which specifies the actual location of
WEBSERVICE.
2. We specify the method name, then we create an instance of service and create CALL
object for a service. We set URL and method name for this CALL object.
3. ‘addParameter’ method takes three parameters, viz.,
a. A user-defined name for the parameter (“sql” in our example).
b. Parameter datatype.
c. Whether the parameter is input parameter or output parameter.
4. It is now required to set the return type.

5. Finally, we invoke the call
That completes the fourth part of this tutorial. In the next month’s issue, we will directly
use the EJB class files in WSDD file and invoke the EJB as webservice without using
sqlaxisbean.
Continued in axis3.htm
WEBSERVICE USING APACHE AXIS - TUTORIAL-2

AXIS FOR EJB-WEBSERVICE (part-5)
DeveloperIQ..APRIL-2004 www.developeriq.com
In DeveloperIQ ( March-2004) , we had seen parts 1 to 4 of this tutorial on exposing an

EJB as XML-Webservice using Axis. This is a 7 part article.
part-1 : Overview
part-2 : deploying ejb in weblogic-7
part-3 : Drop-in-deployment in Axis
part-4 : deloyment using wsdd for javabean.
part-5 : using wsdd file for ejb-bean itself)
a) java:RPC
b) java:EJB
part-6 : WAP client
a) for EJB
b) for EJB-WebService

part-7 : J2ME Client
a) for EJB
b) for EJB-WebService
We now proceed to complete the remaining parts.
Part-5 ( using wsdd file for ejb-bean itself).
In part-4, we created a javabean to accessthe EJB in weblogic enterprise server and usedit
in the wsdd file.This approach is preferable because, the best method is to use a stateless-
session bean to access other beans in the ejb-server.This is known as 'Facade pattern'.
"It is entirely possible to package your business logic into Java Beans and not worryabout
the EJB API.However,as your business logic becomes more complex ,requiring the
coupling of the logic with enterprise functionality like transactions,resource management
etc, the benefits of the EJB architecture rapidly become apparent.The EJB container can
provide all these system-level services(lifecycle management,connection
pooling,transations,etc)leaving the developer to concentrate on developing thebusiness
logic". Secondly, "Utilizing existing applications is the key inan enterprise scenario. It is
important thatexisting business functionality in EJB components within the J2EE
Application can be invoked in a seamless fashion."
---Romin Irani in "AXIS".
This argument against using EJB, surfaces again and again from different quarters often.
For instance, Perl programmers who want to use XML-Webservice also argue that
simple functions will do. Hence, it is worthwhile
to learn the opinion of experts on SOAP on this question. "Intersection of Business and

Programming
(quoted from: Programming web service with SOAP
by James Snell,Doug Tidwell and Pavel Kulchenko)
(James Snell : is a software engineer at IBM's Emerging Technologies team.(Doug

Tidwell is a senior programmer at IBM.(Pavel Kulchenko is an open-source developer.
best known for his Soap::Lite.,XMLRPC::Lite 7
UDDI::Lite modules for Perl.)
"Because a web service exposes an application's functionality to any client in any

programming language,they raise interesting questions in both the programming and the
business world.Programmers tend to raise questions like, "how do we do two-phase
commit transactions?" orHow do I do object inheritance?" or" How do I make this damn
thing run faster?"-questions typically associated with going through the steps of writing
code.
Business folks,on the other hand,tend to ask questions like,"How do I ensure that the
person using the service is really who they say they are?" or "How can we tie together
multiple web services into a workflow?" or "How can I ensure the realiability of web
service transactions?" Their questions typically address business concerns.
These tow perspectives go hand-in-hand with one another. Every business issue will
have a software-based solution. But the two perspectives are also at odds with each
other:the business processes demand completeness, trust, security, and reliability, which
may be in incompatible with the programmers goals of simplicity, performance, and
robustness.
The outcome is that tools for implementing webservices will do so from one of thesse
two angles,but rarely will they do so from both.For example ,SOAP::Lite,the perl based
SOAP implementation written by the coauthor of this book,Pavel kulchenko,is essentially
written for programmers.It provides a very simple set of tools for invoking Perl modules
using SOAP,XML-RPC,jabber,or any number of other protocols.
In contrast,Apache's Axis project(the next generation of Apache's SOAP implemention)is

a more complex web services implementaion designed to make it easier to implement
processes,or to tie together multiple web services. Axis can perform the stripped down
bare essentials,but that is not its primary focus.
The important thing to keep in mind is that both tools implement many of the same set of
technologies(SOAP,WSDL,UDDI, and others,many of which we discuss later on),and so
they are capable of interoperating with each other.The differences are in the way they
interface with applications.This gives programmers a choice of how their web services is
implemented,without restricting the users of that service."
Reverting back to our main theme now, some developers prefer to use the Enterprise-
bean itself directly in the wsdd file as is about to be shown below.
Here again, there are two possibilities. We can use either
a) java:RPC as pivot-handler
(or)
b) java:EJB as pivot-handler
There will be some important differences
in the way in which the wsdd file is created.

and these should be carefully noted.
First, we will demonstrate the java:RPC pivot-handler method . After that, we will create
another wsdd to use java:EJB pivot handler and test it .
This is our objective in this part of the tutorial..
( Kindly read this lesson, in conjunction with
earlier parts, published last month).
We have already deployed our stateless ejb
in Weblogic7.
(please refer to part-2 of this lesson).
We are going to expose an ejb as webservice
mentioning ejb classes such as
sqlRemote,sqlHome,sqlBean
directly in wsdd file.
Our current working folder is C:\>sam.
with path and classpath as shown below.
path=c:\windows\command;
d:\jdk141\bin;
d:\bea\weblogic700\server\bin;
classpath=c:\sam;
d:\bea\weblogic700\server\
lib\weblogic.jar;
c:\axis11\lib\commons-logging.jar;
c:\axis11\lib\commons-discovery.jar;
d:\tomcat 4.1\common\lib\activation.jar;
d:\tomcat 4.1\common\lib\xerces.jar;
Now create sqlDeploy.wsdd file in our
current working folder (ie)C:\sam
c:\sam> edit sqlDeploy.wsdd
<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/
axis/wsdd/providers/java" >
<service name="sqlservice"
provider="java:RPC" >
<parameter name="beanJndiName"
value="sqlJndi" />
<parameter name="homeInterfaceName"
value="sqlHome" />
<parameter name="remoteInterfaceName"
value="sqlRemote" />
<parameter name="className"
value="sqlBean" />
<parameter name="allowedMethods"
value="*" />
</service>
</deployment>
The next step is to deploy the service in Axis.Remember, that Tomcat4.1 and
Weblogic7 , have already been started.
( as given in part-2).Secondly , preliminary steps for using Axis also have been already
performed.(please refer to opening remarks in part-3 of this tutorial in March-2004 issue).
We now give the following command for deploying the service.
c:\>sam>java org.apache.axis.client.AdminClient sqlDeploy.wsdd

-lhttp://localhost:8080/axis/ services/AdminService
( this should be typed in a continuous line). (note: if tomcat server is not running, this
command won't work)
After some time, if the wsdd file is free from
syntax errors, the service will be deployed
and we will get a message as follows:
<Done Processing>
For verifying whether the service is deployed,
we give the following command.
c:\>sam> java org.apache.axis.client.AdminClient list -lhttp://localhost:8080/axis/

services/AdminService > list.txt
After this, we can see list.txt and check up
whether sqlservice has been deployed there.
We can also test the deployment by using the browser and typing the URL as:
http://localhost:8080/axis/services/sqlservice?wsdl
We will get a wsdl file. Now we've exposed our ejb as webservice.
We test this service in two ways

(ie)a) console client and
b) servlet client.
c:\sam> edit ejbaxisconsoleclient.java
// ejbaxisconsoleclient.java
import java.net.URL;
public class ejbaxisconsoleclient
{
try
{
String url = "http://localhost:8080/axis/services/sqlservice";
//Last parameter is service name in WSDD;
System.out.println ("endpoint is :"+url);
String method = "getdata";
System.out.println("method is: "+method);
Service service = new Service();
Call call = Call) service.createCall();

call.setTargetEndpointAddress ( url);
call.setOperationName
( new QName("sqlservice",method));
call.addParameter("sql",XMLType.XSD_STRING,ParameterMode.IN);
System.out.println("Call Ok");
Object[] params = new Object[] { args[0] };
System.out.println("Params ok...");
String s = (String) call.invoke(params);
System.out.println(s);
}
catch(Exception e1)
{ System.out.println(""+e1); }
}
}
c:\sam> javac ejbaxisconsoleclient.java
After it is complied successfully, run the program and pass the query as commandline
argument.
c:\sam> java ejbaxisconsoleclient "select * from table1"
We'll get the resultset as per the query.
Next we are going to test this service as a servlet.
c:>sam> edit ejbaxisservletclient.java
// ejbaxisservletclient.java
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class ejbaxisservletclient extends HttpServlet
public void doPost (HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String sql =
request.getParameter("text1");
try{
Call call = (Call) service.createCall();

call.addParameter
("sql",XMLType.XSD_STRING,ParameterMode.IN);
Object[] params =
new Object[] { sql };
out.println(s);
}
catch(Exception e) { System.out.println(""+e); }
}
c:\sam> javac ejbaxisservletclient.java
( we will be able to compile because classes required for compiling the servlet are
available in weblogic.jar , to which
we have already given classpath).
copy c:\sam\ejbaxisservletclient.class to
d:\tomcat 4.1\webapps\axis\web-inf\classes
Do not forget to edit web.xml in d:\tomcat 4.1\webapps\axis\web-inf folder( this is
very important in tomcat4.1).
<servlet>
<servlet-name>
ejbaxisservletclient
</servlet-name>
<servlet-class>
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>
</servlet-name>
<url-pattern>
\servlet\ejbaxisservletclient
</url-pattern>
</servlet-mapping>
c:\sam> edit ejbaxisservletclient.htm
ejbaxisservletclient.htm
<html>
<body>
<form method=post action="http://localhost:8080/axis/servlet/ejbaxisservletclient">
Query <input type=text name="text1">
<input type=submit>
</form>
</body>
</html>
copy c:\sam\ejbaxisservletclient.htm to d:\tomcat 4.1\webapps\axis
Make sure that tomcat server is running.Open IE and type url as 'http://localhost:8080/
axis/ejbaxisservletclient.htm' Enter sql query in the text box and submit it. we'll get the
resultset as per the query.
That completes our job!
Some developers would prefer to use java:EJB pivot-handler.Fortunately, the changes

required for that are just a few lines.First and foremost, we have to create a suitable
wsdd file. Let us call it as 'directejbdeploy.wsdd'.
// directejbdeploy.wsdd
<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<service name="dataejbservice"
provider="java:EJB">
<parameter name="beanJndiName"
value= "sqlJndi" />
<parameter name="homeInterfaceName"
value= "sqlHome" />
<parameter name="jndiContextClass"
value="weblogic.jndi.WLInitialContextFactory" />
<parameter name="jndiURL"
value="t3://127.0.0.1:7001" />
<parameter name="allowedMethods" value="*" />
</service>
</deployment>
If we carefully study the above file, we will note that the value for jndiContextClass and
jndiURL are just what we usually specify in the client file for ejb program!So, nothing
very special there!
All the classes referred to , are already available and after deploying this wsdd as usual ,
we are ready to use the service!--
So, let us deploy now:
c:\>sam> java org.apache.axis.client.AdminClient

directejbdeploy.wsdd -lhttp://localhost:8080/axis/services/AdminService
( this should be typed in a continuous line). (note that it is exactly like what we did
previously, except that the name of wsdd file is different).
After deploying, we can check up by typing the URL in browser as :
'http://localhost:8080/axis/services/dataejbservice?wsdl'
Please note that 'dataejbservice' is the name of service that we have given in the wsdd
file.As we have ensured that both tomcat4.1 &weblogic7 are running , without anything
being changed, we will get the corresponding wsdl. This shows that our webservice is
running correctly.
We now create a console-mode program in
c:\sam , as usual.
// c:\sam\ directejbconsoleclient.java
//===============================
public class directejbaxisconsoleclient
{
try
{
String url = "http://localhost:8080/axis/services/dataejbservice";
//Last parameter is service name in WSDD; not class name
System.out.println("endpoint is :"+url);
System.out.println("name of method is: "+method);
( new QName("dataejbservice",method));

}
catch(Exception e1) { System.out.println(""+e1); }
}
After compiling , we run the program as usual:
c:\sam>java directejbconsoleclient "select * from table1 "
We will get the resultset , as before.( tested and found to be ok.)
That completes part-5 of our tutorial.
So far we've accessed our ejb through console mode and servlet.Now Its time to write the
client program for wireless browsers.
This, we take up in part-6

Accessing ejb-webservice using WAP (Wireles-Application Protocol)
c:\sam> edit ejbaxiswapservlet.java
******************************************
//ejbaxiswapservlet.java
----------------------
import java.io.*;
public class ejbaxiswapservlet extends HttpServlet
public void doPost (HttpServletRequest request,
{
response.setContentType("text/vnd.wap.wml");
PrintWriter out = response.getWriter();
String sql = request.getParameter("text1");
try{

out.println("<p>");
out.println("ejb with wap<br/>");
out.println(s);
out.println("</p>");
out.println("</card>");
out.println("</wml>");
}catch(Exception e)
{ System.out.println(""+e); }
}
********************************************
Complie and copy the class file to tomcat as below.

c:\sam> javac ejbaxiswapservlet.java
copy c:\sam\ejbaxiswapservlet.class to
Edit web.xml in
d:\tomcat 4.1\webapps\axis\web-inf folder
<servlet>
<servlet-name>
ejbaxiswapservlet
</servlet-name>
<servlet-class>
ejbaxiswapservlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>
ejbaxiswapservlet
</servlet-name>
<url-pattern>
\servlet\ejbaxiswapservlet
</url-pattern>
</servlet-mapping>
For accessing servlet, create a wml file in the working folder

and copy the file to
d:\tomcat 4.1\webapps\axis
c:\sam> edit ejbaxiswapservlet.wml
***************************************************
ejbaxiswapservlet.wml
---------------------
<!DOCTYPE wml PUBLIC
"-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="card1">
<p>
Query? <input type="text" name="text1" />
<do type="accept">
<go method="post" href="http://localhost:8080/axis/servlet/ejbaxiswapservlet">
<postfield name="text1" value="$text1"/>
</go>
</do>
</p>
</card>
</wml>
*************************************************
Open 'Microsoft Mobile browser'and type the url as

'http://localhost:8080/axis/ejbaxiswapservlet.wml'
Make sure that tomcat is running. Enter sql query in the text box and submit it. we'll get
the resultset as per the query. But, WAP is no-longer, the favoured wireless client
because of limited functionality. Color graphics, games and animations are expected
today.
J2ME is the best solution for such apps, because,it is platform independent.
We now demonstrate how we can access an ejb-webservice from a j2me wireless client.
( continued in axis3-3.htm
WEBSERVICE USING APACHE AXIS- TUTORIAL-2

J2ME CLIENT FOR EJB & EJB-WEBSERVICE
In the previous section,we've dealt with how to write WAP client for accessing ejb. In
the same way, we are going to see how to write J2ME client for ejb.We divide this part
into two. They are
(a) creating J2me client for accessing ejb directly
(b) creating j2me client for accessing ejb as webservice.
Let's see the first part now.
Create and complie j2meServlet.java in
the working folder ie. c:\sam
c:\sam> edit j2meServlet.java
j2meServlet.java
import java.io.*;
import javax.ejb.*;
import java.rmi.*;
import javax.rmi.*;
import java.util.*;
public class j2meServlet extends HttpServlet
public void doPost
(HttpServletRequest request,
throws ServletException,IOException
{
try
{
System.out.println("Please wait----!");
Properties props = new Properties();
props.put
props.put(Context.PROVIDER_URL,
"t3://localhost:7001");
Context ctx = new InitialContext(props);

System.out.println("Context ok");
sqlHome home = (sqlHome)ctx.lookup("sqlJndi");
System.out.println("Home ok");
sqlRemote remote = home.create();
System.out.println("Remote ok");
String s = request.getParameter("text1");
String s1=s+"%";
String sql=
"select * from table1 where name like '"+s1+"' ";
System.out.println(sql);
String msg= remote.getdata(sql);
DataOutputStream out =
new DataOutputStream(response.getOutputStream());
out.writeUTF(msg);
System.out.println(msg);
}
catch(Exception e1)
{ System.out.println(" " + e1); }
}
}
c:\sam> javac j2meServlet.java
copy j2meServlet.class to:

d:\tomcat 4.1\webapps\root\web-inf\classes
Next step is to create a midlet for J2ME.Create ejbmidlet.java in our current working
folder.
c:\sam> edit ejbmidlet.java
//ejbmidlet.java
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import javax.microedition.io.*;
import java.io.*;
public class ejbmidlet extends MIDlet implements CommandListener
Display display1;
Form form1,form2;
Command button1,button2;
TextField text1;
StringItem s1;
public ejbmidlet()
{
display1 = Display.getDisplay(this);
text1 = new TextField(null,"a",100,TextField.URL);
form1 = new Form("Type in a URL:");
form1.append(text1);
button1 = new Command("SEND",Command.OK,1);
button2 = new Command("Back",Command.OK,1);

form1.addCommand(button1);
form1.setCommandListener(this);
}
public void startApp()
{
display1.setCurrent(form1);
}
public void pauseApp() {}
public void destroyApp(boolean unconditional) {}
public void commandAction(Command cmd,Displayable d)
{
String url = "http://localhost:8080/servlet/j2meServlet";
if(cmd==button1)
{
try
{
String s = text1.getString();
url = url+"?text1="+s;
System.out.println(url);
HttpConnection hc =
(HttpConnection)Connector.open(url);
hc.setRequestMethod(HttpConnection.POST);
DataOutputStream dos =
new DataOutputStream(hc.openOutputStream());
dos.writeUTF(s);
dos.flush();
System.out.println(s +" Sent");

DataInputStream dis =
new DataInputStream(hc.openInputStream());
String msg=dis.readUTF();
form2 = new Form("Get Result");
s1 = new StringItem(null,msg);
System.out.println(s1);
form2.append(s1);
System.out.println("displayed");
}catch(Exception e){}
}
else if (cmd == button2)
{
text1.setString(" ");

}
}
No need to complie the midlet file.
It is taken care of by J2ME Wireless Toolkit. For running the toolkit from our working
folder set the path as below
c:\sam> set path=%path%;c:\j2mewtk\bin;
c:\sam> ktoolbar
This will open the Toolkit window.Create a new Project by clicking the button 'New
project'.and give the project name as 'ejbdemo1' as project name.Just minimize the
window.
Now copy ejbmidlet.java from our working folder to 'src' folderof 'ejbdemo1'.
c:\sam> copy ejbmidlet.java c:\j2mewtk\apps\ejbdemo1\src
Then go to the toolkit and click 'settings'.
In the 'midlets' tab,add midlet class name ie. ejbmidlet
Click 'Build' for compilation. After source file is compiled successfuly, Click 'Run' button
and execute our midlet. (tomcat41 is running).
Type a letter 'a' in the textbox and click 'send'. Midlet program sends the letter to the
servlet which'll form sqlquery and contact ejb for fetching the result. Recordset for the
name starting with letter 'a' will be displayed in the wireless browser.Let us now create a
J2ME client accessing ejb webservice.create and complie j2meaxisservlet.java
c:\sam> edit j2meaxisservlet.java
j2meaxisservlet.java
import java.io.*;
public class j2meaxisservlet extends HttpServlet
public void doPost (HttpServletRequest request, HttpServletResponse response)
{
try{
String s = request.getParameter("text1");
String s1=s+"%";
String sql="select * from table1 where name like '"+s1+"' ";
System.out.println("sql is"+sql);
System.out.println("point1....call");
call.setTargetEndpointAddress ( new java.net.URL(url));

call.setOperationName ( new QName("sqlservice",method));
Object[] params = new Object[] { sql };
String s2 = (String) call.invoke(params);
DataOutputStream out1 = new DataOutputStream(response.getOutputStream());
out1.writeUTF(s2);
}catch(Exception e) { System.out.println(""+e); }
}
c:\sam> javac j2meaxisservlet.java
copy j2meaxisservlet.class to
Start tomcat4.1 server and do the procedure mentioned in the first part for deploying
midlet.
c:\sam> edit j2meaxismidlet.java
javaismidlet.java
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import javax.microedition.io.*;
import java.io.*;
public class j2meaxismidlet extends MIDlet

implements CommandListener
Display display1;
Form form1,form2;
Command button1,button2;
TextField text1;
StringItem s1;
public j2meaxismidlet()
{
display1 = Display.getDisplay(this);
text1 = new TextField(null,"a",100,TextField.URL);
form1 = new Form("Type in a URL:");
form1.append(text1);
button1 = new Command("SEND",Command.OK,1);
button2 = new Command("Back",Command.OK,1);
}
public void startApp()
{
}
public void pauseApp() {}

public void destroyApp(boolean unconditional) {}
public void commandAction(Command cmd,Displayable d)
{
String url = "http://localhost:8080/axis/servlet/j2meaxisservlet";
if(cmd==button1)
{
try
{
String s = text1.getString();
url = url+"?text1="+s;
System.out.println(url);
HttpConnection hc =
(HttpConnection)Connector.open(url);
hc.setRequestMethod(HttpConnection.POST);
DataOutputStream dos =
new DataOutputStream(hc.openOutputStream());
dos.writeUTF(s);
dos.flush();
System.out.println(s +" Sent");
DataInputStream dis =
new DataInputStream(hc.openInputStream());
String msg=dis.readUTF();
form2 = new Form("Get Result");
s1 = new StringItem(null,msg);
form2.append(s1);
System.out.println("displayed");
}catch(Exception e){}
}
else if (cmd == button2)
{
text1.setString(" ");
}
}
That completes our rather long tutorial! Student-readers are requested to actually try all
the above lessons in this carefully crafted tutorial..
visit http://in.geocities.com/rsramsam
Web Services Tutorials and Links

1. Web services Activity:
The World Wide Web is more and more used for application to application
communication. The programmatic interfaces made available are referred to as
Web services. The goal of the Web Services Activity is to develop a set of
technologies in order to lead Web services to their full potential. The Web
Services Activity Statement explains the W3C's work on this topic in more detail.

2. Web Services Addressing:
Web Services Addressing 1.0 - Core (WS-Addressing) defines two constructs,
message addressing properties and endpoint references, that normalize the
information typically provided by transport protocols and messaging systems in a
way that is independent of any particular transport or messaging system. A Web
service endpoint is a (referenceable) entity, processor, or resource to which Web
service messages can be addressed. Endpoint references convey the information
needed to address a Web service endpoint. This specification defines a family of
message addressing properties that convey end-to-end message characteristics
including references for source and destination endpoints and message identity
that allows uniform addressing of messages independent of the underlying
transport.

3. Web Services Description Language:

As communications protocols and message formats are standardized in the web
community, it becomes increasingly possible and important to be able to describe
the communications in some structured way. WSDL addresses this need by
defining an XML grammar for describing network services as collections of
communication endpoints capable of exchanging messages. WSDL service
definitions provide documentation for distributed systems and serve as a recipe
for automating the details involved in applications communication. A WSDL
document defines services as collections of network endpoints, or ports. In
WSDL, the abstract definition of endpoints and messages is separated from their
concrete network deployment or data format bindings.

4. Java Web services:

The Java Web Services Developer Pack (Java WSDP) is a free integrated toolkit
you can use to build, test and deploy XML applications, Web services, and Web
applications with the latest Web service technologies and standards
implementations. With the newest release of the Java WSDP 2.0, developers will
be able to:
Develop and deploy using the latest XML and Web services technologies slated
for inclusion into Sun's deployment platforms.
Enhance Web services performance without revising WSDL files or application
code with the refreshed Fast Infoset features from Java WSDP 1.6.
Create XML and Web service-enabled applications that exploit the enhanced
security features with enhanced XWSS features.
Continue to enjoy Java interoperability and portability across different platforms
and devices.
Simplify and lower the cost of legacy application integration, data interchange,
and publishing in a Web environment.

5. Web Services Architect:

In this article, we have tried to keep a realistic, pragmatic, and balanced approach
in determining the return on investment on Web Services. It is worth mentioning
that, no matter how promising a new technology is, promoting and encouraging
its usage through such articles and papers is not justified until there is a solid
business case for its adoption. It is fundamentally important for us to warn about
the pitfalls as and where we foresee them, leaving the final decision up to the
readers who range from senior management (technical and business), through
business analysts, and systems architects, to project managers, and software
developers.

6. Web Services primer:

Looking back over the last six years, it is hard to imagine networked computing
without the Web. The reason why the Web succeeded where earlier hypertext
schemes failed can be traced to a couple of basic factors: simplicity and ubiquity.
From a service provider's (e.g. an e-shop) point of view, if they can set up a web
site they can join the global community. From a client's point of view, if you can
type, you can access services. From a service API point of view, the majority of
the web's work is done by 3 methods (GET, POST, and PUT) and a simple
markup language. The web services movement is about the fact that the
advantages of the Web as a platform apply not only to information but to
services.

7. Web services-Axis:
Apache Axis is an implementation of the SOAP ("Simple Object Access
Protocol") submission to W3C.
From the draft W3C specification:
SOAP is a lightweight protocol for exchanging structured information in a
decentralized, distributed environment. It is an XML based protocol that consists
of three parts: an envelope that defines a framework for describing what is in a
message and how to process it, a set of encoding rules for expressing instances of
application-defined data types, and a convention for representing remote
procedure calls and responses.
This project is a follow-on to the Apache SOAP project.
Please see the Reference Library for a list of technical resources that should prove
useful.

8. Getting a Java Web service to work:
We're deploying an existing Web service application to a new JBoss server by
following the "Getting Started with JBoss" manual from www.jboss.org, but the
j2eetutorial examples file doesn't seem to match the documentation. The
application is ready for deployment, but we can't seem to get the right files in the
right places to make things work. Where can we find a JBoss example that works,
or some tools to automate the deployment?
The manual is written for JBoss Version 3.2.3 and Version 1.3.X of the Java
Software Development Kit (JSDK). The current production JBoss release is 3.2.4,
and using Version 1.4X of the JSDK is recommended.

9. Web Services ToolKit:
A software development environment for designing, developing, and executing
Web service technologies.WSTK has evolved into the ETTK for Web Services
and Autonomic Computing (ETTK-WS).
The Emerging technologies team is expanding the scope of the toolkit to include
autonomic and grid-related technologies and has therefore rebranded this
technology to "ETTK for Web Services and Autonomic Computing" (ETTK-WS)
in order to more accurately reflect its role in the new ETTK collection of
technologies and prototypes. The ETTK-WS will continue to offer leading-edge
prototyping of emerging Web services technologies for recently released
specifications. The ETTK-WS can be downloaded here at alphaWorks. The
ETTK-WS integrates emerging technologies from IBM Research Labs and IBM
Software Groups into a consolidated package to showcase leading-edge
technologies that may or may not make it into IBM products.

10. Internet Web Services:
Web services are the basis of distributed computing across the Internet. A Web
service consumer locates a Web service and invokes the operations it provides.
The Web service provider (the application implementing the Web service) can be
on the same Java virtual machine as the one using it, or it can be thousands of
miles away. Web services use standard Web protocols such as XML, SOAP, and
HTTP.

11. What is Web Services resource:
Many technologies must represent state in a standard fashion in a Web services
architecture, such as grid computing and distributed systems management. WSRF
is the emerging OASIS Web services standard for modeling and accessing stateful
resources using Web services.
WSRF for WAS was developed by the WebSphere Application Server (WAS)
development team. This technology extends the WAS Web Services run-time
environment to support the patterns defined by WSRF, and it enables a Web
service to have an association with instances of stateful resources, the composite
of which is a stateful "WS-Resource." A WS-Resource has an associated XML
document, called a resource properties document, that describes the state of the
resource. The resource properties document and the resource it describes may be
queried and updated through Web service message exchanges defined in the
WSRF specifications.
This technology includes a comprehensive sample application illustrating the
following:
the use of a stateful WS-Resource
the means through which its state is queried and updated
the well-defined life cycle of the state.

12. Web Services Language:
As expressed in the Statement of Mission and Objectives, the SWSI Language
Committee aims to develop computer language technology that will provide a
firm, long-term foundation for the future of Web services on the Internet. It is
desired that this foundation will support the most general approaches to service
deployment and use that are currently technically feasible.
The Committee seeks to develop a formal language that allows for rich
declarative specification of a wide variety of information about Web services,
which will support automation of a broad spectrum of activities related to Web
services, such as discovery, selection, composition, negotiation and contracting,
invocation, monitoring of progress, and recovery from failure.
The committee aims to build on the success of OWL-S, taking the existing
language as a starting point, while allowing scope for the revisions and additions
necessary to address these new requirements.

13. WSDL Editor:
The XMLSpy WSDL editor allows you to create, edit, visualize, and validate any
WSDL file. WSDL is a language for describing Web services and is ideally suited
as an interface definition language (IDL) for architecting Web services
applications. By first building an interface, client and server programmers can
implement their respective programming contract using any language or operating
system, avoiding interoperability problems. XMLSpy helps you write and validate
WSDL documents quickly and easily. The graphical WSDL editor displays the
WSDL file structure as well as the WSDL elements grouped by operations,
portTypes, bindings, and services. You can manipulate the file by dragging and
dropping elements, and context-sensitive windows and entry helpers provide
intelligent editing options.

14. Feature of WSDL Editor:
The WSDL Editor offers a rich set of features for programmers looking to create
and edit Web Services:
Intuitive graphical environment for viewing and editing WSDL files
Web Services creation wizard that automates the creation of service definitions,
port types, binding, template operations, and messages
Fully automated wizards for creating and editing XML schema, schema array,
complex types, simple types, and enumerations
Support for WSDL validation, where WSDL is tested against WSDL Schema
Support for WSDL profiling, so WSDL can be validated against customized
profiles for specific requirements such as standards compatibility (for example,
WS-I)
Support for advanced WSDL capabilities such as imports, faults, SOAP headers,
multiple bindings, and parameter ordering
WSDL 1.1 specification support
Retrieval of WSDL from across networks, UDDI repositories, or Internet
locations
Full support for WSDL documentation

15. Web Services Editor:
Cape Clear Software has debuted a free service-oriented architecture (SOA)
editor. It “provides programmers with a graphical environment that simplifies the
creation of standards-based Web Services, which can be deployed into an SOA-
based architecture,” Cape Clear says. The SOA Editor offers easy-to-use tools for
building services, including automated wizards for common development tasks,
support for Web Services standards, tools for testing code, support for XML
Schema, and detailed documentation to help programmers get up and running
quickly,” the vendor notes. “The SOA Editor is available for download
immediately.

16. X standard version:
XStandard is the leading standards-compliant plug-in WYSIWYG editor for
Windows desktop applications and browser-based content management systems
(IE/Mozilla/Firefox/Netscape). The editor generates clean XHTML Strict or 1.1,
uses CSS for formatting, and ensures the clean separation of content from
presentation. Markup generated by XStandard meets the most demanding
accessibility requirements. The editor's cool features include drag & drop file
upload, spell checking and an image library that integrates tightly with your CMS.

17. XML-Editor:
XML editor is a Java-based XML editor with support for XML, XSL, TXT, XSD
and DTD documents. Oxygen shows that Java should be the base of an XML
editor; this can be proved by the development dynamics of Oxygen and by the
availability on many platforms. It has Unicode support and the interface messages
are translated in English, French, German, Italian and Romanian. The main goal
of Oxygen is to be a tool easy to use and to make tasks shorter, thus it offers end
tag auto-completion and a powerful code insight that guide the user to write valid
XML content. The code insight can follow a DTD structure, an XML schema
structure or even can detect the structure of a partial edited document allowing the
rest of the document to be created about 5 times faster than before. A very
important thing is manipulating XML content and XSLT is the normal way to
this, thus XML and XSL documents can be easily associated one with the other
and the transformation results can be viewed through different views like text,
XML, HTML. An XPath console is present to assist the user in testing the results
of XPath expressions.

18. Web services with Axis2:
In simple terms, Axis2 is not just the next version of the Axis 1.x family; rather, it
is a revolutionary version of Axis 1.x. Axis2 is no longer bound to request-
response Web service invocation. As in the Axis 1.x family, there is no turning
point like the "pivot point" in Axis2, and Axis2 is built totally on keeping
asynchronous Web service invocation in mind. Axis2 acts as a pipe that carries
the SOAP message from one end to other. The entry point to the pipe is a
transport receiver, and the end point is a message receiver. After handing over the
message to the message receiver, Axis2 does not care about the message.
Therefore, it's up to the message receiver to invoke the service and send the
response, if any, so service implementation classes) need not always be a Java
class; it can be something else as well.

19. Secure Web Services via Oriented:
This article describes the exploitation of the pluggable transport infrastructure
provided as part of ASP.NET Web Services, which allows developers to deliver
Soap messages built in the document/literal format to be delivered to an end point
via mechanisms other than default HTTP transport. In this article, a framework
that supports the addition of alternative physical delivery mechanisms is
presented, and two such implementations are included – MSMQ and Websphere
MQ are chosen to illustrate a store-forward capability for a more 'guaranteed'
Web Services request delivery. The framework that will be developed integrates
the Web Services Enhancements (WSE) 1.0 for secure 2-way transport of
messages over non-HTTP mechanisms, thereby giving the developer a choice of
'trusted' (clear message) or 'untrusted' (secure message) delivery to the chosen
endpoint.

20. Microsoft Web Services:
The Microsoft.com Web service is an XML Web service that will enable you to
integrate information and services from MSDN, Technet, other Microsoft.com
sites, and Microsoft Support. In order to serve as a test for our new architecture,
Version 1.0 of the Microsoft.com Web service is limited to providing information
about top downloads from Microsoft.com. Future releases will build on this
architecture to provide access to a broader variety of Microsoft content and
services.

21. Web Services to J2EE :
The Java XML Pack is the first certified release of Web services tools for J2EE
(Java 2, Enterprise Edition), the server software platform that is based on the Java
programming language. Java developers already have some tools provided by the
open-source community that allow them to build XML-based Web services for
J2EE, said Karen Shipe, a product manager with Sun's Java XML group. But
Sun's release Monday is the first such technology that has gone through the Java
certification process.

22. Open SAML Web Services:
OpenSAML is a set of open-source libraries in Java and C++ which can be used
to build, transport, and parse SAML messages. OpenSAML is able to store the
individual information fields that make up a SAML message, build the correct
XML representation, and parse XML back into the individual fields before
handing it off to a recipient. OpenSAML supports the SOAP binding for the
exchange of SAML request and response objects (C++ supports requesting only).
It provides additional help in supporting the SAML browser/POST profile for
web single sign-on. It does not currently provide any additional support for the
artifact profile, but provides the machinery needed to implement it in other
software. All core SAML constructs are now supported to some
degree.OpenSAML has been produced by Internet2 members as part of their work
on the Shibboleth project ( http://shibboleth.internet2.edu/ )

SOA & Web Services Tutorials

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOA & Web Services Tutorials

Uploaded by

Copyright:

Available Formats

SOA and Web Services

Developing and deploying Web Services on Apache Geronimo Application

What is Service-Oriented Architecture?

A service is a function or some processing logic or business processing that is well-

The following figure is a typical example of the service-oriented architecture. It shows

Different Technologies Used:

Term Definition / Comment

Web Services - Web Services Tutorials

Historically speaking, remote access to binary units required platform-specific and

What is a Web Service

Web services constitute a distributed computer architecture made up of many different

Web Service Standards

Universal Description, Discovery, and Integration (UDDI) is a protocol for describing

Implementing Web Services

Here comes a brief step-by-step on how a Web service is implemented.

 A service provider creates a Web service

Web Service Infrastructure

Web Services Technologies and Tools

Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol")

From the draft W3C specification:

Why Web Services?

Why Web Services?

Here are the benefits of using Web Services:

Connecting Different Applications: Web Services allows different applications to talk

Loosely Coupled Applications: Web Services are self-describing software modules

J2EE Web Service Development with

Attachments are becoming increasingly popular in the web service development

1. Developing a web service that handles the attachments.

Web Service Implementation

Listing 1. Method signatures in the web service

public Object getDimeData(DataHandler dh)

public Object getMimeData(DataHandler dh)

Listing 2. Checking the DIME attachment

Listing 3 shows the code to handle the MIME attachment.

Listing 3. Checking the MIME attachment

Listing 4. Getting the byte array from any attachment

public static byte[]

Listing 5. Getting the client's input String from attachment

Listing 6. Sending output as a DIME attachment.

log.info("setting the DIME

Listing 7 shows the procedure to send the output String as a DIME

Listing 7. Sending output as a MIME attachment.

You might be wondering why a temporary file is used in case of a MIME

Deployment of web Service

Listing 8. Contents of deploy.wsdd file.

After installing axis application on Tomcat web server, execute the

Running the above command creates the server-config.wsdd file in the

First, create the org.apache.axis.client.Call object as shown in Listing 9 :

Listing 9. Creating Call Object for the service.

Listing 10. Client program to access the web service.

private static void

Download the source code of this article: Source Code

 For more information on DIME attachments, refer to an article on DIME

Building a Simple Web Service – A Tutorial

 By Jeevaraj Gnanaselvan Dhanaraj (jeevaraj_1970@yahoo.com)

Install JDK (in D:\j2sdk1.4.2_04)

Install Tomcat (in E:\Tomcat5.5)

Install Eclipse (in E:\Eclipse3.1)

Install Lomboz (in E:\Eclipse3.1)

 Creating a Web service

2. Enter name as “WebServiceTutorial”, select project location as “E:\Test” and select

5. Add a simple method in the “Hello” class as below.