The .ppt file on Advantage provides an overview of wM 6. Many wmusers.com no doubt attended the webinar on Mar 19 to see the presentation. A couple of features in the presentation caught my attention.
- IS can hold documents in a queue for delivery
IS/TN veterans will recognize the need for having delivery queues. I’m not privvy to the implementation details but I assume the delivery queue facility provides features beyond what TN and private/public queues provide. This is a Good Thing.
What perplexes me, however, is that they are calling this “client-side queueing.” My understanding of client-side queueing is the ability of an application to queue a message/document for publishing even if the broker/server which handles publishing is down. When the server comes back, then docs in the client-side queue are published. From what has been described about wM 6, clients cannot post docs to queues if IS is down (someone please correct if this is incorrect).
The wM description of what they are calling client-side queueing sounds more like server delivery queues. This allows the server to queue up docs for delivery to clients, even if the client is unavailable for some reason.
What am I missing here?
- IS can publish “to itself”
Adapters hosted on the same IS can participate in pub/sub without going through a broker. Cool. Seems to me the next logical step is to allow IS boxes to do this with each other. Is this another step toward eliminating the broker, or at least bringing it into the IS fold? Does it make sense to just have IS do pub/sub within itself and within a P2P-like environment? If a pub/sub hub is desired, couldn’t an IS box be deployed for that?
Some may offer that broker will dramatically outperform IS in pub/sub operations. Agreed. But does it need to stay that way? Couldn’t IS be made to perform as well?
Toss in your two-bits…