[axis1]document update report No.2

Mon, 18 Oct 2010 20:12:30 -0700 

 Now comes document update report No.2.

This time I do check with 2 html pages: security.html and reading.html

Changes for security.html:
1.Links update
--Bilal Siddiqui
--HttpClient

2.Correction
--change CVS to svn
--change bugzilla to JIRA
--change AxisBaseServlet to AxisServletBase

Changes for reading.html:
1.Links update
--Dennis Sosnoski:Apache Axis SOAP for Java
--Macromedia:Axis in JRrun
--IBM:Ask the magic eight ball
--SOAP Version 1.1
--SOAP Version 1.2 Part 0: Primer
--Web Services Description Language (WSDL) 1.1
--RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
--SOAP with Attachments API for Java (SAAJ)
--Java API for XML-Based RPC (JAX-RPC)
--Java API for XML Messaging (JAXM)
--Axis - an open source web service toolkit for Java
--Steve Loughran:When Web Services Go Bad
--The Java Web Services Tutorial: Java API for XML-based RPC
--Steve Loughran:The Wondrous Curse of Interoperability
--Java development with Ant
--AXIS: Next Generation Java SOAP
--Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI
--IBM developerWorks Web Services corner
--MSDN Web Services
--WebServices.xml.com

2.Remove links no longer exists
--Dennis Sosnoski:Enabling SOAPMonitor in Axis 1.0
--Kevin Jones:Configure Axis Web Services
--Kevin Jones:Different WSDL Styles in Axis
--VeriSign's TSIK
--JavaOne 2002, Web Services Today and Tomorrow
--Beginning Java Web Services

Again, who is responsible for updating documents in svn?

dilly(Ma Yu)
Shanghai, China


