Download Apache Axis

Apache Axis:
A Set of Java Tools for SOAP Web
Services
What’s a SOAP web service ?
•
•
•
•
•
•
•
•
•
A remote resource that accepts and returns SOAP messages.
SOAP messages are XML.
The XML sent to the resource describes an invocation of a method call : parameters and
(optionally) their types and method name, and some metadata about the message itself.
The XML received from the resource describes the return value and the type, or exceptions, and
some metadata about the message itself.
A programming languages do the same thing with their syntax, but XML is weaker in readability
and economy of expression.
XML can be described in a schema. Web service schemas are called WSDL and also define
protocols ( e.g. http ) and a usually a URI. Schemas must define the types but the SOAP XML
instance does not have too.
Anything that is optional is implementation dependent and varies among resource providers.
Web services do not have to use SOAP, they do not have to use HTTP even. A SOAP web service
does not require the HTTP protocol, but in practice it’s almost always used.
SOAP is the standard that major vendors have agreed to, and can be expected to be supported
by external systems.
Apache Axis
• Hide implementation details of web services that talk SOAP :
– Wrap Java methods and deploy them as web services.
– Create web service clients that accept and return Java objects.
• In the simplest case, the developer need never know that
•
•
•
•
SOAP/XML/HTTP is being used. Axis does all the serialization and
protocol handling.
It is possible to customize for more complex cases with hooks
provided by Axis.
SOAP and WSDL are complicated, because they use XML schemas
with namespaces, and do serialization of java objects and primitives
to and from mapped XML representations. Best let the tools do it.
This is on purpose : SOAP was developed by MS to sell their tools.
Fortunately a free set of tools was developed : Axis.
Create a Web Service in Java
• Set up server : add Axis servlet mapping to
•
web.xml; make sure Axis in classpath.
Write your classes and methods in POJ.
– Use types that have built-in type mappings.
• Can also generate a skeleton from a Java
•
•
•
interface.
Write a deployment descriptor (*.wsdd).
Use the Axis admin client to deploy.
C’est tout !
Create a Web Service Client
• Two simplest options:
– Use the Service and Call classes.
– Generate code for proxies and stubs from a WSDL.
• If its not a web service you have the source
code for, you have to use the WSDL. Therefore
always generate and make available a WSDL for
your own web services. It defines the contract
with your clients, and they can use their tools to
create the client code.
Code Generation
• Conveniently generate WSDL, client and
server code from one Java interface.
• Generated code is a skeleton for an
implementation. You can focus on your
business logic in your implementation
without worrying about protocol details.
• All the usual pluses and minuses of code
generation.
Why Web Services ?
• Easier distributed computing.
• Move toward systems of software components with well defined interfaces
•
•
•
that are able to easily plug-in ( and out ); modular, not monolithic, software
systems without unnecessary coupling (= “SOA”). Tight / inappropriate
coupling makes brittle systems that cannot be evolved with changing
conditions.
Disparate systems need access to a particular piece of functionality.
Creating it as a service means it can be coded and maintained in one place
but still be available everywhere its needed.
The SOAP and Web Service specifications represent a consensus for
allowing software components to be included in a computing environment
and to be used, irrespective of physical location, operating system,
programming language, etc. HTTP + XML removes barriers.
May seem to introduce complexity but the tools can hide that. Performance
may be an issue ( due to serialization / de-serialization to XML, network
latency ) depending on how its used.
Why Web Services ? cont.
• Identify candidate services.
–
–
–
–
–
–
Discrete unit of work.
More than one client.
Clients can’t be constrained to one implementation language, platform, or server.
Does something tricky that we only want to maintain in one place.
Does something that many clients need to do.
Need flexibility to change other system components, uncouple them from implementations
and use generic interface instead.
• Develop a service catalog.
• Get buy in by development teams – overcome “I can just hack it myself much easier
•
•
than dealing with all this stuff”.
Good communication required. Silos won’t use services from other silos.
Problems
–
–
–
–
Co-variant development and dependency loops.
Additional testing, development environments. Integration environment needed.
Deployment issues between environments – must configure to use the right service for the
given environment. Use a good configuration + deployment process.
Monitoring and troubleshooting – may have to debug a process across different servers.