EI has numerous patterns and we will be looking most importantly the webservice based models in this post.
There are two principal architectures for Web service interfaces
A> Synchronous Web services
B> Asynchronous Web services
These two architectures are distinguished by their way of request/response handling pattern. With synchronous services, clients invoke a request on a service and then suspend activity to wait for a response. With asynchronous services, clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request and returns a response when available later. Upon availability of the response, the client retrieves the response for further processing.
However a Web service may combine synchronous and asynchronous architecture depending upon the types of work, the service performs and the available technologies.
A> Synchronous Web Services
Synchronous services are characterized by the client invoking a service and then waiting for a response to the request. Since the client suspends its own processing after making request, this approach is best when the service can process the request in a small amount of time. Synchronous services are also best when applications require a more immediate response to a request. Web services that rely on synchronous communication are usually RPC-oriented. Generally, consider using an RPC-oriented approach for synchronous Web services.
A credit card service, used in an e-commerce application, is a good example of a synchronous service. Typically, a client (the e-commerce application) invokes the credit card service with the credit card details and then waits for the approval or denial of the credit card transaction. The client cannot continue its processing until the transaction completes, and obtaining credit approval is a prerequisite to completing the transaction.
A stock quote Web service is another example of a synchronous service. A client invokes the quote service with a particular stock symbol and waits for the stock price response.
Pic: Synchronous webservice with JAX-RPC
A synchronous architecture like this also has the facility to expose a Web service interface to an existing J2EE application that may already have a browser/wireless/rich client interface.
B> Asynchronous Web Services
With asynchronous services, the client generates the request but doesn't wait for the response. Often, with these services, the client does not want to wait for the response because it may take a significant amount of time for the service to process the request and the nenxt operation is not directly dependent on the response (unlike the credit card response for the e-commerce application during check out).
Generally, an asynchronous class of services is used for document-oriented approaches.
A travel desk service is a good example of a document-oriented service that might get benefitted by using asynchronous communication, where the client sends a document to the travel service (may be for requesting arrangements for a particular trip or reimbursement for a trip). Based on the document's content and/or the workflow defined within the business logic of the service, it starts processing. Since the travel service might perform time-consuming steps in its normal workflow, the client cannot afford to pause and wait for these steps to complete.
So far so good. The synchronous calls are easy enough, since we do not need to think about a way out of delayed response tracking. Now in case of Asynchronous calls the service may make the result to the client's request, available in one of two ways:
1> the client that invoked the service periodically checks the status of the request using the ID that was provided at the time the request was submitted. (This is also known as polling.)
2> If the client itself is a Web service peer, the service calls back the client's service with the result.
While designing the architecture of asynchronous webservice based integration, we can think of multiple design patterns. 
The above architecture shows one of the recommended approaches to achieve asynchronous communication. In this architecture, the client sends a request to the JAX-RPC servlet endpoint on the web container. The servlet endpoint delegates the client's request to the appropriate business logic of the service. It does so by sending the request as a JMS message to a designated queue or topic. The JMS layer (along with the message-driven beans) makes asynchronous communication possible.
The above architecture shows the scenario in case the client itself is a Web service peer. The client application (which could be a direct client or another web container) generates a request and sends it via JMS to the Processing Center (Service A). "Service A" has a Web service invoker that sends the request to the destination application's Web service endpoint (Service B). The endpoint receives the request and acknowledges the receipt by sending an ID back to the service invoker. Later, when the supplier application fulfills the request, its Web service invoker sends the result to "service A" endpoint.
As I mentioned earlier, there could be numerous approaches to achieve this pattern and the above mentioned are only two of them. In case you are interested to add anything, please feel free to write note on the post.
