Ray Lai

Unfortunately, no. Struts or alike is about user presentation, and is not directly related to building web services.
But personally I am involved in an initiative to package all Java application frameworks and add web services elements (e.g. orchestration) to brand them as Java web services framework for customers.

This is a lengthy and contentious subject -
* Lengthy meaning my book is on the entire subject. We have different types of best practices or patterns, e.g. architecture/deployment/quality of services patterns (ch 4), interoperability patterns (ch 5), integration patterns (ch6), security patterns (ch 7). I've attempted to summarize a few patterns for you from my book ch 4.
The quality of service patterns discusses how to improve the service quality of Web Services deployment. This includes scalability (SOAP Cache, JMS Bridge, Multiple Servlet Engines), reliability (State Management, SOAP logger), manageability (Publishing Web Services, Service Versioning, and Service Registry Content Management), availability (High Availability of Service Registry), and security (Service Registry Deployment). Some of these patterns are programmatic design patterns, and some of them are architecture patterns or best practices.
SOAP Cache � This pattern provides a structure to cache client-side or server-side service look-up that can reduce dynamic service look-up overhead. This can be used in conjunction with the Service Locator pattern.
JMS Bridge � This pattern illustrates how SOAP over JMS can be used to provide reliable messaging between two different JMS-based middleware. It can be used to bridge between two different middleware products or two system infrastructures using SOAP over JMS mechanism. The JMS Bridge is usually used in conjunction with Service Activator pattern. There are also object database products or middleware products that provide the same function.
Multiple Servlet Engines � This pattern is a best practice to apply horizontal scaling (multiple SOAP server hosts connected to a HTTP load balancer) or vertical scaling (multiple SOAP server instances in the same host) technique to improve scalability and performance throughput.
SOAP Server Farm � This pattern is a best practice to scale the SOAP processing capability (namely, SOAP server) horizontally or vertically using a HTTP load balancer. The SOAP server is primarily a servlet running on top of a web container, and handles SOAP message routing and processing. It is crucial to have more than one SOAP servers to ensure the SOAP-based Web Services are scalable and available by having a HTTP load balancer connected to a number of SOAP servers horizontally or vertically.
State Management � This pattern discusses the best practices of stateful and stateless Web Services. The design of stateful and stateless Web Services is dependent on the business requirements and technical constraints. Stateless Web Services that use RPC invoke remote business service (for example, from a mainframe), and thus they do not typically store state information. Stateful Web Services can use either RPC-style or document-style Web Services, and manage the state information for roll-back or failover programmatically. This will incur additional system resources overhead and more complex exception handling design.
SOAP Logger � This pattern makes use of the logging API infrastructure in J2SE 1.4 to provide service invocation and troubleshooting information for Web Services. It is important to track the service requester�s credentials, the remote service invoked, and the timestamp to a single logging infrastructure (or a Web Services management server) for managing Web Services and service level. The logged messages should have some structure or tiers, instead of disorganized or piecemeal logging information. Otherwise, application support personnel will not be able to diagnose the root cause with sufficient Web Services calls details.
Publishing Web Services � This pattern re-capitulates a common programmatic structure to use JAXR to publish, un-publish or discover Web Services from the service registry. It addresses the complexity of using different APIs for each UDDI or ebXML service registry product with standardized Java APIs.
Service Versioning � This pattern explains how different versions of the same business services can be defined and deployed in the service registry. This is usually implemented by associating the service version with the �Service Bindings� and the service end-points (or service bindings access URI). In parallel, the SOAP header also needs to specify the service version.
Service Registry Content Management � This pattern applies the content management process to managing service registry contents. If an enterprise has a single master service registry, then the contents update can be replicated to the replica service registry using the service registry infrastructure (for example, LDAP replication, proprietary registry replication features). However, if an enterprise has multiple service registries, the administrator should define a set of registry content management process, including the use of a staging service registry to host all service information changes, and the approval process to update and replicate the changes to the replica service registries.
High Availability of Service Registry � This pattern simply explains how to make the service registry highly available using hardware clustering or container clustering features. If the service registry is implemented using directory server, the LDAP replication topology may provide high availability or failover feature, and it may not require hardware clustering.
Service Registry Deployment � This pattern depicts the variation of deployment scenarios where a service registry should be deployed. For a private service registry or an intranet environment, the service registry can be deployed behind the de-militarized zone (DMZ). For a public service registry environment, the service registry should be deployed before the de-militarized zone for security reasons.
* Contentious, because not every one agrees there needs to be web services patterns. For some J2EE architects, web services patterns may be something they can re-use existing J2EE patterns if they are using J2EE to build web services.

