This content has been marked as final. Show 4 replies
I guess you could create your own implementation imitating TMQFORWARD that pretty much does what you want. I have once done that (for another purpose than yours) when TMQFORWARD wasn't able to do exactly what we needed it to do (we had a very specific condition for when it had to quit draining the queue). It wasn't really rocket science.
Do you need to pass on an entire TPSVCINFO structure in this case, or just the data/len portion?
I like the name "message-driven-banana" by the way :-)
Hi Per (and others),
you're right there and I guess we're not actually intrested in the entire TPSVCINFO, merely just (as you said) 'data', 'len' and perhaps 'name' and the entire TPSVCINFO wouldn't even make sence (or would it?)
Can you reveal how you did your "TMQFORWARD-replacement" ? It would be nice if the solution somehow could be configured via ubbconfig and tmboot:able/tmshutdown:able
A 'banana' tastes better than a 'bean'
I'm not entire sure I understand what you are trying to accomplish. Maybe just because its Saturday morning and I haven't finished my first cup of coffee. What is a service that can't perform its task synchronously? I don't know what a banana is in the context of Tuxedo? Doesn't an MDB operate synchronously? And isn't an EJB or MDB essentially the same as a Tuxedo service (EJB) or Tuxedo service invoked by TMQFORWARD (MDB)?
What exactly is it that TMQFORWARD doesn't do? Is it really just the reply queue part?
Oracle Tuxedo Chief Architect
assume that a (client)service A wanna perform some task asynchronously, it writes a request-message to a queue with a reply-queue (and perhaps a correlation-id). If the (server)service B cannot handle the request synchronously, e.g. it needs to do another asynchronous request to yet another service C, the reply-queue and possible correlation-id needs to be persisted so that service B can write the response back to queue provided as reply-queue by A whenever B receives the response from C
If you're invokin' (server)service B with plain TMQFORWARD, B won't get any message-properties (as reply-queue and correlation-id) but merely the payload (i.e. the buffer). Of cource there are ways to solve this and one solution could be that service B has some knowledge 'bout where to put the reply, which is not very SOA and another solution is to let reply-queue and correlation-id etc be a part of the payload (e.g. some none-business-related-redundant FML-fields) which is not very generic and forces service A to have extra/special knowledge about service B's implementation which is, again, not very SOA
A JMS-MDB is invoked with a "message" that contains both payload and properties. An EJB-MDB may operate synchronously or asynchronously. The requestor already know it's using a asyncronous pattern and should not care if a response ends up in its reply-queue after 1 millisecond or after 2 days. We would like some similar mechanism
So, yes, a Tuxedo service is essentially the same as an MDB minus message-properties and we simply wanna be invoked with the message-properties as well
An MDB is a Message-Driven-Bean and I assume that name cannot be used outside the J(2)EE-world (or whatever the acronym is this week) and therefore I suggested a Message-Driven-Banana instead