On 07/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote:
Robert Greig wrote:
> Let me ask another question: if you came across a database startup
> that had some special features only available if you ditched JDBC,
> would you want to use that product? Would you invest your own money in
> that company?
This is a reasonably good analogy, but it argues against the point you
are trying to make.
If what I want is database functionality, and I want to be able to
access the database from multiple platforms, I can't use just JDBC, I
also need something that is not dependent on the Java language or the
Java platform, so I wind up using both JDBC and ODBC, and very likely
ADO.Net. Of course, not all databases support all of these interfaces,
and not all of these interfaces are available on all platforms, and
these three APIs are gratuitously different in things that could easily
have been done the same way.
Of course, in the database world, SQL implementations also differ
markedly, but suppose SQL worked the same way across databases and we
were designing an API to access relational databases across platforms
and languages. Would we want to use one model for everything but Java,
then use JDBC for Java? I think it would make much more sense to provide
one consistent API across languages, and provide an alternative Java
API, which would use the same code base as the native Java API.
Jonathan
Providing two distinct APIs seems like a clean way forward with new
applications but it doesn't seem to offer much in the way of migration
for existing JMS API users. They may not wish or be able to re-write
their application to make use of the new AMQP features but their
application may have need for some of them. Are we really going to say
to that group of people the only way to do it is to re-write?
As long as we provide a JMS extension that allows JMS applications to
access the AMQP layer then it doesn't really matter to me what is
going on under the covers. Existing users just need an easy upgrade
path.
--
Martin Ritchie
