| Author |
Message
|
| Gervas |
 Posted: Wed Apr 28, 2004 3:15 am Post subject: Next-Generation Middleware |
 |
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
If you have built distributed Java-based systems, you have probably used JMS as well as MQ, not to mention other middleware, be it tightly or loosely coupled. Whatever middleware you have used you might well have wished it was automatically adaptable to change in application structures. If this is so have a look at an article in the Inquirer e-magazine which also offers a free software download. You can find this article at the link below:
http://www.theinquirer.net/?article=15197
Gervas |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Apr 28, 2004 3:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, personally, I keep hoping that applications will be automatically adaptable to changes in infrastructure.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Gervas |
| Posted: Wed Apr 28, 2004 5:19 am Post subject: Next-Generation Middleware |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
Yes, that would be wonderful! Sad reality is that once an integration schema is implemented, those responsible find that they are not dealing with a static application structure. Applications change, get removed and new apps get installed. Companies get bought and sold. Data structures change, not always with close enough reference to the apps using them. Distributed processing often ends up reflecting the uncoordinated chaos of the real world 
Gervas |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Apr 28, 2004 5:55 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
How does this differ in actual implementation from what we already have in the market, viz, MQ/MSMQ. I see almost all the features that MQ provides in this product, with a few additional stuff here and there.
And the other question to ask would be, how would it benefit me or rather how can i make maximum use of it, if i am using MQ.
Cheers
Kumar |
|
| Back to top |
|
|
| Gervas |
| Posted: Wed Apr 28, 2004 6:13 am Post subject: Next-Generation Middleware |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
Kumar,
Good point. This is not a trivial one, but here goes for starters:
When building a large application structure without multiple apps and multiple sources and formats of data, it is preferable to build explicit models to cope with this ever-shifting wealth of information. You can leverage Autevo technology to do this in a way which you cannot with MQ or other message-oriented middleware, MOM at best being capable of building poorly formed implicit models.
There are a couple of whitepapers which you might find useful for background reading on this:
• Evolutionary Model Driven Integration (MDI)
• Autevo, Javaspaces and the Publish/Subscribe Paradigm
You can find these at http://www.intamission.com/whitepapers/default.asp
Gervas |
|
| Back to top |
|
|
| Gervas |
| Posted: Wed Apr 28, 2004 6:16 am Post subject: Next-Generation Middleware |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
Sorry, I meant "with multiple apps... " not "without..."! Silly me!
Gervas |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 28, 2004 8:02 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Gervas,
can you explain how it helps us 'MQ' people?
this is MQSeries.net not eai.net or MessageQ.com ...
sofar feels like an ad for BEA WebLogic in WebSphere Advisor...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Gervas |
| Posted: Wed Apr 28, 2004 8:55 am Post subject: Next-Generation Middleware |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
WebLogic and WebSphere are wonderful products as we all know, and yes you can of course use this technology with J2EE app servers! However to return to MQSeries, we have an MQ adaptor (two-way adaptors are relatively easy to develop in this context). Soon there will be a Jini-XA transaction bridge. This will enable you to connect an MQ-type bus to Autevo and thus run MQSeries in parallel with other middleware connectivity paradigms, such as RPC, other MOM, CORBA, ESB, publish/subscribe etc. This will give you the advantage of both MQSeries’ and Autevo’s versatility, the latter including a resilient, decoupled structure tolerant of module failure.
Gervas |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Apr 28, 2004 10:15 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I havent played around much with MQSI/WBIMB(or whatever acronym is used these days...:).. ), but isnt this supposed to do more or less what you say this new Autevo is going to achieve.
And since this is a proven technology, one would probably want to stick with it unless there is more to offer. Just my thoughts, and that doesnt mean Autevo is in any way a wrong choice, since i havent used it, i cannot really comment on its scope and viability.
Cheers
Kumar |
|
| Back to top |
|
|
| Gervas |
| Posted: Wed May 05, 2004 12:50 am Post subject: Next-Generation Middleware |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 6
|
Kumar,
Sorry for the delay, but I hope this answers your points:
One significant difference between Autevo and traditional
middleware such as MQSeries, JMS, or TIBCO's Rendezvous is that it
supports an explicit common information model that can range in
complexity from simple data structures to full object graphs. This
provides a much richer shared vocabulary for the components of a
distributed system, enabling collaboration instead of simple
communication.
Another difference is that Autevo is next-generation middleware
in that it supports all the traditional messaging paradigms, including
publish/subscribe, message queues, and request-reply. Most
importantly, it allows all of these to be used simultaneously.
MQSeries is an excellent technology, especially for simple,
straightforward messaging requirements. As the complexity of the
messages and interactions increases, though, more effort is expended
in using the product than in solving the actual business problem. In
those situations, Autevo should be considered.
Gervas |
|
| Back to top |
|
|
|
|
