This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
We've covered quite a bit of ground in this chapter. We started by looking at XML attributes in the EAIRequest message to signify whether the client wants the transaction processed synchronously or asynchronously. The other attribute signified whether you should abort processing when you hit the first error while processing a Request type.
Next, we examined the code for the Controller class. The Controller takes a request from the web service and creates an EAIRequest object from the incoming XML message. This object is then passed around the system to various subcomponents.
The Controller checks what type of processing has been requested. If the client specifically requests Asynch="TRUE", you send the entire request on to a Message Queue in the MSMQ service. All of the classes needed to interact with the MSMQ are housed in the System.Messaging namespace. A response message is sent back to the caller with the TransactionID that was created for this request. Because processing takes place asynchronously, the caller must send a message later to get the status of the processing for this transaction.
The RequestQueMonitor project, a Windows application, uses the classes in the System.Messaging namespace to watch the appropriate message queue for the integration messages. When it finds one, it sends the message to an instance of the RequestsProcessor class. Status information is printed to a text box on the screen to let you know what's going on.
If the request is synchronous, the client expects processing to happen now. The HTTP connection is held open to the web service while you work on the back end. When you send back the response, it is sent back to the calling client.
Next we described RequestsProcessor, the class that takes the input request and actually pieces out the work to various appropriate handler classes. In the case of synchronous requests, it is called from Controller. In the case of asynchronous requests, it is called by Message Queue monitoring code. One of the main reasons for approaching the architecture this way is so that you have a single spot where code can be changed if you want to modify the behavior of the system. When a change is made, both synchronous and asynchronous paths call the RequestsProcessor class.
What's Coming Up
In the next chapter, we cover the RequestHandler set of classes. You saw an instance of these classes created in the RequestsProcessor class. A subclass of the RequestHandlerBase will be invoked to process each Request block sent into the system. As shown earlier in this chapter, classes in the System.Reflection namespace are used to create an instance of the needed subclass on the fly. This is powerful (and cool) code that lets you quickly add functionality to your system without having to change any of the code on the calling, engine side.
For more information on .NET, visit our .NET Reference Guide or sign up for our .NET Newsletter.