Apache Axis:

1. Apache Axis: A Set of Java Tools for SOAP Web Services

2. 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.

3. 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.

4. 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 !

5. 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.

6. 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.

7. 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.

8. 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.