uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslaw Cwiklik <uim...@gmail.com>
Subject Re: UIMA AS - CAS consumer patterns
Date Tue, 12 Oct 2010 13:15:46 GMT
Uima AS service always replies to a client that sent the request. A request
messages contains a temp reply queue where the service must return a reply.
 From the client perspective it is always Request-Reply pattern.  The
framework provides no support for overriding this behavior.

If you need to forward a reply to a different queue, you need to add custom
jms code to the application client and call it whenever you receive a reply
from a service.

Jerry C

On Tue, Oct 12, 2010 at 2:44 AM, Diman Karagiozov <diman@tetracom.com>wrote:

> Hi there,
>
> I am working on a project that utilizes UIMA Async Scale-out capabilities.
>
> There are two client applications that send messages in an "input.queue"
> and several UIMA aggregate engines that fetch messages from this input
> queue. What I want to achieve is to send the annotated serialized CAS to an
> "output.queue" depending on the client application that sent the initial
> message. In other words - if the message comes from "client A", after
> processing send it to "output.queue.A"; if it comes from "client B", send it
> "output.queue.B".
>
> This is how I am sending the message to an UIMA worker:
>
>            final UimaAsynchronousEngine client = ...;
>
>            final CAS cas = client.getCAS();
>            cas.reset();
>
>            cas.setDocumentLanguage( lang );
>            cas.setDocumentText( StringUtils.stripNonValidXMLCharacters(
> text ) );
>
>            final String id = client.sendCAS( cas );
>
> Somehow, I have to set the client ID but I do not want to add it in the CAS
> as annotation. Is there another way to add such information that is later
> available in the process methods of the primitive engines? If this is
> possible I can create a new primitive engine (Finalizer) that reads the
> client ID and implements the messaging router functionality.
>
> Are there other pasterns that are more suitable for implementing the
> above-described scenario?
>
> thanks
> Diman
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message