Service Centric

You can watch an interview about my book that was taped at JavaOne on SYS-CON.TV.

You can download a sample chapter (Chapter 10) at TheServerSide.com

A couple people have commented in this blog that it would be good to have a version of the sample code from my book that runs on Tomcat. I agree that its a good idea. It shouldn’t be very difficult, since most of the code does not require all of Java EE 5, but only JAX-WS, JAXB, JSR-109 and JSR-181. And the JAX-WS RI runs on Tomcat (see instructions here). Probably, only the JSR-109 specific deployment stuff (e.g., stateless session bean deployment) would not move over.

One idea that I am considering is to put the book code on SourceForge under SVN and then readers who are interested in Tomcat could work with me on porting the code and junits over to Tomcat/JAX-WS. Similarly, if others got interested in doing the same thing for BEA, IBM WebSphere, JBoss, etc. these platforms could be handled as forks from the initial code base. Each port would be fairly straightforward, but there will be some minor wrinkles for each platform.

If you have any comments about this approach, please let me know.

P.S. GlassFish is great by the way and I still think everyone should give it a try

I just got back from JavaOne and was pleased to see that my book was #8 on the top sellers list at the conference book store.

It was a real thrill to arrive at JavaOne and see my book in the conference bookstore. It was the first time that I saw it in print. My father-in-law (who is not a Java programmer …) reports that Barnes & Noble told him it will be available in their store starting May 18th. I expect that it will be available on Amazon.com any day now.

Thanks to everyone at JavaOne who bought the book. I hope you like it. Please email me with any comments, suggestions or questions.

The following is the preface to my book SOA Using Java(TM) Web Services.

Java became a powerful development platform for Service-Oriented Architecture (SOA) in 2006. Java EE 5, released in May 2006, significantly enhanced the power and usability of the Web Services capabilities on the application server. Then Java SE 6, released in December 2006, incorporated the majority of those capabilities into the standard edition of the Java programming language.

Because robust Web Services technology is the foundation for implementing SOA, Java now provides the tools modern enterprises require to integrate their Java applications into SOA infrastructures.

Of course, Java has had basic Web Services capabilities for some time. JAX-RPC 1.0 was released in June 2002. J2EE 1.4, finalized in November 2003, included JAX-RPC 1.1. So what is significant about the latest versions of the Java Web Services (JWS) APIs?

The answers are power and ease of use. Programmers will find it much easier to build enterprise-class applications with Web Services in Java EE 5 than in J2EE 1.4. Evidence of that is contained in Chapters 9 and 10, which describe an application I developed to integrate online shopping across eBay, Yahoo! Shopping, and Amazon. It’s a pure Java EE 5 application, called SOAShopper, that consumes REST and SOAP services from those shopping sites. SOAShopper also provides its own SOAP and REST endpoints for cross-platform search, and supports an Ajax front-end. SOAShopper would have been a struggle to develop using J2EE 1.4 and JAX-RPC. With the new Java Web Services standards, it was a pleasure to write.

This book focuses on the following standards comprising the new Java Web Services:

• JAX-WS 2.0 [JSR 224]—The Java API for XML-Based Web Services. The successor to JAX-RPC, it enables you to build and consume Web services with Java.
• JAXB 2.0 [JSR 222]—The Java Architecture for XML Binding. Tightly integrated with JAX-WS, the JAXB standard controls how Java objects are represented as XML.
• WS-Metadata [JSR 181]—Web Services Metadata for the Java Platform. WS-Metadata provides annotations that facilitate the flexible definition and deployment of Java Web Services.
• WSEE 1.2 [JSR 109]—Web Services for Java EE. WSEE defines the programming model and run-time behavior of Web Services in the Java EE container.

