Santanu,
I've looked into your Webinar. Here are my notes (that I hope helpful to you and others).
1. The Best Practice of interaction and integration underneath is asynchronous. In synchronous mode, reliability of the interaction is always under a serious risk if communication crosses boundaries of the components, which is always the case for Web-apps.
2. A fundamental assumption is that interacting entities initially have to know about each other. If they do not and if you cannot modify them to recognise each other (i.e. become requester-replier) an intermediary cannot integrate them but can only interact with each of them separately.
3. It is a well-known pattern and practice when a requester specifies what to be returned and where, i.e. URI, end-point, protocol, etc. It is feasible.Â
4. Positioning a Facade (intermediary) between requester and replier, which work in synchronous mode, does not help to make communication between them asynchronous: simply, this makes a requester's waiting time longer.
5. The power of asynchronous mode is not in the API (interface) but in the behaviour of the requester and replier (no API has a behaviour). This component behaviour assumes that the requester does not wait for the response in the same process/thread as was used for the request; also, the replier knows that it is not constrained by time/performances in responding to the request.
So, the value I see in your Webinar is in the code that includes indicators of synchronous/asynchronous communication. However, the pros/cons of synchronous/asynchronous mode are not clear presented (at least, IMO).
Thanks,
- Michael
________________________________
Sent: Saturday, January 19, 2013 8:18 AM
Subject: [service-orientated-architecture] API Facade Pattern Webinar
Â
Friends,
Your comments and reviews welcome on my recent webinar effort on REST APIs. This is the last one on the series.
API Facade Pattern: Synchronous to Asynchronous
Regards
Santanu