于 2010-10-16 16:59, Andreas Veithen 写道:
> Yes, this this is indeed quite convoluted. What are the results if you
> try to follow the instructions given in [1]?
>
> Andreas
>
> [1] http://ws.apache.org/axis/howtobuild.html
>
> On Fri, Oct 15, 2010 at 04:27, dilly <[email protected]> wrote:
>>  Finally I get the response :)
>>
>> The way to build the whole axis 1 web site seems difficult to me.  I'm
>> studying, little progress now.
>> So now I focus on the document update.  I think the document with axis 1
>> package is using html format directly, so I can simply update the .html
>> itself, right?
>>
>> dilly(Ma Yu)
>> Shanghai, China
>>
>>
>> 于 2010-10-14 3:54, Andreas Veithen 写道:
>>> Here is what I would suggest:
>>>
>>> 1. Check out
>>> https://svn.apache.org/repos/asf/webservices/axis/trunk/site/src/java/
>>> and try to build it.
>>> 2. Confirm that this is indeed the source of the current version of
>>> the published site.
>>> 3. If it's confirmed, I'll move this folder to the appropriate place
>>> under https://svn.apache.org/repos/asf/axis.
>>> 4. Make the changes to the site source and submit a patch (svn diff)
>>> so that we can review and apply them.
>>> 5. Republish the site. This is something that we (the developers) need
>>> to figure out.
>>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>> On Mon, Oct 11, 2010 at 05:43, dilly<[email protected]>  wrote:
>>>> Hi,
>>>>   I'm back again, for that someone told me dev list did not split :)
>>>>   As planed, I send the first axis1 document update report No.1.
>>>>
>>>>   Up to now, I have examed two document html page, index.html and
>>>> install.html.
>>>>   Install.html cost me a lot, and I was shocked about the workload  -_-!
>>>>
>>>>   Test enviroment:
>>>> Item Description
>>>> Windows Operation System Windows XP SP3
>>>> Linux Operation System Ubuntu 10.04LTS
>>>> Main Verify Browser IE 6, Windows XP SP3
>>>> Minor Verify Browser Firefox 3.6.10, Ubuntu 10.04
>>>> Web Server Tomcat 4.1.40
>>>> JDK Sun JDK 1.4.2_19, both windows&  linux
>>>>
>>>>   The changes list here:
>>>>
>>>> Invalid links update
>>>> 1.Change Tomcat Links up to date
>>>> 2.Change "Java Web Services Developer Pack Version 1.0" up to date
>>>> 3.Change "WebLogic Server Application Classloading" up to date
>>>> 4.Make the result of "Test a SOAP Endpoint" by getVersion up to date
>>>> 5.Make the result of "Test a JWS Endpoint" by list up to date
>>>> 6.Change the links of Java Development with Ant and it's 15th chapater up
>>>> to date
>>>> 7.update the user mail list
>>>> 8.update the mailing list archives for axis 1 user
>>>> 9.Change the outdated bugzilla database and its address to new JIRA
>>>> 10.Change the Axis Wiki address up to date
>>>>
>>>> Issues to be resoled
>>>> 1.Very Importance: The Classpath setup of Step 6 is lack of one important
>>>> jar:wsdl4j-1.5.1.jar
>>>> 2.Add a directory note for step 7
>>>> 3.Correct the runing-fail bug by adding ".:" to Testing command on Unix
>>>>
>>>> Improvements
>>>> 1.Add Linux to Unix Command
>>>> 2.Not good format in IE6
>>>>
>>>> Related JIRA Bugs:
>>>> 1.AXIS-1643:Testing samples.stock.GetQuote
>>>> 2.AXIS-1503:Varioius small issues in install.html
>>>> 3.AXIS-1340:Documentation but in testing GetQuote
>>>>
>>>>   Besides, how can i submit the changes?
>>>>   Do I need to open a new issue in JIRA and update related files as
>>>> attechments, or just send email to dev mailing list like this?
>>>>   How to close the old issues in JIRA? Some one will do me a favor?
>>>>
>>>> dilly(Ma Yu)
>>>> Shanghai, China
>>>>
>>>> 于 2010-10-10 2:11, Andreas Veithen 写道:
>>>>
>>>> No, we decided to split the user list, but not the dev list. The
>>>> reason is that in 2009, there was still a significant number of Axis
>>>> 1.x related user requests, but there were no active developers.
>>>>
>>>> Andreas
>>>>
>>>> On Sat, Oct 9, 2010 at 18:30, dilly<[email protected]>  wrote:
>>>>
>>>> Hi,
>>>> I have tried to enter [email protected] but failed.
>>>> So there is a mailing list for axis 1 developer, isn't there?
>>>>
>>>>
>>>> -------- ???? --------
>>>> ??:     Delivery Status Notification (Failure)
>>>> ??:     Sat, 09 Oct 2010 16:25:40 +0000
>>>> ???:    Mail Delivery Subsystem<[email protected]>
>>>> ???:    [email protected]
>>>>
>>>>
>>>>
>>>> Delivery to the following recipient failed permanently:
>>>>
>>>>     [email protected]
>>>>
>>>> Technical details of permanent failure:
>>>> Google tried to deliver your message, but it was rejected by the
>>>> recipient
>>>> domain. We recommend contacting the other email provider for further
>>>> information about the cause of this error. The error that the other
>>>> server
>>>> returned was: 550 550 mail to [email protected]
>>>> not
>>>> accepted here (state 14).
>>>>
>>>> ----- Original message -----
>>>>
>>>> Received: by 10.114.124.10 with SMTP id w10mr4569684wac.6.1286641539294;
>>>>        Sat, 09 Oct 2010 09:25:39 -0700 (PDT)
>>>> Return-Path:<[email protected]>
>>>> Received: from [192.168.1.104] ([116.232.127.205])
>>>>        by mx.google.com with ESMTPS id
>>>> p4sm2596614wal.3.2010.10.09.09.25.33
>>>>        (version=SSLv3 cipher=RC4-MD5);
>>>>        Sat, 09 Oct 2010 09:25:38 -0700 (PDT)
>>>> Message-ID:<[email protected]>
>>>> Date: Sun, 10 Oct 2010 00:25:17 +0800
>>>> From: dilly<[email protected]>
>>>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.9)
>>>> Gecko/20100915 Thunderbird/3.1.4
>>>> MIME-Version: 1.0
>>>> To: [email protected]
>>>> Subject: Apply for subscription
>>>> Content-Type: text/plain; charset=GB2312
>>>> Content-Transfer-Encoding: 7bit
>>>>
>>>>
>>>>
>>>> --
>>>> dilly(Ma Yu)
>>>> Shanghai, China
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
Title: Web Service Security