These standards contain a few big improvements and many little enhancements that add up to a significantly more powerful Web Services programming platform. New annotations, for example, make it easier to
write Web Services applications. And the delegation, in JAX-WS 2.0 [JSR224], of the Java/XML binding to JAXB 2.0 [JSR 222] greatly improves the usability of JAX-WS as compared with JAX-RPC. The deployment model
has been greatly simplified by WS-Metadata 1.0 [JSR 181] and an improved 1.2 release of WSEE [JSR-109].

Chapters 1 and 2 review these JWS standards in detail and describe how they improve on the previous set of JWS standards. Chapters 3 through 10 focus on writing code. To really understand the power and ease of use of the new Java Web Services, you need to start writing code. And that is primarily what this book is about. Chapters 3 through 10 are packed with code examples showing you how to best take advantage of the powerful features, avoid some of the pitfalls, and work around some of the limitations.

Chapter 11 looks to the future and offers some ideas, along with a prototype implementation, for a WSDL-centric approach to creating Web Services that might further improve JWS as a platform for Service-Oriented Architecture.

I started writing this book in 2002, when JAX-RPC first appeared on the scene. I soon ran into trouble, though, because I wanted it to be a book for programmers and I had a hard time writing good sample code with JAXRPC. Four years later, when I started playing around with beta versions of the GlassFish Java EE 5 application server, I noticed that things had significantly improved. It was now fun to program Web Services in Java and I recommitted myself to finishing this book.

The result is a book with lots of code showing you how to deal with SOAP, WSDL, and REST from inside the Java programming language. Hopefully this code, and the writing that goes with it, will help you master Java Web Services and enable you to start using Java as a powerful platform for SOA.

Being a new author of a book on SOA and Web Services, I've gotten interested in the Amazon sales rankings. I found myself periodically checking the sales rank of my book, and thought it would be nice to be able to create a little application to track it for me.

Today, I spent some time experimenting with the Amazon Web Services RESTful interface to poll the sales rank of several books, and created this application.

I created the application using:

• Perl (to query Amazon Web Services)
• MySQL (to store the sales rank time series data)
• PHP and a charting library called PHP/SWF Charts (to create the graph)

The RESTful query to Amazon Web Services (AWS) that gets the sales rankings is this:

http://webservices.amazon.com/onca/xml?Service=AWSECommerceService\
&AWSAccessKeyId=#####&Operation=ItemLookup&IdType=ASIN\
&ItemId=0130449687,0131347969,0321349601,0596527756\
&ResponseGroup=SalesRank,Small

To run this query, you need to substitute your own AWS Access Key Id for the '#####'. You can get one by going to AWS and creating a free account. This RESTful query uses the ItemLookup operation that returns information about the specified ItemId(s).

The XML that is returned when this query is executed looks like this:

To track the sales rank data over time, I use the following Perl script, invoked hourly as a cron job. This Perl code runs this query, parses the XML that gets returned, extracts the sale rank data, and inserts it into a MySQL database.

The last piece of the puzzle is to load the MySQL timeseries data that is collected by the above Perl script into a charting library. For this, I use the charting library called PHP/SWF Charts. The resulting Flash chart is displayed using
this HTML:

As you can see, the HTML is very simple. The chart that is inserted, however, is configured by the PHP code (booksales.php) shown here:

If you find this interesting, and want to learn more about how to build applications using Amazon's RESTful Web services, you might want to check out Chapter 9 in my book . The example illustrated there shows how to build a shopping search engine in Java that integrates Amazon, eBay, and Yahoo! Shopping.

On April 13, Sun Microsystems, the specification lead for Java EE 6 (JSR-313) withdrew the specification because of licensing concerns expressed by members of the Java EE 6 Expert Group.

The following companies abstained from a vote authorizing specification work to proceed: Google, Hewlett-Packard, Intel, Oracle, and SAP. BEA Systems, Fujitsu, IBM, and others did not vote. In choosing to abstain, SAP provided the following comment:

