RE: What is XP?

["Eve L. Maler" <eve.maler@east.sun.com>]

Hi again Michael-- I asked Anne to respond, but she's not on XML-Dev, so 
I'm continuing to pass things along.  See below.  I hope you find this helpful.

         Eve

At 12:06 PM 12/21/00 -0800, Michael Brennan wrote:
>Thanks for passing this reference along. I am pleased with the statements
>made. Overall they seem technically accurate and provide a more balanced and
>fair perspective than some of the statements from Sun representatives I've
>seen quoted before.
>
>I would be more pleased and encouraged, though, if Sun were pursuing a more
>generalized XML messaging API with it's "M Project" rather than focusing so
>exclusively on ebXML. Support for ebXML is valuable and sensible. But Sun
>has a track record of providing more modular and flexible APIs in the Java
>platform, allowing different service providers to be plugged in to support
>different protocols with the same client APIs. The M Project, in contrast,
>seems to be taking a much narrower and more constrained approach (at least
>as far as I can tell from what is currently publicly available). Citing the
>fact that SOAP is not an international standard doesn't seem to me to be a
>good reason for not supporting it. SAX is not an international standard,
>either, but Sun wisely supports it in JAXP.
>
>If Sun were to provide a more generalized XML messaging API that supported
>different protocols to be "plugged in" (including both SOAP and ebXML), I
>think that would be a valuable contribution to the development community. I
>hope Sun and its collaborators on that effort will take that into
>consideration. Certainly, ebXML is more suitable for B2B ecommerce at this
>stage, but SOAP has substantially greater momentum and developer mindshare
>for application integration. We have yet to have any of our customers or
>partners indicate a desire to integrate with us via ebXML, but we have
>already had a couple of partners want to integrate with us via SOAP (and we
>are providing that option for them).
>
>It would also be valuable if Sun provided a more robust foundation for XML
>messaging than that currently afforded by the Java platform. The HTTP
>support that is standard in Java, for instance, suffers from antiquated
>protocol support and some significant design flaws making XML messaging
>problematic and proper SOAP support impossible. Fortunately, Sun's Open
>Source Brazil project has an HTTP implementation that solves the key
>problems. I'd love to see some of that work make it into the Java platform
>(and I'd love to see Sun provide SSL support in that class, and support for
>content streaming in chunked encoding form rather than requiring that
>everything being sent in a request be buffered up front in memory).
>
>With that said, though, thanks for sharing the statements. I am encouraged
>by them and look forward to seeing what comes out of Sun's efforts in this
>arena.

Michael,

I hope you'll be pleased to hear that JAXM is, in fact, designed to be a
general-purpose abstract Java API for XML Messaging. But please don't
confuse JAXM (an API) with M Project (an implementation). M Project is an
implementation of the JAXM API that supports the ebXML Message Service.
Other JAXM implementations can be developed to support other XML messaging
systems such as SOAP.

The JAXM Expert Team did its best to produce a generic XML messaging API.
There are some technical challenges associated with creating a completely
generic XML messaging API, though. For example, there are no standards for,
or even any useful abstractions of, a meta message header. Any completely
generic API to get or set message header elements would require relatively
complex programming. One way to simplify the API is to build-in specific
support for certain types of headers. JAXM provides specific support for
ebXML header files. Having specific support for ebXML doesn't preclude use
of other XML messaging systems; it just means that it is easier to use ebXML
than other messaging systems. If you'd like to see specific support for SOAP
added to JAXM, or any other enhancements, please join the Java Community
Process (http://java.sun.com/jcp) and participate in developing the next
version of the API.

Regards,

Anne Thomas Manes
Director Market Innovation
Sun Microsystems