Web Service Security

The challenge of server security

A standard attack on a web site is usually that of identifying and abusing badly written CGI scripts. Anything that gives read access to the file system is a security hole, letting people get at the code behind the site, often including database passwords and other sensitive data, plus of course there are the core parts of the underlying platform, which may contain important information: passwords, credit card lists, user-private information, and the like. Unauthorized access to this data can be embarrasing and expensive.

Having write access to the system leads to even greater abuses; defaced web sites may be created, spoof endpoints written to capture caller's data, or the database directly manipulated.

Is SOAP fundamentally insecure?

Some people, such as Bruce Schneier, have claimed that SOAP is a security disaster in the making, because of its ability to punch through firewalls. However, because in SOAP over HTTP the client can only make SOAP calls, not receive them, SOAP is no more insecure than any other application which POSTs XML files to a web server. The clients are safe unless the server (or its DNS address) have been subverted; the server is vulnerable, and does need to be secured.

Similarly, Bilal Siddiqui makes the claim that SOAP cannot distinguish between sensitive and non-sensitive web services and cannot perform user authentication, authorization, and access control.

Again, this is another example of excess panic, perhaps combined with a lack of knowledge of how SOAP servers are implemented. You do not need to follow this author's advice and have separate SOAP servers for every level of sensitivity, or XML and SOAP aware firewalls, any more than you need separate Web Servers for different users, or require HTTP aware routers to restrict parts of a web server to different IP addresses.

Common Attack Types

  • Denial of Service to a server
  • Interception and manipulation of messages
  • Forged client requests
  • Forged server responses
  • attempts to read the server file system/database
  • Attempts to write to the server file system/database
The most significant security risk comes from the fact that you are writing code to provide functionality to calling programs. If that functionality is offered to the wrong people, or if the code you wrote creates a security hole, "unexpected functionality", then you have a problem.

There is a large body of literature which covers securing web sites, such as the Open Web Application Security Project Top Ten List of vulnerabilities, and their Guide to Building Secure Web Applications.

Special XML attacks

XML messages have a few intrinsic weakness, that Web Service creators should know about. None of these problems are unique to SOAP; anyone processing incoming XML needs to know and resist these.
  1. Large XML Documents
    Have a client post an XML doc of extreme length/depth <foo><foo><foo>...</foo></foo></foo> This does bad things to DOM parsers and memory consumption on the server: a DoS attack. The issue here is that the costs of handling a large XML document are much greater than the cost of generating one.
  2. Entity Expansion Attacks. If an XML doc header declares some recursive entity declarations, and the file refers to them, then bad things happen. Axis became immune to this between versions 1.0 and 1.1.
  3. Entities referring to the filesystem.
    Here you declare an entity referring to a local file, then expand it. Result: you may be able to probe for files, perhaps even get a copy of it in the error response. As Axis does not support entities any more, it resists this. If your code has any way of resolving URLs from incoming messages, you may recreate this problem.
The other thing to know about XML is that string matching is not enough to be sure that the content is safe, because of the many ways to reformat the same XML.

Authenticating the caller

The new Web Service security proposals offer to authenticate your callers to your end point, and vice-versa. Axis does not yet implement these, but we do support XML signatures via a sister project.

The other approach is to validate at the transport level, using HTTPS. Configuring your web server to support https is definitely beyond the scope of Axis documentation: consult your server docs. To support https in the Axis client, you need to ensure the client has https support in the runtime. This is automatic for Java1.4+; older versions need to add JSSE support through Sun or an alternate provider.

Once you have HTTPS working at both ends you need to have the client trust the server certificate -usually automatic for those signed by central certification authorities, a manual process for home rolled certificates.

Clients can authenticate themselves with client certificates, or HTTP basic authentication. The latter is too weak to be trustable on a non-encrypted channel, but works over HTTPS. The MessageContext class will be configured with the username and password of the sender when SOAP messages are posted to the endpoint; use the appropriate getters to see these values. Note that Axis does not yet integrate with the servlet API authentication stuff. Although the forms authentication is literally off-axis when it comes to SOAP calls, the UserPrincipal notion and integration with server configuration gives some incentive for integration. (this is a hint to developers out there)