We will need to get more clarification for the new proposed license terms which seem to require a license fee per Java EE profile. If this means a fundamental change in the Java EE licensing model, SAP may decide to vote "NO" on this JSR based on the proposed license terms.

This development is significant, because, these companies are the heavyweights of the Java community.  Java EE 6 cannot proceed unless their issues are addressed.

The Java EE Profiles mentioned by SAP are subsets of Java EE tailored to specific application domains. As Java EE has grown in size and complexity, there has been increasing demand from vendors to componentize Java EE so that a variety of distributions can be created to serve specific markets. One example of such a profile, described in the JSR-313 Request, is for a Java EE Web Profile targeting Web developers. This is how the Web Profile is described in the JSR Request:

Java EE Web Profile - a subset of the Java EE platform targeted at web application development. This profile will provide a more gentle introduction to the Java EE platform, providing only those technologies needed by most web application developers, without the enterprise technologies that sometimes confuse such developers.

Presumably, Expert Group members would prefer a single Java EE license that includes the profiles. However, as described in Section 2.18 of the JSR-313 Request, there are separate licenses (and license fees) for Java EE and the Java EE Web Profile.

For the sake of the entire Java community, I hope that this issue get resolved quickly and that Java EE 6 gets back on track. The concept of Java EE Profiles is vital to keeping server side Java flexible, innovative, and adaptable.

On another note, Java licensing is a hot topic these days, with the Apache Software Foundation's open letter to Sun regarding problems with the terms of the Java SE 5 TCK. There has been some heated discussion of this issue at TheServerSide.com.

This is an excerpt from my book: SOA Using Java Web Services.

If you are a Java developer building enterprise applications today, chances are you are looking at how to best use the Web Services standards built into Java EE 5 to create systems using Service-Oriented Architecture (SOA) principles. These standards include JAX-WS 2.0 (formerly JAX-RPC 1.1) [JSR 224], JAXB 2.0 [JSR 222], Web Services Metadata 2.0 (WS-Metadata) [JSR 181], and Web Services for Java EE 1.2 (WSEE) [JSR 109]. I call these standards, taken together, Java EE 5 Web Services (JavaEE5-WS).

SOA applications are constructed from loosely-coupled Web services. So, naturally, as Enterprise Java developers, we turn to the JavaEE5-WS specifications as our tools for creating SOA applications. Furthermore, the leading Enterprise Java vendors hold out JavaEE5-WS technologies as the development platform of choice for SOA applications.

So, the JavaEE5-WS standards are very important. They are the foundation for SOA. And loosely-coupled SOA applications are critical to corporate competitiveness because they enable business processes to be flexible and adapt to rapidly changing global markets.

Unfortunately, if you are like me, you have found JavaEE5-WS complex and difficult to work with. There often seems to be lots of complex machinery required just to deploy a Java class as a Web Service or create a simple client to consume such services. Sure, you can get the simple “Hello World” application from the Java EE 5 tutorial working. But when you need to deploy your purchase ordering system, things suddenly get a lot more complicated. Either the WSDL you start with gets compiled into a myriad of bizarre classes that have to be manually wrapped and mapped into your real purchasing system. Or, if you start from your Java classes, the WSDL that gets produced doesn’t turn out the way you need it to. If you have run into these problems, then I sympathize with you. So have I, and that is what motivated me to write this book.

Am I Stupid or is Java Web Services Really Hard?

At first, I just thought I was stupid. Prior to getting involved with Java Web Services, I had been running a consulting business. I figured that since I’d been a manager for the past several years, the technologist side of my brain had atrophied. “Keep working at it!”, I said to myself, “and you’ll master this stuff.”. That was 3 years ago, and I’m still struggling to figure out how to best make use of the Enterprise Java standards for Web Services.

During those past 3 years, I’ve mastered topics such as Java generics, reflection, and EJBs. I’ve studied the Apache Axis [AXIS, AXIS2] source code – and even submitted a few patches. I’ve convinced myself that I’m not stupid. Yet, I’m still struggling to develop an intuitive understanding of these complex standards. And I’m not alone.

