[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMLBlaster as a JMS implementation
> > How would adding support for the JMS API be a drawback? It would
> > 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
> 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 ]