Re: XMLBlaster as a JMS implementation

["Kyle Cordes" <kyle at kylecordes.com>]

> > How would adding support for the JMS API be a drawback?  It would
not
> > mean you need to remove your powerful, simple API, right?
>
> No, but one thing which might be hard to integrate is the
> matching from key/values to xml meta informations and vice versa.

Certainly it is possible that the JMS interface might not support the
full richness of what XMLBlaster can do.  But I think you could find a
way to do the XML meta information through the JMS interface.

> > >From an application developer point of view, it's a lot more
> > future-proof to adopt a standard API (JMS) than a proprietary one.
>
> JMS is no standard, it is a spec organized by a company called Sun.
> (But you are somehow right, this is currently accepted as kind of a
> standard).
> And the world knows other languages than Java.

Certainly I would not suggest you abandon the cross-language work you
are doing and become "just another JMS implementation".  However, when I
am programming a Java app that needs to talk to MOM, I would prefer to
use the JMS API.  It is indeed a Sun spec as opposed to a standard, but
as you point out it is being widely accepted by MOM vendors.

[ Kyle Cordes * kyle at kylecordes.com * www.kylecordes.com ]
[ Training and Development Services: Java, Delphi, PHP,  ]
[ ASP, ASTA, Web Applications, n-tier systems, etc.      ]
[ Delphi developers: Visit the BDE Alternatives Guide    ]