Richard Monson-Haefel, a distinguished technologist, published a 960 page book on the J2EE 1.4 versions of these Java Web Services specifications in late 2003. 960 pages! That is all the evidence anybody needs to prove that this stuff really is complex. Its not that any one particular topic is all that difficult. Sure, it takes a little while to figure out what the JAX-WS API does – for example. But, the real difficulty is getting your mind around all these APIs and how they relate to the underlying Web Services standards (e.g., XML, WSDL, and SOAP), the HTTP protocol, and the other Java EE container services (e.g., dependency injection). This complexity can make working with the JavaEE5-WS standards feel awkward and unnatural.

During the past two years, there has been a growing chorus of leading technologists - Monson-Haefel among them - bashing the Enterprise Java Web Services standards. And I agree that it is very difficult to do useful SOA-style application development work with the J2EE 1.4 versions of the Java Web Services standards. But, I have trouble agreeing that the specifications themselves are the real problem. Instead, I suspect that the problem itself – creating a general purpose framework for Web Services development – is just plain complicated.

Richard Monson-Haefel posted this email on his blog on April 22, 2006. It summarizes pretty well how a lot of us feel after having spent a lot of time working on Java Web Services:

Dave Podnar’s 5 Stages of Dealing with Web Services

1. Denial - It’s Simple Object Access Protocol, right?
2. Over Involvement - OK, I’ll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P,… specs. next, I’ll check the Wiki and finally follow an example showing service and client sides.
3. Anger - I can’t believe those #$%&*@s made it so difficult!
4. Guilt - Everyone is using Web Services, it must be me, I must be missing something.
5. Acceptance - It is what it is, Web Services aren’t simple or easy.

One thesis of this book, simply stated, is that Web Services are hard. We need to accept that fact and move on. Web Services are hard because they are a form of distributed computing and distributed computing is just about the hardest problem in computer science.

Don’t Drink That Kool-Aid

In early 2001, when Ariba, IBM, and Microsoft published WSDL 1.1 as a W3C Note, Web Services were envisioned as a way make distributed computing easier. No longer would developers need to understand CORBA to create cross-platform, distributed applications. Even better, Web Services were envisioned as a technology to make distributed computing over the Internet possible.

Like me, most Java developers bought into this early Web Services vision. It made sense given our experience with the Internet during the 1990s. HTML over HTTP had fueled the astonishing growth of the World Wide Web – a distributed computing platform for people. We believed that standards (like SOAP and WSDL) for XML over HTTP would fuel similar growth for Web Services – a distributed computing platform for business applications.

We all drank that Kool-Aid. We believed that Web Services would make distributed computing easy.

The leaders of the Enterprise Java industry set to work implementing the Web Services vision. Along the way to realizing this vision, the Java industry discovered that they had created some pretty daunting specifications. The people who read the JAX-WS, JAXB, and other Enterprise Java Web Services specifications – including myself – got alarmed. We figured that something must have gone wrong. We assumed that the Expert Groups leading these specifications had gotten off-track. We got disillusioned and bitter about the lost promise of Web Services. We started bickering amongst ourselves about SOAP vs. REST and who is to blame for the complexity of the Java Web Services specifications.

But the complexity problem doesn’t result of choosing the SOAP framework instead of REST. It’s not a result of over-engineering on the part of the Expert Groups. As the Expert Groups got down to brass tacks – trying to make the Web Services vision happen – they rediscovered that distributed computing really is a daunting challenge. SOAP, WSDL, XML, and even REST, are not going to make distributed computing easy.

Certainly the Enterprise Java specifications for Web Services are flawed. But that is to be expected – new technologies always come with mistakes (look at EJB). The mistakes get corrected and flushed out with subsequent versions [1].

