One of the lead engineers at Alpha Parts proposes solving
these challenges by using the Service Gateway pattern in the middle tier and an
ASP.NET compatible Ajax component on the front end. Let us take a look at the
Service Gateway.
The Service Gateway pattern is a repeatable design that
"encapsulates the details of connecting to the source and performing any
necessary translation." Here is a logical overview of the pattern.
Figure 1
The web application sends its request to the Gateway. The
Gateway is then responsible for translating the request into the proper format
to send to the External Service. After the response comes back from the
external service it is returned to the gateway where it is then translated back
into a representation that the application understands. It is also at this
point where the gateway can use the persistence layer for storage or retrieval
of data.
The next figure is a UML breakdown of the gateway layer.
Figure 2
Class Breakdown
Gateway – responsible for providing coordination and
translation for calling the external service
PartnerInventory – object that describes products
availability at a particular vendor
PartnerInventoryCollection – object representing a
collection of PartnerInventory objects
RealTimeInventoryAccess – this is an existing class that
handles the actual post to the services
GatewayPersistence – responsible for persisting and
retrieving data from cache or the database - this could also be used to
perform an algorithm to decide what stock results are active enough to stay in
memory cache and which should persist to the database
GatewayDataAccess – responsible for physically persisting
and retrieving data to the database
The pattern is straightforward enough and only really gets
complicated depending on the extent of logic that is desired in the persistence
layer.
Each time a method is invoked from the Gateway to RealTimeInventoryAccess
(and hence, the external service itself) it will be done with an asynchronous
method. The following figure shows the idea behind this, not the exact code.
Listing 1
ThirdPartyInventoryDelegate third =
new ThirdPartyInventoryDelegate(RealTimeInventoryAccess.GetInventoryByVendorsAndItemsCode);
IAsynchResult synchResult =
third.Invoke(parameter, new AsychCallback(method), third);
synchResult.AsynchWaitHandle.WaitOne(time, true);
The Alpha Parts engineers want to ensure that the web
application continues processing while the web services are being called; so
they propose calling each web service asynchronously in order to return
information to the Gateway object as the services returns. This way they can
be run through the persistence layer sooner. Each asynchronous method call is
also done with a timeout value in order to prevent the HTTP post from waiting
on the default timeout which could be too long (notice the WaitOne in the above
listing). This will also enforce our own time limits for those remote method
calls.
Being as such, if a method was called at 8:00:01 AM and
method two was invoked right after that, if the first service call took longer
to return, the second call could already be done processing the service XML and
have handed the data back to the Gateway for the persistence layer. It
basically allows the multiple calls to return on their own time and not queue
up behind each other so that there are not wasted cycles.
The Ajax capable front end is another key facet to this design
coming to life.
Alpha Parts can use an Ajax component, like ComponentArt’s
CallBack. This control allows you to dynamically refresh an HTML region
with JavaScript, but control it all from the ASP.NET server side code. This is
a great benefit because it means they would not have to write their own
JavaScript. A third party control also ensures that it has been tested,
debugged and run on multiple platforms and browsers.
When a product page loads on the Alpha Parts website, the
full page will load except for the real time html region. The CallBack
component will call the page class which will check with the Gateway and its
persistence engine to see if there is current inventory information available.
If it is available, those objects are returned to the page and bound to the
CallBack control. If they are not available from persistence, they are sent
out to the external service(s) and the CallBack control will display a "loading"
icon. The user is then free to use the rest of the page and as soon as the
Service Gateway is done with its work its return objects will be bound to the
CallBack control.