Dean Kuo

Expressing and Reasoning about Service Contracts in Service-Oriented Computing

The Web services and service-oriented architectures (SOA) vision by Helland, P. (2005) is about building large-scale distributed applications by composing coarse-grained autonomous services in a flexible architecture that can adapt to changing business requirements. These services interact by exchanging one-way messages through standardized message processing and transport protocols. This vision is being driven by economic imperatives for integration and automation across administrative and organizational boundaries. This paper presents a concise yet expressive model for service contracts to describe messaging behavior. The idea is simple: we use Boolean conditions to specify when a message can be sent and received, where the conditions refer only to other messages in the service contract - that is, conditions only refer to a services externalized messaging state and not to internal state

Compensation is not enough [fault-handling and compensation mechanism]

An important problem in designing infrastructure to support business-to-business integration (B2Bi) is how to cancel a long-running interaction (either because the user has changed their mind, or in response to an unrecoverable failure). We review the fault-handling and compensation mechanism that is now used in most workflow products and business process modeling standards. We then use an e-procurement case-study to extract a set of requirements for an effective cancellation mechanism, and we show that the standard approach using fault-handling, and compensation transactions is not adequate to meet these requirements.

A service-oriented workflow language for robust interacting applications

In a service-oriented world, a long-running business process can be implemented as a set of stateful services that represent the individual but coordinated steps that make up the overall business activity. These service-based business processes can then be combined to form loosely-coupled distributed applications where the participants interact by calling on each other’s services. A key concern is to ensure that these interacting service-based processes work correctly in all cases, including maintaining consistency of both their stored data and the status of the joint activities. We propose a new model and notation for expressing such business processes which helps the designer avoid many common sources of errors, including inconsistency. Unlike most existing orchestration or workflowa This work was completed while the author was working at CSIRO. languages used for expressing business processes, we do not separate the normal case from exceptional activity, nor do we treat exceptional activity as a form of failure that requires compensation. Our model has been demonstrated by developing prototype systems.

Automated Analysis of Java Message Service Providers

The Java Message Service (JMS) is a specification that provides a consistent Java API for accessing message-oriented middleware services. This paper presents a test harness that automates the testing of JMS implementations (providers) for correctness and performance. Since the JMS specification is expressed in informal language, a formal model for JMS behaviour is developed, based on the I/O automata used in other group communication systems. The test harness has been successfully used to test a number of JMS implementations. This paper contains a descriptive presentation of the formal model, the full details are found in a technical report

Just what could possibly go wrong in B2B integration

One important trend in enterprise-scale IT has been the increasing use of business-business integration (B2Bi) technologies to automate business processes that cross organizational boundaries, such as the interactions between partner companies along a supply chain. It is relatively easy to describe a pattern of interaction, or choreography, in the case where everything proceeds smoothly. However, the abnormal cases, such as where a process fails or a message is lost, are much more complicated, and risk introducing data and process inconsistencies into computer-based systems. Current B2Bi technologies do not supply an infrastructure that can provide reliability without considerable sophistication from the architects and developers. As a first step towards guiding architects to the design of B2Bi systems that maintain consistency despite failures, this paper describes a variety of types of failure that can arise in practice, based on a realistic e-procurement scenario. We describe these failures in terms of the different types of state that naturally occur within the distributed system. Understanding the types of failure that need to be handled, or prevented, is essential to an architect or developer who must design and write handlers for all the exceptions that can occur in their workflows.

Towards a Transactional Framework Derived from Real Workflows

One fundamental issue that has yet to he adequately addressed in loosely coupled distributed systems is long duration transactions — maintaining integrity of the system in the presence of both failures and concurrent activities for processes that last from seconds to years. This issue is of particular importance to both business-to-business integration (B2Bi) and enterprise application integration (EAI) applications such as e-procurement.