As one example of how the Enterprise Java specifications have improved, consider JAX-WS 2.0. Chapters 6 and 7 describe that specification in detail, so for now, I’m just going to give a preview of why I think it’s such a big improvement over JAX-RPC 1.1. For starters, the JAX-RPC data binding has been removed and the specification has been simplified to focus entirely on the WSDL to Java mapping. The XML Schema to Java data binding from JAX-RPC has been eliminated and the data binding features in Java EE 5 are provided by JAXB 2.0. Second, JAX-WS lets you use annotations to control the shape of the WSDL generated from a Java interface. The use of annotations in this manner simplifies and in some cases eliminates the need for the deployment descriptors required to deploy a JAX-RPC service. Third, JAX-WS provides interfaces (Dispatch on the client side, and Provider on the server side) that enable programmers to directly access and work with XML – effectively bypassing the JAXB data binding when they don’t want to use it. For certain, JAX-WS 2.0 could still be improved greatly. The biggest improvement that I can think of would be to provide an alternative binding (in addition to JAXB) that lets the developer work directly the native XML types that are specified in a WSDL and its associated schema. Some type of XML extension to the Java like XJ [XJ] might do the job. Much of the complexity and confusion that developers experience when working with JAX-WS relates to the difficulty of determining how the JAX-WS / JAXB generated classes created by the JAX-WS WSDL compiler map to the XML messages specified in the WSDL. But, that is a whole research area (creating a language that makes it simple to program directly with native XML types) unto itself where we are all still waiting for some breakthroughs. My point here is not that JAX-WS is ideal, but simply that is has improved on JAX-RPC much as EJB 3.0 has improved on EJB 2.1.

To summarize, in the years since the WSDL specification came out, the Enterprise Java community has created from scratch a Java-centric platform for distributed computing based on Web Services technologies. This has been a Herculean task and it shouldn’t surprise anyone that the specifications are difficult to understand! Viewed from this perspective, the JavaEE5-WS standards are not bad at all. In fact, they are a huge step forward toward enabling Enterprise Java to become a SOA development platform. These standards give us the APIs that we need to wrestle with the complexities of Web Services development.

So why are we disillusioned? What lesson should we be learning as we wallow in our disillusionment? I think it is the same lesson that we learn over and over again in this business – “Don’t drink the Kool-Aid”! If we didn’t start out by assuming that Web Services was going to be a silver bullet for distributed computing, we wouldn’t be disillusioned. Instead, we would be optimistic.

Round Pegs and Square Holes - Application Frameworks vs. Toolsets

Realizing that Web Services are intrinsically difficult forced me to rethink my assumptions about the JavaEE5-WS specifications. I no longer believed that these specifications could be significantly simplified. I accepted their complexity as the natural expression of the complexity of the underlying distributed computing problem.

Instead of viewing JavaEE5-WS as an application framework for SOA-style development, I recognized it as a toolset for distributed computing. My problem had not been stupidity, but using the tools incorrectly. Trying to create SOA applications with the JavaEE5-WS technologies is like trying to pound a square peg in a round hole. JavaEE5-WS is not an application framework.

Application frameworks make programming easier by encouraging application development along the lines of a particular architecture. For example, the Apache Struts [STRUTS] framework encourages the applications based on the Model 2 or Model View Controller (MVC) framework. Frameworks offer a layer of abstraction on top of complex toolsets. The layer of abstraction encourages you to program in a certain way. By restricting your programming choices to a sub-set of proven patterns, the framework makes your job easier and less confusing.

Application frameworks can also encourage good design. For example, in Chapter 4, I discuss the use of centralized XML Schema libraries as a mechanism to promote separation of concerns. Such libraries separate the type definition process (a necessary part of creating SOA application with Web Services) from the interface definition process (i.e., creating WSDL representations of individual SOA components). A good SOA framework, therefore, should encourage the use of XML Schema libraries and promote the reuse of schema across WSDL documents.