Axis does not (yet) support HTTP1.1 Digest Authentication; if it does get added it will be via the HttpClient libraries.

Securing your Services

One of the key security holes in any Web Service is the code you write yourself. It won't have as many eyes examining it as the Axis source gets, deadlines get in the way of rigorous testing, and a complex web service will bind to the valued items: private data, databases, other servers, etc, that you want to defend against.

The key to this is not to trust the caller: their identity, their IP address and most of all, their data. Here are some attacks to consider.

XML attacks

We listed these attacks earlier. If your service takes XML from an attachment, or in a base-64 encoded string, parsing it as a standalone document, then you are exposed to all these attacks. Also watch out for standard XML syntaxes that integrate xlink or other ways of describing URLs to fetch -such as SVG. You need to ensure the renderer only fetches approved URLs.

Session Theft

Axis uses a good random number generator to generate session IDs, but someone listening to an unencrypted conversation could hijack a session and send in new messages. Recording sender info, such as the originating IP address helps, though beware of proxied systems (e.g. AOL) that may change the apparent origin of calls mid-session.

DOS attacks via load-intensive operations

Any request that takes time to process is a DOS attack target, as it ties up the CPUs. Authenticate before long requests, and consider watchdog threads to track really long execution times. If any bug causes a request to spin forever.

Parameter Attacks

If any parameter in the XML is fed straight into a database query, or some other routine that depends on valid data, then that data must be validated. Otherwise someone malicious could send a database update request, or some other string which lets a malicious user manipulate the system. This could even be as simple as changing their UserID in a request from that they set up in the session. Database attacks come from any situation where a parameter is inserted into an SQL query; the insertion of a semicolon ";" often permits the caller to append a whole new SQL command to the end of the first, and have it executed with the rights of the Web Service.

The key to defending against malicious parameters is to validate all data. Only accept a string containing only the characters/regular _expression_ expected, and check its length. Better yet apply any other higher level checks 'userID==session.userID' that you can. Prepared Statements are the followon way of defending against SQL injection, as the JDBC runtime handles escaping of things. Don't try and build SQL strings by hand; it is a recipe for security holes.

Note that this would seem to argue strongly against mapping Session EJB objects to SOAP Endpoints. This is not the case. The Session bean must merely assume that all incoming data is untrusted, and so validate it all before processing further. This is exactly the kind of task a Service Layer should be doing.

Cross Site Scripting

In theory, a pure Web Service should be immune to XSS attacks, at least those that rely on having uploaded script displayed in an HTML Web Page server-side, script that is executed when the client views it. But the moment one takes Axis and integrates with one's own webapplication, any loopholes in the rest of the webapp expose this exact problem. We don't think Axis itself is vulnerable, because although it may include supplied data in a SOAPFault, this is displayed as XML, not HTML. Clients which don't distinguish the two could be an issue, as could anything we missed, especially in GET handling.

Securing Axis

A core philosophy is 'defend in depth', with monitoring for trouble.

Disguise

One tactic here is to hide the fact that you are running Axis...look at all the headers that we send back to describe the service, and if any identify Axis, edit that constant in the source. While obscurity on its own is inadequate; it can slow down attacks or make you seem less vulnerable to known holes.

Cut down the build

Rebuild Axis without bits of it you don't need. This is a very paranoid solution, but keeps the number of potential attack points down. One area to consider is the 'instant SOAP service' feature of JWS pages. They, along with JSP pages, provide anyone who can get text files onto the web application with the ability to run arbitrary Java code.

Rename things

The AxisServlet, the AdminService, even happyaxis.jsp are all in well known locations under the webapp, which is called 'axis' by default. Rename all of these, by editing web.xml for the servlet, server-config.wsdd for the AdminService; the others are just JSP and WAR files you can rename. You may not need the AdminService once you have generated the server config on a development machine.

Stop AxisServlet listing services

To do this, set the Axis global configuration property axis.enableListQuery to false.

Keep stack traces out of the responses