Originally posted by Rashmi Tambe:
1. I don't have any prior experiance of web services. How would this book help to be comfortable with web services? I mean, for a beginner like me, would the book be easy to digest?

I got some postive feedback from both management and techies. The book looks readable even for those who have no background in web services. So, give yourself a try.

2. The only time i had interaction with web services was when i was asked write a web service wrapper on top of an ejb (one seesion facade and a few entity beans) using a special weblogic ant task. That did not help me to understand web services? My basic confusion was are you supposed to write a web service over an EJB or it can talk to any distratibuted component? this question may sound very dumb, but i really want to know?

Earlier books on web services suggest using a utility (e.g. Axis's java2wsdl) to expose a servlet, Java bean, EJB or C++ function as RPC-style web services. This is only one style, 'cos you can write asynchronous doc-style web services by using messaging (e.g. SAAJ or JAXM). This will be a completely different paradigm than your weblogic EJB web services experience.
perhaps it's useful for you to go back to the basics of what makes web services, and how they can be created (doc or RPC-style). Have a feel of the samples in Axis or JWSDP to experience how to create a simple web service. For example, my book ch 9 section 9.4 has a simple Axis step-by-step tutorial, and ch 3 section 3.8.4 has a simple JWSDP step-by-step tutorial.

3. I heard that sun is coing up with web services certification? do you have any idea abt that?

Yes, the team will meet in April, probably the second time, to create the exam questions.

4. Is this book available in india?

You can order via Amazon, barnes and nobles, bookpool.com or your local store.

5. I dont know your back ground yet, i mean u must be having a solid one to write a book on such upcoming technology. but I really want to know abt your technical experiance, what made u write this book etc.

I have >15 years working experience, particularly in financial services, transportation. My last 5 years are focused in Java-based technology. I started to build up my working experience in hands-on web servcies architecture and simple Proof of concept experience in my consulting work. After I've done a few cases, then I start to write this book, and verify it with my customer consulting. I believe real experience counts, not pure research.

Originally posted by Avi Nash:
I also want to know
1. can state be maintained between SOAP requests and if yes, how?

Basically you have to maintain states between SOAP requests.
If you use a stateful session bean to invoke remote web services, you can store states between SOAP calls. There are some disadvantages obviously.
One argument is that your remote web services may be tracking the states already. so why are you tracking additional state information? perhaps you can use a stateless session bean to invoke remote services, and keep track of the return code (instead of full state information) for re-try or recovery.
State management is a complex subject, and can be very debatable. ch 4 pp. 188-192 section 4.8.5 discusses the subject.

2. disadvantages of using web services? and

One disadvantage is that web services can be quickly deployed, and it may take longer time to make it right (due to the complexity of deployment, and SLA management). You have to build web services it seriously with subject matter experts. You can't do web services half-hearted - you have to do it right, considering all layers and platforms. For example, wrapping your legacy apps with SOAP, and exposing them in production. This won't work because it does not have a thorough security design.

3. What is better option for web services - .NET or J2EE?

There is no better option, because people use heterogeneous platform for production. There's always proponents for specific platform technology, no matter .net or J2EE - you always hear from the .net guys saying .net web services is fast and developer-intuitive; the same for Java guys.
Hope these discussion makes sense to you.

Originally posted by Tonny Tssagovic:
I just wanted to ask you about the scope off the book. Does it include a dummy step by step description of how to use an open source implementation/tool like Axis to create/consume web services?

My book ch 9 pp. 500-510 section 9.4 includes a concise step-by-step guide to build web services using Axis. This is supplemented by an analysis (not summary) of the basic concepts and standards in ch 3. Ch 3 pp. 136-146 section 3.8.4 also includes a step-by-step guide to build web services using JWSDP as a contrast. This can give the readers a direct experience seeing the differences.

I am not very much interested in the standards (SOAP, WSDL, UDDI), since I prefer to go back to the standards for accuracy and depth when needed.

You're right. Many readers don't like reading books that summarize from standards specification (which is like a book summary in simpler English). What I intended to do is to articulate what I see the strengths/weaknesses, and the design implication of each web services technology. For example, I've argued the strengths and design implication of using ebXML (using SOAP as the transport and routing protocol) to build web services in p. 107.

What I would prefer is a step by step guide, then jump to Architectural level with patterns, as well as �real-life� examples, and strategies that help you make decisions.

ch 4 starts with defining what web services architecture is, and the logical components. Then it begins to introduce 25 design patterns, which are mainly architecture / deployment patterns in ch 4. Under each pattern, I tried to provide real-life examples how each pattern is used in the industry.

I just checked the table of contents, and it seems to have architecture/best practices and some �real. Examples� but it is not yet clear to me if there is Axis �start-up guide�.

Appendix C may be something you are looking for. It is a concise installation and setup guide. Section C.5 and C.15 are the specific sections.
However, Axis's own user guide (in the Axis doc set) is the best start-up guide. Basically, it says you drop the axis directory under your webapps directory of your web container.

If it does not, could you guys please guide me to such a book, I am confused by the different reviews of books at Amazon, and I need a single simple book that gets me started in no time!

Try Ramesh Naggapan's Developing java web services book. You should see Axis 1.0 setup/installation in details.

Is the WebService technology with its basic components (XML,SOAP,WSDL,UDDI..) the ultimate and definite solution for platform and application independent (and automated) communication? Is it the way to to realize real interoperability, no matter wich devices, languages or technologies are involved?

Some opponents of SOAP-based web services would argue that web services technology components are not just WSDL, UDDI, and SOAP (WUST?). The other service-oriented components are ebXML, ASN.1, ReSt, asap (asynchronous web services), etc.
From a broad perspective, we can also argue that service-oriented architecture (SOA) is the goal of web services architecture. You may already note that IBM has been selling SOA instead of pure web services pitch. SOA means real interoperability, no matter which devices, languages or technologies. Thus, Corba, C++ or Java can be a means to build SOA with web services.
Putting this in the perspective, SOAP-based web services may be the mainstream, while there are other mechanisms or alternatives.
Personally, there are advantages to staying with the mainstream, 'cos there are many tools and literature available. It's always healthy to hear different voices or perspectives, so that we know we can achieve the same goals with different means. Just my 2c input.

Originally posted by Hari Vignesh Padmanaban:
Should security be taken into consideration in web services? Does your book cover that ?

IMHO, end-to-end security should be considered in any applications, including web services. My book ch 7 discusses an end-to-end framework, some design strategies and some health-checklist for web services objects.
Typically, HTTPS protects client-to-server connection. XML encryption and digital signature will ensure data confidentiality and integrity at the message level. There are a heap of security protection mechanisms need to be in place to protect from message replay, message insertion, denial of attack, etc, which are outside the scope of WS-Security. For example, Liberty is a good single sign-on and authentication mechanism.
Here's the catch - many security book introduces the alphabets of WS-security, XML encryption, XKMS, etc. Readers need to put these technologies in the context of real life applications, and the different threats/risks exposed today. They really need a systematic methodology and scenarios.
I'm working with 2 other security gurus on a second book on J2EE and web services security patterns. We've introduced a factor analysis, and a comprehensive health checklist. You can refer to www.coresecuritypatterns.com. The book should be available by fall 2004.

It looks like your healthcare case is a good candidate for web services because:
1. there are many trading partners involved (medical labs, doctors)
2. point-to-point interfaces or traditional EAI will be an integration issue due to re-usability, portability, and interoperability
3. cost of integration is a key business driver
I heard that there are some interest in the healthcare industry, e.g. http://www.ebizq.net/topics/healthcare/features/1546.html, Gorilla Logic has produced a RFID-based web services for the healthcare industry and connect them using HIPPA.
Lasse has already suggested kSOAP as an infrastructure component to enable your Palm or PocketPC to "speak in SOAP". Also refer to my book ch 9, p. 486 section 9.2.2 for more details of wireless web services.

Originally posted by Arun Subramanian:
As someone exposed to J2EE but not at all to web services, what additional steps (in terms of new hardware, software, security etc) does one have to take to convert, say, a java application component to a web service or to put it like this, how easy or difficult is it to transform an existing software component into a web service.

Apache Axis provides probably the simplest example to expose a Java apps to web services. you rename your .java, and drop it under the webapps of your Axis servlet under Tomcat or J2EE apps server. Axis will automatically generate the stub/skeleton for you. This may be too simplistic for real life situation.
My book ch 9 pp. 500-510 (section 9.4.2) shows a simple exercise (step-by-step guide) to expose a Java component to web services using Axis's utilities java2wsdl and wsdl2java. Using these utilities, developers may spend a few minutes to create a web service.
The concept of exposing Java components is simple. You expose your servlet/beans/EJB to RPC-call. Your SOAP server (e.g. Axis) will route the SOAP-RPC call automatically by binding to your Java components (pp. 93-34 section 3.4.2).
Reality check. But in real life, there are many design complexities, e.g.
* not every Java component is RPC call; you may need both synchronous (RPC-style) and asynchronous web services
* state management issues (p. 188 section 4.8.5)
* need to consider how the apps security is designed (pp. 367-317 section 7.4.1)
* data type conversion and compatibility
* what to expose/other design considerations (e.g. p. 207 section 4.8.13) - fine-grained versus coarse-grained

Also, I work within a corporate intranet. Do we have any examples of intranet applications utilizing a web service in practice.

At Sun, many intranet apps are web services, e.g. our timecard for consultants, our travel expenses, our staff benefits system, internal messaging hub, payment services with bank, etc. They have been in production for at least 2 years.
I'm aware that many production web services are for external B2B integration, e.g. Sabre's travel services. Some customers also start with intranet first, e.g. brokers/traders' desktop risk models

Lastly, is your book comprehensible for a beginner?

Yes in general. But I'd recommend other better beginner books if you're looking for a step-by-step programming book on web services. Pls refer to a separate thread I posted on the different kinds of web services books.
My book was written with 2 target groups of audience:
1. Management, who are *beginners* but want to know real life case studies or examples, or want to do a business case/ROI for web services initiatives
2. Architects or developers, who already have a hands-on beginner book, but want to delve into advanced level of mainframe integration, architecture patterns, integration patterns, or security patterns. My book will serve as a companion book or an advanced book.
However, a refresher chapter of web services basic with some hands-on exercises are provided in ch 3. A detailed case study of complete programming examples is provided in ch 8. Pls note that this has complete design details using Unified Process methodology (elaboration details). This will be good for beginners, as I have not seen much detailed design coverage in many beginners' books.

Originally posted by Max Tomlinson:
1. As a relative newcomer to Web Services, I'm a little confused about which flavor of web services is the best to use: Sun's WSDP? WSIF?
Which version is the most open? And does it matter which platform one is developing on e.g. WebSphere? (OK, that's several questions)

I think you're referring to which developer toolkit to build web services. Sunm's JWSDP is a toolkit to generate stubs, to provide additional JAX pack (e.g. JAXR for service registry, XWS security for message encryption) for productivity. Now that JAXP, SAAJ and JAX-RPC are part of J2EE 1.4, the value of JWSDP will be highly focused on the integration of XWS, JAXB, JSF and registry server with your J2EE apps server. It is also logical to infer that JWSDP features will be good candidates for the next version of J2EE.
WSIF from IBM (now donated to Apache) is another realm of tool on top of the developer productivity toolkit. It is WSDL-centric, and does not provide similar set of productivity functionality. I wouldn't categorize them into the same functional class.
The term "open" is always relative. Not every Apache projects are widely acceptable or successful. No matter it's JWSDP (e.g. XWS security) or WSIF, it's always a good practice to avoid vendor-specific extension, and use the common denominator, say, J2EE 1.4. There's always a risk of migration to J2EE standard. And it's not easy to bet on.

2. Complex data types (marshalling Objects): what's the best way to deal with these? I know in the past this was an issue.

There are at least 2 different schools of thoughts:
1. Always use simple data types. Do your conversion before exposing as a WSDL. This addresses the issue of .net vs J2EE web services.
However, with many web services management tools, you can actually use a .net adapter (web services proxy) to translate the data types from .net client to J2EE.
2. Write your own marshal/unmarshall serializer.
I haven't heard of any major issues between J2EE clients using complex data types. Experience suggests it's better to have your own serializer for performance consideration. It's a matter of overhead and one-off development effort.
Note: WSI basic profile intends to address the interoperability of web services invocation and message content compatibility. Which means the data type compatibility issue should be addressed. However, I still prefer your own marhsal/unmarshal serializer.

Originally posted by Dave Knipp:
If they are publicly accessible, can this public access ever become a problem in the future? What are your experiences with this topic?

Many web services in production are private, i.e. you can't access directly from public internet. Even if you can, they use tight encryption (e.g. HTTPS and XML encryption) and authentication mechanism. Majority of early adopters tend to use HTTPS in general. Anyway, there was no WS-Security 2-3 years ago - no standard way to protect SOAP messages; HTTPS appeared to be sufficient for RPC calls.
There are also some web services in production available in public internet. The examples cited in public include ASU, Jarna, Adobe, Comvia, POSC, TCPL, etc. My book ch 2 section 2.5 provides some details. I'm aware that some financial services using web services are typically using HTTPS, but some of them use web services for server-side processing to aggregate account information from the back-end, without allowing the client-side to invoke the services directly.
It's difficult to conclude whether this "first-generation" web services security is secure, because end-to-end security spans across different layers and technology stacks. Early generations of web services use HTTPS and XML encryption, which covers client-to-server interaction, and message-level protection. But they are not necessarily sufficient, as there are many risk areas behind the DMZ firewall, and between service components. For instance, message replay can be hazardous even though you have HTTPS and XML encryption.
It's true that when more web services are available in public, the security risk will increase as they become more accessible to hackers. However, provided that architects / developers have strong apps security design to cover all layers and stacks, I'm confident that it is still safe and secure to provide public web services. For instance, Liberty provides a good security framework for single signon and authentication services. This will be a strong component to building end-to-end web services security.
Many customers I met today seem to be happy with web services security using HTTPS and XML encryption. Some are still awaiting for the final WS-Security or any market standard to be finalized. Most of them are fully aware of the need for stronger end-to-end security. But some thought HTTPS and XML encryption are just fine. IMHO, as the public are getting more awareness of what web services are, their awareness and demand for end-to-end web services security will increase.

Originally posted by Avi Nash:
1. When should we go for Web Services?

Difficult question.
Short answers - large number of trading partners, dynamic/complex integration requirements (e.g. frequent changes), need reusability, etc.
BUT - they all depend; it's a matter of spectrum of choices, relative pros/cons and constraints, political context, etc.
My book ch 2, p. 33 section 2.6.2 defines the list of attributes of the web services candidate.

2. When should we not go for Web Services?

Relatively easy to answer -
Do web services for technology sake, point-to-point interface that does not require reusability or frequent changes, low awareness of what web services is, high risk project, lack of business executive sponsor, etc.

3. For what kind (and what size?!) of projects should use web services?

My book ch 2, p. 41 section 2.6.6 discusses what kind of projects should use web services, e.g. high business value, thought leadership, process-oriented, etc.
Typically, from a management perspective, you don't want a large size high risk project to go for web services. It's the same principle for any emerging technology.
From my first hand experience, most early adopter customers start small project size, but high business impact (e.g. high cost savings, operational) but not necessarily mission critical. Small size means different things to different industries and regions, e.g. in terms of dollar, US$100K is considered relatively high in some Asian countries, but US$300K-500K is a small size project to some US companies. In terms of team size, team size of 10 or below is small to many companies. I did see many web services pilots are achieved by 3-5 top-notched architects/developers.

4. What are other alternatives instead of using web services?

Traditional EAI, middleware, screen-scrapping (tactical integration tools] are examples of alternatives.
Some even claim Corba, parameter-driven or OO-design are also alternatives.

5. What are the security features to be considered while using Web Services?

My book ch 7 pp. 362-434 defines a design methodology for web services security. Typically, you need different flavors of security for different stacks, e.g.
* Infrastructure, e.g. key management, directory server, identity server, host security hardening, intrusion detection, protection of web services objects/infrastructure
* Message level security, e.g. WS-Security, XML-encryption, XML-DSIG
* Messaging/routing level, e.g. web services proxy
* Policy-based, e.g. XACML
* Authentication, e.g. Liberty-based security
* Distributed security, e.g. SAML-based single sign-on
* Transport level, e.g. HTTPS
* Process-oriented, e.g. risk mitigation against replay, man-in-the-middle, Denial of attack
* Proactive security assessment methodology before production/checklist
e.g. p. 420 table 7-3 shows a simple checklist
I'm currently co-authoring with 2 specialists on a specialized J2EE/web services security book, which will be available by fall 2004.

Originally posted by Romeu Franzoia Jr:
Is there any fast way to learn the essential of web services???
I was looking for a good book, or a good tutorial for it.

You probably need different types of books. Some books cover 1-2 areas, and some may cover most areas but do not delve into details. There are plenty of good and free materials.
1. Management summary, architecture
James McGovern's Java web services architecture would be a good one.
2. Case studies, how they are applied, ROI/business case, and real-life examples
My book J2EE platform web services is in this category. ftp://ftp.prenhall.com/pub/ptr/sunsoft_books.w-053/lai/others/ shows free download of the chapter summaries.
3. Web services design patterns, strategies
There are 3 books in the market that fall into this category. My book also
provides 25 design patterns (3 pending patents).
4. Web services tutorial, programming examples
IMHO, Ramesh Nagappan's Developing Java Web services (Wiley) is probably the best so far.
Sun's JWSDP 1.3 tutorial is free download. I like it a lot.
5. Interoperability between .net and J2EE web services
There are not too many in-depth materials/books so far. There'll be 1 book coming out by fall 2004.
6. Specific / advanced topics, e.g. external/internal integration details, workflow orchestration, web services security
My book covers some interesting mainframe integration materials, which you'll find very unique so far.
There'll be an excellent J2EE/web services security patterns from SunPress in this fall, co-authored by Ramesh Nagappan, Chris Steel and myself. Stay tuned.
7. Free web services tutorial
JavaOne has many goodies, but very often you have to pay.
Nevertheless, you can download free Java One 2003 tutorials via
http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/xxxx.pdf
where xxxx is the slide # of a tech session.
[ February 25, 2004: Message edited by: Ray Lai ]

Originally posted by Frankie Cha:
I understand beside Generated Stubs, the other two ways of programming JAX-RPC clients are Dynamic Proxies and Dynamic Invocation Interface. Beside the programming differences which most books cover, what are the factors that influence the choice of these two methods of implementing web services clients? Could you briefly state the pros and cons of these two methods? Thank you.

With dynamic proxies, developers can simply refer to a WSDL. This simply denotes "static look-up". You do need to generate the service end-point interface (*IF) file though using wscompile or similar utility. This scenario is ideal if you are managing a set of WSDLs that do not require frequent changes.
With dynamic invocation interface (DII), developers can perform service discovery using UDDI or JAXR on the fly. They will create an instance of an RPC call, and instantiate with relevant service end-point information. This scenario is ideal for services that have frequent updates, or that involve frequent addition/changes in the service contents, or in the number of service providers/trading partners.
From a programming construct point of view, you've probably noted that
DII is slightly more complex, as you need to be more specific about what properties/attributes for the RPC call (e.g. call.setProperty(xxx)). But it gives you more flexibility in managing changes (e.g. changes in WSDL, changes in service versioning) that cannot be easily managed by dynamic proxies.
To summarize, dynamic proxies are simpler in program design (e.g. faster to code or debug), more suitable for static WSDLs, and thus less service lookup overhead. DII is more agile for managing web services changes (e.g. changes in WSDL content, changes in service versioning), but it requires dynamic UDDI or ebXML service lookup (and thus have overhead). Choosing which method will be a matter of design strategies, and a case of your web services changes requirement. For example, your online store has many merchants joining or exiting. The WSDLs are so volatile and service versioning becomes an issue. It won't be sensible to use the same WSDL all the time, as the merchant may simply add a new parameter next month. Thus, a DII client is more appropriate.
On the other hand, many early web services deployment use static WSDLs that are exchanged between trading partners. They don't prefer dynamic lookup due to (1) lookup overhead, which may cost 0.2-2 seconds/call, and (2) they don't like building a UDDI infrastructure, which may be exposed to potential security risks (e.g. Denial of Attack).
My book J2EE platform web services ch 4 p. 207 (section 4.8.12-13) discusses some performance information about lookup overhead. To mitigate the service lookup overhead, you may also consider using a SOAP cache (pp. 172-178, section 4.8.1), which can be a client-side or a server-side caching.

Originally posted by Pradeep Bhat:
How does JAXM fit into J2EE web services?

JAXM is one of the JAX pack (most of them are now J2EE 1.4) that enables doc-style web services. It is asynchronous in nature, and usually relies on the underlying middleware such as JMS that supports JAXM, ebXML, etc.
Unfortunately, JAXM is not widely accepted into the world of J2EE during the J2EE 1.4 discussion. It was political because Sun is pushing JAXM for reliable messaging, but IBM/Microsoft/BEA are pushing WS-Reliability. It's just a matter of interests (conflict of interests).
SAAJ, aka light-weight version of doc-style web services and subset of JAXM, is now decoupled from JAXM. It is a core part of J2EE 1.4.
Having said that, who uses JAXM-based web services? Some pilots done before J2EE 1.4 is finalized use it. TCPL in Canada has implemented reliable SOAP messaging using SOAP over JMS and some JAXM. Practically, it means you specify ebXML profile in the JAXM (that comes with Sun's JWSDP), and use JAXM as doc-style web services. The underlying reference implementation will treat this as reliable SOAP messaging by re-try or re-send if the recipient fails to receive it. This is all transparent to developers.