Application frameworks employ toolsets, but they go beyond toolsets. They encourage a particular manner of using toolsets. Struts, for example, employs Servlets and JavaServer Pages (JSP) among other toolsets. On top of these toolsets, Struts provides a framework of classes (e.g., Action, ActionMapping) for building applications according to the MVC framework.

Thinking through the Struts analogy to Web Services, I realized that JavaEE5-WS provides a toolset but not an application framework. To develop SOA business applications, I really wanted an application framework like Struts - not just the underlying toolset.

Along these lines, I started to think that a useful SOA application framework could be created on a foundation analogous to the ActionMapping and Action classes from Struts. In Struts, an ActionMapping maps an HTTP request to an Action instance that encapsulates calls to the appropriate business logic and dispatches the response to the appropriate View. Likewise, I thought, a SOA application framework could have a customizable Controller layer that receives SOAP messages and dispatches them to the appropriate implementation class. In this approach, the WSDL representation can be thought of as the View (using the MVC analogy), and the Java classes that implement the WSDL are the Model. One current limitation with the JavaEE5-WS toolset that hampers the implementation of this approach is that this dispatching process (analogous to the Controller) is difficult, if not impossible, for the programmer to manipulate. That is because it is hard-wired to correspond to the WSDL to Java mapping defined by JAX-WS. What control the programmer has over dispatching comes through annotations which are embedded in the target Java classes themselves. The JavaEE5-WS design is analogous taking the ActionMapping (Controller) and embedding it in the business logic (Model).

Don’t worry if this analogy to Struts seems confusing at this point. Chapters 9 – 11 explore the concept of a Java application framework for SOA in detail. And you don’t have to be a Struts programmer to understand it. At this point, I just want to give you a flavor for where I’m headed with the application framework idea.

The good news is that, by implementing the JavaEE5-WS toolset, the Enterprise Java vendors have done a great deal of hard work that paves the way for the development of application frameworks for SOA. One just has to get a little clever to work around some of the JavasEE5-WS limitations when attempting to create a SOA application framework.

Epiphany

Understanding the need for SOA application frameworks built on top of the JavaEE5-WS toolset was my epiphany. Instead of trying to create SOA applications using JavaEE5-WS, I began to think about how to create an application framework for SOA.

The result is contained in the last three chapters of this book – an effort to show how application frameworks for SOA can be created using JavaEE5-WS.

Before discussing either the JavaEE5-WS toolset APIs, or how to implement a SOA application framework on top of it, I need to introduce some common terminology in order to discuss the different components of a platform, like Java EE 5 Web Services, or Apache Axis, that enables the development and deployment of Web services. I call such a system a Web Services platform. The next section introduces what I call the Web Services Platform Architecture (WSPA), which provides the common terminology that is used throughout this book for discussing Web Services platforms. Think of the WSPA as our reference architecture. As we discuss Java EE 5 Web Services, we will refer back to the WSPA to discuss its strengths and weaknesses.

[1] Note that EJB 3.0 continues to improve and implements advanced Aspect Oriented Programming and Inversion of Control features that its many detractors have been calling for.

In the Java EE 5 Web Services programming model, JAX-WS is tightly integrated with JAXB. To invoke a Web service with JAX-WS, you typically generate Java proxy classes from the Web service’s WSDL using a WSDL compiler tool such as the GlassFish wsimport utility. (For a quick intro to invoking Web Service’s using JAX-WS and the wsimport utility to compile WSDL, see: The Java EE 5 Tutorial). These proxy classes are largely compiled from the WSDL’s schema using the JAXB schema compiler and its XML Schema to Java mapping.

Sometimes, however, you might not want to use JAXB generated classes to invoke a Web service. You might want to use another binding tool like Castor, XML Beans, or JiBX. Replacing JAXB with a tool like Castor makes sense in situations like these:

You want to use your existing Java classes to invoke the Web service. For example, you might have a CreditCard class that you’d like to use, rather than dealing with the machine generated representation of a credit card produced by JAXB.