By default, Axis ships in production mode; stack traces do not get sent back to the caller. If you set axis.development.system to true in the configuration, stack traces get sent over the wire in faults. This exposes internal information about the implementation that may be used in finding weaknesses.

Stop autogenerating WSDL

Trusted partners can still be given a WSDL file through email, or other means; there is no need to return the WSDL on a production server. How do you stop Axis returning WSDL? Edit the .wsdd configuration file, as described in the reference, to return a WSDL resource which is simply an empty <wsdl/> tag.

Servlets2.3: use filters for extra authentication

Servlets 2.3 lets you use filters to look at all incoming requests and filter them however you like -including validating IP address, caller credentials, etc. Caller address validation is useful for securing admin services and pages, even when other endpoints are public. Of course, router configuration is useful there too.

Log things

Although full logs are a DoS attack tactic in themselves, logging who sends messages is often useful, for auditing and keeping track of what is going on. Add more log4j tags to whatever bit of Axis appeals to you to do this.

Run Axis with reduced Java rights

Java has a powerful and complex security system. Use it to configure Axis with reduced rights. Axis tries to write to WEB-INF/server-config.wsdd when updating the server config; and somewhere else (its configurable) when saving compiled .jws pages.

Run the web server with reduced rights

On Unix this is pretty much a given, but even on Windows NT and successors you can run a service as a different user. Make it one with limited rights. Make sure the core of the system has its access permissions tightened up so that the restricted-rights user can not get at things it shouldn't.

Monitor Load

To track DoS attacks, a load monitor is useful. AxisServletBase tracks the number of callers inside its subclasses at any point in time; the AdminServlet shows how to get at this data.

Consider 'tripwire' and 'honeypot' endpoints

With the core endpoints moved, why not create tripwire implementations of the admin endpoint, or a spoof endpoint listing under Axis/AdminServlet pointing to a honeypot endpoint that does nothing but send an alert when anyone sends a SOAP message to it. You then need a policy to act on the alerts, of course. A real honeypot would emulate an entire back end service -it would be an interesting little experiment to build and play with.

Monitor the Mailing Lists

We tend to discuss security on Axis-Dev, whenever it is an issue, but if demand is high we may add an axis-announce mailing list for important announcements.

What to do if you find a security hole in Axis

These days a lot of people love to make a name for themselves by finding security holes, and Axis, as part of the Apache product family, is a potential target. A hole in Axis could make many Web Services vulnerable, so could be serious indeed. So far we have only found a few of these, primarily in quirks of XML parsing rather than anything else.
  1. Don't Panic. We have a process in place for verifying and fixing holes.
  2. Don't rush to issue the press release to BugTraq. It is polite to let us know, and even verify that you are correct.
  3. Test against the latest svn version, not the (older) release builds. We may like already have fixed it, hacker dudes :-)
  4. Email [email protected]. Not the public axis-dev list, not JIRA. The security alias list is a list with representives from all Apache projects, so your report will be taken seriously.
  5. Let us do a fix if possible, so we can announce that a fix is ready when you announce your finding. This doesn't take any of the credit way from the finder, just stops people panicing.

Automate Security Tests

If you find a security problem, write a test for it, such as a JUnit or HttpUnit test, so that you can regression test the application and installations for the problem. This is particularly important where it is a configuration problem that creates the hole; it is almost inevitable the same problem will re-occur on future installations.

Conclusions

We have shown some of the issues with Web Service security, things you need to think of in your own service, and how to harden Axis itself. Securing a system is much harder than getting a system to work, as 'work' usually means 'one or two non-critical bugs are OK'. From a security perspective, no security holes can exist for a system to be secure: no matter how obscure it is, someone may find it and exploit it. Be paranoid: you know it makes sense.

Finally, don't get put off writing SOAP services through a fear of the security implications. Any CGI-BIN or ASP/JSP page that takes parameters is as much of a security risk as a SOAP endpoint. For some reason, SOAP attracts dramatic press stories about infinite risk, perhaps because it is new and unknown. It isn't: it is XML posted to a web application, that's all. Only if you are scared of that, should you not write a SOAP service.

Title: Axis: further reading

Recommended Reading

