Communicating Availability
Transaction or session-specific errors often indicate that something is wrong, but a hung
socket connection or a cascading error may never return a satisfactory message to allow
an exploiting application to respond appropriately. In order to provide a higher level of
resiliency, real-time status is required. UDDI servers can identify several end points, which
may allow a Web service client the opportunity to use a different system to accomplish the
same task. The problem is that any one of those services may be having problems. To help
address this situation, system availability is included as part of the interaction between the
service consumer, service discovery, and service provider.
This model (Figure 10) provides a level of service availability above and beyond the typical
transaction-based error. Service clients can be advised of issues through simple calls
to an independent third party, which allows appropriate logic to take place to maintain a
higher level of service. This technique is similar to network dispatcher models, where a
single service provides a feedback loop to ensure that servers in a cluster are available before
being dispatched. For example, an asynchronous process may test the availability of
an externally-dependant service through the central availability system.
Pages:
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328