Yossi Dahan [BizTalk]


Thursday, April 27, 2006

Wrong way to implement polling?

Consider the following scenario:

Application A on a legacy platform needs to deliver message to application B

Legacy platform can only be polled for messages, it cannot send messages.

Legacy platform includes logic to accept requests for outgoing messages from internal applications and queue them (Outbox functionality)

It also includes logic to accept polling calls from outside the platform for the "next" message and return it to the caller.

However, an implementation I recently saw did not queue the actual outgoing message

Instead it queued the request to generate the outgoing message, in the form of a call back.

So - when Application A arrives to a point it needs to send the messages it registers the fact that it needs to deliver a message. What is actually kept is method callback information.

When BizTalk is polling for messages the callback is invoked to generate the message, which is then being returned to the BizTalk polling call.

To me this bring a few issues to the table -

  • It creates a dependency between BizTalk and the application so the application (and everything that is needed to generate the message) must be available when BizTalk polls for the message.
  • Application A intended to deliver the message at a certain point in time. BizTalk polled for it at a later point in time. if the message gets created when BizTalk polls for it (as opposed to when the application sent it) - the underlying data may have changed and the message created differently.
  • In addition, if the process of creating the message fails, it is much harder to resolve, if the message was created as part of a user interaction, for instance, the user has probably moved on.


Post a Comment

<< Home