Designing and Building the Service Interface

When using message queuing for asynchronous interoperability, there are no direct calls into service interfaces across technological boundaries. Instead, the role of service interfaces is more like “message consumers.” The service interface is an application that monitors and picks up messages from a queue, unpacks the data, and sends it to the existing fa ade or application that processes the message.

Both .NET Framework and J2EE provide built-in support for activation of components from messages (queued components in .NET Framework and message driven beans in J2EE). However, there are differences in the required message structure in each case, so this approach is not feasible when you require interoperability between .NET Framework and J2EE. Instead you write a service interface yourself that consumes messages and passes them on to the appropriate service fa ade.

Building a message consumer is an easy task. Regardless of the technology that you use to write the message, the technique for consuming the message is the same. You need to create a client application or service that polls for messages on the queues and reads any messages found. The data you extract from the message is then either already in the correct format (if it uses the bridging technologies) or requires de-serializing from an XML string back into the correct data class using the techniques described for Web services in Chapters 7 and 8.

Figure 9.1 shows the role of service interfaces in asynchronous communications.

Figure 9.1: The role of service interfaces in asynchronous communications

After the data is back into the correct format, all you need is a method call into the appropriate service fa ade.