RE: [ebxmlms-develop] Should Hermes makes dispatching decision?

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Given that, it's a small leap to supporting different listeners for the
> CpaId/service/action combination (rather than just the CpaId). However, I
> still think that the current implementation is too complicated.

> Have you identified other parts of the specification that the MSH must know?

        How to do MessageOrder delivery if no "conversationId" is included
in ApplicationContext?

> Fair enough. Do they really have different listeners at the conversationId
> level? The CpaId/service/action combination seems sufficient.

        Two departments of the same company write two different applications
to receive messages. Thus, these two departments would register two
MessageListener's with the same cpaId but different service and action.
Somehow, the business process is written and governed in such a way that
3 messages are now being sent: (cpaid, 1, s1, a1), (cpaid, 2, s2, a2),
(cpaid, 3, s1, a1). The application with s1 and a1 must wait for
conversationId 2 message to be delivered to application with s2 and a2
before receiving conversationId 3.

        I have been developing some internal stuff on business process
during these months. I simply switch myself to be the user of MSH, the
"son" I ever composed. I don't assume any implementation details in MSH.
When a business process is executed, it is acting on behalf of an
application of a particular cpaId, service and action from CPA with no
choice. The process engine also generates conversationId which is used
to differentiate a particular business process execution instance. I don't
know why MSH Request asks me to supply cpaId, conversationId, service,
action and MessageListenerImpl. Anyway, I have enough information to do so.
From my observation, I just know a particular business process execution
instance can receive exactly what it is supposed to receive from MSH. I also
observe that after receiving the message, that execution instance would
automatically unregister itself to MSH.

        In case the process engine deploys a global MessageListener, all
messages, once they are received, may be buffered, say, on the file system.
Then, the process engine has still to dispatch the messages one by one to
identify which message should be delivered to which process instance at
appropriate time (if MessageOrder semantics). Since I know nothing about
MSH, I would prefer the dispatching duty to be shifted to MSH instead of
my application, if there is choice.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------