/Q and TMQFORWARD offers a beautiful mechanism to asynchronoulsy invoke a synchronous service with it's payload, i.e. the service can be used for two purposes
When the service in the asyncronous pattern it self does not have the ability to perform its task synchronously, it becomes more cumbersome. With /Q and TMQUEUE etc there's no built in immediate way to let the service retrieve the message-properties (reply-queue, correlation-id etc) i.e. to mimic e.g. JMS-MDB (or does it?)
This message-driven-service-mechanism can be done in various ways, but all of them we tried out doesn't really feel appealing and are a bit cumbersome to implement
Does anyone know of a built-in-mechanism (e.g. TMQINVOKE if such existed) or have anyone had similar needs and how did you solve it ?
If there is no such mechanism as "TMQINVOKE", does it make sense to create an enhancement request for it ?
Consider the interface to an ordinary Tuxedo-Service
void my_service( TPSVCINFO* rqst);
could something like this make sence as interface to a Tuxedo-Message-Driven-Banana
void my_service( TPQCTL* ctrl, TPSVCINFO* rqst);
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