You can’t or don’t want to add JAXB annotations to your existing classes. If the classes are in production, you may not be able to modify them. Or it may require a lengthy process of modification, unit testing, system testing, etc. to get annotated versions of the classes put into production. In such situations, it may be easier and faster to work with a tool like Castor than JAXB.

You may already be using Castor, or another binding tool that you like, and want to continue using it along with JAX-WS.

If any of these situations describe you, you are in luck. JAX-WS is flexible enough to work with other Java/XML binding tools. Read on to see how it’s done.

This blog shows how you can use the Castor (www.castor.org) Java/XML mapping tool and the JAX-WS Dispatch interface to map existing Java classes to XML message that can be used to interact with Web services. These same techniques can be applied to work with other Java/XML mapping tools as well. I have chosen Castor for this example simply because it is a relatively popular open source tool.

The example used here is a simple purchasing Web service. This service has an operation named requestOrder that enables you to place an order for a list of items and get back an order confirmation. As you can see in the RequestOrder WSDL, the req:requestOrder element used to invoke the requestOrder operation, contains information such as the customer number (req:CUST_NO) and credit card (req:ccard). The req:ccard element has type oms:BUSOBJ_CCARD. If you were to use a WSDL compiler to generate Java proxy classes from this WSDL, the credit card element would be represented by a JAXB generated class compiled from the oms:BUSOBJ_CCARD type defined by the orders.xsd schema.

But, suppose that you want to use your existing credit card class, like the one below. This CreditCard class is a simple structure containing the properties of a credit card (e.g, card number, expiration date). In this example, we will use Castor to bind it to the credit card XML type - oms:BUSOBJ_CCARD - used by the Web service.

Castor enables you to map existing Java classes to XML. Rather than using annotations, like JAXB, Castor uses an external mapping file. So, to map your classes to XML, you create a mapping file that associates each class and its properties with an XML type or element and its children.

This snippet from the Castor mapping file (the entire file is here), shows how the Java property expireDate gets mapped to the oms:CC_EXPIRE_DATE element in the oms:BUSOBJ_CCARD schema.

Once you have mapped all your classes to the corresponding WSDL schema types (e.g., credit card, items, etc.) you need a wrapper class that bundles these parameters together. This is the class that you will map directly to the contents of the SOAP message that invokes the Web service. In this example, the wrapper class is called MyRequestOrder:

You can see how the MyRequestOrder class is mapped to the SOAP request element (req:requestOrder) in the Castor mapping file here.

The code below shows how to invoke the Web service using these classes (i.e., CreditCard, MyRequestOrder, etc.) and the Castor mapping file. At the beginning of this code, the mapping file is loaded into an instance of org.exolab.castor.mapping.Mapping. The Castor Mapping class plays a role similar to the JAXBContext class in that it is used to configure marshallers and unmarshallers. Next, an instance of MyRequestOrder is created along with a ByteArrayOutputStream to marshal it into. The Castor org.exolab.castor.xml.Marshller instance is constructed as a wrapper around the ByteArrayOutputStream. Then, the Marshaller is configured by loading in the Mapping instance using the setMapping method.

The method invocation m.marshal(requestOrder);
marshals the MyRequestOrder instance to an XML document (stored in the ByteArrayOutputStream) according to the rules specified in the Castor mapping file that was loaded. From this point, the Dispatch instance is created an invoked using the XML document generated by Castor.

As you can see from this code snippet, it is the Dispatch interface that enables us to use Castor instead of JAXB as the Java/XML binding mechanism. Using Dispatch, you can send XML directly to the target Web service. That XML can be generated by Castor, XML Beans, JiBX, or whatever your favorite tool binding tool is.

This example is explained in a lot more depth (along with full source code and installation instructions to build and run it with GlassFish) in Chapter 6 of my book SOA Using Java EE 5 Web Services.