This post originated from an RSS feed registered with Java Buzz by Simon Brown. Original Post: SOA : Synchronous vs asynchronous Feed Title: Simon Brown's weblog Feed URL: http://www.simongbrown.com/blog/feed.xml?flavor=rss20&category=java Feed Description: My thoughts on Java, software development and technology. Latest Java Buzz Posts Latest Java Buzz Posts by Simon Brown Latest Posts From Simon Brown's weblog

In the scenario that I mentioned in "What is SOA?", messaging was used as the transport mechanism to shift data from one node to another. Each node was effectively a listener that accepted a message, processed it and forwarded on the enriched message to another node. By design, this was an asynchronous architecture. This leads me to the question, can services in SOA be synchronous or asynchronous?

To answer the first part of this question, we only need to look at the defacto technical implementation for SOA, web services, which are typically called in a synchronous manner. Looking outside of this technology space, calls to services residing on an enterprise service bus (ESB) such as TIBCO are also typically synchronous, even though the underlying messaging infrastructure might be asynchronous.

So, what about asynchronous services? When trying to imagine services, I try to find an example in the real world and map this back to SOA. Examples of an asynchronous service might be paying a bill at the post office or paying in a cheque to your bank. Although there is a synchronous aspect, typically you don't wait around for these services to complete. Instead, you wait for the acknowledgment of receipt and your payment is forwarded on to another party. This maps well onto how a service might be implemented. The caller makes a request to a service end-point. The end-point receives the request and sends an acknowledgment back to the caller. The service then either processes the request or forwards it on somewhere else. In the latter case, the service is basically operating as a broker for your request.

When trying to define a service, I don't think it matters whether the service is synchronous or asynchronous. After all, this just specifies how clients interact with that service. I also don't see why SOA can't contain a mix of synchronous and asynchronous services, since both are useful when building solutions.