Here are things you can read to understand and use Axis better. Remember, you also have access to all the source if you really want to find out how things work (or why they don't).

Axis installation, use and internals
  1. Web Services with JAX-RPC and Apache Axis.
    by Pankaj Kumar. Starting with a 10000 ft. view of Web Services, prior technologies, current and emerging standards, it quickly gets into the nitty-gritties of using JAX-RPC and Apache Axis for writing and executing programs. Has a nice coverage of different invocation styles - generated stubs, dynamic proxy and dynamic invocation interface. A good place to start if you are new to Web Services and Axis.

    The author also maintains a Web Services Resource Page.
  2. Apache Axis SOAP for Java
    Dennis Sosnoski covers Axis. This is another good introductory guide.
  3. Enabling SOAPMonitor in Axis 1.0.
    Dennis Sosnoski on how to turn the SOAP monitor on and off, and use it to log your application. You can get a copy of this article by google.
  4. Axis in JRrun
    Macromedia authored coverage of using Axis from inside JRun.
  5. Ask the magic eight ball
    Example of using an Axis service with various caller platforms/languages.
  6. Configure Axis Web Services
    Kevin Jones talks a bit about configuring axis, showing how to return handwritten WSDL from the ?wsdl query.
  7. Different WSDL Styles in Axis
    Kevin Jones looks at the document and wrapped styles of WSDL2Java bindings.
  8. Web Services Security with Axis
    This sample chapter from J2EE Security for Servlets, EJBs and Web Services book explains use of username/password based authentication, SSL and Servlet security mechanisms for securing the transport and WS-Security for securing the messages with Apache Axis. To illustrate use of handlers for enforcing security, it describes the implementation of a bare-bones WS-Security mechanism using VeriSign's TSIK and JAX-RPC handlers. You can also view or download the complete sources discussed in the chapter.

Specifications
  1. SOAP Version 1.1
    Remember that SOAP1.1 is not an official W3C standard.
  2. SOAP Version 1.2 Part 0: Primer
    This and the follow-on sections cover what the W3C think SOAP is and how it should be used.
  3. Web Services Description Language (WSDL) 1.1
  4. RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
    This is HTTP. You really do need to understand the basics of how this works, to work out why your web service doesn't :)
  5. SOAP with Attachments API for Java (SAAJ)
    SAAJ enables developers to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
  6. Java API for XML-Based RPC (JAX-RPC)
    The public API for Web Services in Java. JAX-RPC enables Java technology developers to develop SOAP based interoperable and portable web services. JAX-RPC provides the core API for developing and deploying web services on the Java platform.
  7. XML Schema Part 0: Primer
    The W3C XML Schema, (WXS) is one of the two sets of datatype SOAP supports, the other being the SOAP Section 5 datatypes that predate WXS. Complicated as it is, it is useful to have a vague understanding of this specification.
  8. Java API for XML Messaging (JAXM)
    JAXM enables applications to send and receive document oriented XML messages using a pure Java API. JAXM implements Simple Object Access Protocol (SOAP) 1.1 with Attachments messaging so that developers can focus on building, sending, receiving, and decomposing messages for their applications instead of programming low level XML communications routines.

Explanations, articles and presentations
  1. A Gentle Introduction to SOAP
    Sam Ruby tries not to scare people.
  2. A Busy Developer's Guide to WSDL 1.1
    Quick intro to WSDL by the eponymous Sam Ruby.
  3. Axis - an open source web service toolkit for Java
    by Mark Volkmann, Partner, Object Computing, Inc. A very good introduction to SOAP and Axis. Highly Recommended.
  4. When Web Services Go Bad
    Steve Loughran tries to scare people. A painful demonstration how deployment and system management are trouble spots in a production service, followed by an espousal of a deployment-centric development process. Remember, it doesn't have to be that bad.
  5. JavaOne 2002, Web Services Today and Tomorrow
    (Java Developer connection login required)
  6. The Java Web Services Tutorial: Java API for XML-based RPC
    This is part of Sun's guide to their Java Web Services Developer Pack. The examples are all based on their JWSDP, but as Axis also implements JAX-RPC, they may all port to Axis.
  7. Using Web Services Effectively.
    Blissfully ignoring issues such as versioning, robustness and security and all the other details a production Web Service needs, instead pushing EJB as the only way to process requests, this is Sun's guide to using web services in Java. It also assumes Java is at both ends, so manages to skirt round the interop problem.
  8. Making Web Services that Work
    A practical but suspiciously code free paper on how to get web services into production. As well as coverage of topics such as interop, versioning, security, this (57 page) paper looks at the deployment problem, advocating a fully automated deployment process in which configuration problems are treated as defects for which automated test cases and regresssion testing are appropriate. Happyaxis.jsp is the canonical example of this. The author, Steve Loughran also looks a bit at what the component model of a federated web service world would really be like.

Interoperability
  1. To infinity and beyond - the quest for SOAP interoperability
    Sam Ruby explains why Interop matters so much.
  2. The Wondrous Curse of Interoperability
    Steve Loughran on interop challenges (especially between .NET and Axis), and how to test for them.

Advanced topics
  1. Requirements for and Evaluation of RMI Protocols for Scientific Computing
  2. Architectural Styles and the Design of Network-based Software Architectures
    The theoretical basis of the REST architecture
  3. Investigating the Limits of SOAP Performance for Scientific Computing
  4. Architectural Principles of the World Wide Web
    The W3C architects say how things should be done.

Books
  1. Beginning Java Web Services
    Meeraj Kunnumpurath et al, Wrox Press, September 2002.
    An introductory book, with the early chapters focusing on Axis.
    The sample chapter shows how to install Axis with Tomcat 4.0: we do not believe that their approach is the best. It is easier to drop jaxrpc.jar and saaj.jar into the CATALINA_HOME/common/lib dir than it is to add all axis jars to the classpath by hand. The book is based on Axis Beta-3.
  2. Java development with Ant
    by Erik Hatcher and Steve Loughran, Manning Press, July 2002.
    A book on Ant development which covers Web Service development with Axis, along with other topics relevant to Java developers using Ant. The Web Service chapter, chapter 15, is free to download, and was the birthplace of happyaxis.jar.
    The book is based on Axis Beta-2; the web site contains updated documentation where appropriate.
  3. AXIS: Next Generation Java SOAP
     by Romin Irani and S Jeelani Bashna, Wrox Press, May 2002.
    The first nothing-but-Axis book.
    It is based on Beta-1. This is a reasonable book, despite is apparent thinness and relative age. If it has a major weakness it believes everything works as intended, which regular Axis users will know is not quite true yet. Maybe they didn't want to fault missing features and other gotchas, assuming they would be fixed by the time the product shipped, but the effective result is that you can get into minor trouble working from this book, trying to use bits that aren't there, or just don't work (yet).
  4. Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI
    Steve Graham et al, December 2001. 2nd Edition, Jun 2004.
    Covering very early versions of Axis along with other aspects of Web Service technologies. One of the authors, Glen Daniels, is an Axis committer and active contributor, so the quality of the Axis coverage is high. Good explanations of SOAP, UDDI, and the like.
  5. J2EE Security for Servlets, EJBs and Web Services
    Pankaj Kumar, Prentice Hall, September 2003.
    A book on using Java security APIs, tools and mechanisms for building secure enterprise applications. The chapter on Web Services Security uses Axis-1.1RC1 for illustrations. Besides Web Services, it covers security aspects of Java RMI, Servlet and JSP based Web Applications and EJBs.
Authors, publishers: we welcome additions to this section of any books which have some explicit coverage of Axis. Free paper/pdf copies and other forms of bribery accepted.

External Sites covering Web Services

  1. IBM developerWorks Web Services corner
    There are lots of interesting articles on Web Services here, many of which are Axis related. There is also a listing of "all current open standards and specifications that define the Web services family of protocols", though Soap with Attachments is mysteriously absent.
  2. MSDN Web Services
    These are the microsoft pages; little Axis coverage but plenty on Web Service specifications.
  3. WebServices.xml.com The O'Reilly site is always up to date, interesting and useful. It doesn't advocate a single technology (REST, SOAP, RDF...), or a single product. As such, it retains its independence and value. 
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to