Implementing exceptions in an SOA

Ideally, the service invocation always completes successfully and returns the desired result. Unfortunately, in reality, services can and will fail. This failure can be caused by a whole host of problems. It can be caused by the service itself, such as an argument validation failure, or just a bug in a service implementation, or a communication problem, such as a service unreachable or an implementation that does not have access to the underlying database. Finally, failure can be caused by deployment problems, such as after a software upgrade, a required library is not properly deployed.

A widely used failure-handling mechanism is exception handling, including capturing and logging errors, and selecting an alternate execution path when a failure occurs. In application and component implementations, it has become a standard mechanism. The problem is that it relies particularly on the ability of application designers and developers to anticipate possible anomalies and to use code 1 to handle them correctly at runtime. This approach is based on the following assumptions:

The application is completely designed as a whole, including all possible anomalies. This means that all of the execution paths for the application are defined, and as a result, it can be completely tested by the application team.

The application runs on a single machine (or a limited number of machines) and reports all exceptions in a local file log file using a standardized exception reporting pattern.

Changes that occur in the application component are centrally managed, which means that the application development team can have complete control over the changes.

In the case of a distributed system, trying to implement this exception-handling method is obviously complicated, because in this case, the exception can be caused not only by the application code itself, but also by the infrastructure (such as the network), which makes it more difficult to parse all possible exception scenarios. In addition, in this case, the exception logs are propagated across multiple physical machines, making it significantly more complex to coordinate them. Features in the context of service-oriented architecture (SOA), such as loose coupling (organizational and technical), autonomy, and reliance on existing applications to implement business functions make exception handling more complex.

Since each service is designed, implemented and maintained by itself, and can be used in multiple enterprise solutions (which may be unknown at the time of service design), the exception handling implementations for specific services revolve around 3 points: Handling exceptions, logging exceptions to local services, and reporting them to the service consumer when they cannot be resolved locally. If no particular metric is taken, this will result in an "outlier handling Island" (see Figure 1) 2.

Fig. 1 Island of exception handling

The following complex issues are not a big problem in monolithic applications and must be handled in order to support exception handling under SOA [2].

The distributed and heterogeneous nature of SOA makes it particularly easy to fail, causing exceptions at multiple levels [3]. System-level exceptions are caused by messaging, communications, and other infrastructure failures. Application-level exceptions are caused by incorrect message semantics or logical errors in the application. Business-level exceptions caused by violations of best practices, compliance laws, regulations, or business policies required by the business manager. The latter may not even be visible to service execution itself and may require service management solutions to properly detect them.

One exception is that exception handling in any participant is not detectable, that is, an exception that is associated with a particular business transaction that spans one or more services (sometimes across multiple companies) across different business processes. In this scenario, exception handling may require aggregation of exception information at the business transaction level. This means that the exception information for a particular service must be severed by the business transaction that uses the service. In addition, the need for such partitions is also reinforced by the privacy, Health Insurance Portability and Accountability Act (Health Insurance Portability and accountability ACT,HIPAA) and other compliance requirements.

A single service lacks the perspective of the entire solution (business process). Lack of a process-wide perspective will make error correction difficult. Therefore, once an exception is detected by the service implementation, it is not always possible to choose an optional execution path, but also to notify the consumer because it may have the necessary context to correct the situation. However, the nature of the SOA recursive portfolio complicates the situation further: consumers are often another service and therefore not the right place to solve the problem [4]. Not all exceptions can be handled automatically, and sometimes the only way to handle failure is through human intervention. To do this, you need to decide who is the right person and inform them about the anomalies.

Loosely coupled, heterogeneous services are often found and handled differently for exceptions. Some may use special components, such as log4j, Log4ne, and. NET Enterprise Library, etc., others use proprietary solutions. In addition, as defined in [1], the ability to wrap existing applications is a common practice for current services implementations. These traditional applications can detect, record, and notify exceptions in different ways.

Applying SOA principles to exception handling implementations is an elegant exception handling solution in SOA. This will cause all major exception management elements to be "serviced" [4], (i.e., log, exception resolution, and notification). Figure 2 shows the overall architecture of the Exception log, resolution, and notification.

Figure 2 Unified architecture for exception logging, resolution, and notification