Article Preview
Top1. Introduction
In an enterprise, business routines and processes form a foundation for its businesses. Business development within the enterprise relies heavily on its innovation, i.e. newer, or further re-designed, and more effective routines and processes. In other words, business is a set of routine-based operations and innovation is a move from the set of original routines to a set of innovative routines. Business patterns encapsulate the best practice solutions for business tasks. They are the best practices within an enterprise or across enterprises. Business patterns help an enterprise to run their business smoothly and effectively and quicken restructuring process to meet new business demands.
Business patterns under Service Oriented Architecture (SOA) (Bieberstein & Bose, 2005) are enterprise-focused best practice with SOA based solutions. These patterns include the solutions for business under the SOA infrastructure and the technologies for these solutions that have been accumulated over the years. These patterns help an enterprise to understand and analyse complex business problems, break them down into smaller functions, and modularize them into services for future (re)use. The SOA provides the architecture for agile service construction. In other words, it is how an enterprise can quickly reconstruct their business to meet the new demands. If an enterprise can encapsulate their SOA solutions into patterns, it can make business more agile and business solutions more flexible.
However, under the SOA infrastructure, it is difficult to connect and match an instance service (i.e. a concrete, executable web service) into a suitable business pattern without a large amount of manual work. One reason is that the description of a business pattern and its requirements is entirely different from the description of an instance service: the former is at a high level and business oriented whereas the latter at low level and technical oriented (Song, 2006). Therefore, system developers or business process designers are required to work as an in-between to translate the descriptions from one level to another in order to locate suitable concrete services to meet business demands. Obviously, we need to bridge this gap between the two types of descriptions. Currently, once a new business pattern is developed and adopted, a manual process is carried out to decompose the pattern into some sub-components, create a set of relevant business processes, and connect (embed) relevant instance services into the business processes. This process greatly reduces the efficiency of business processes reforming. An ideal situation is, when a new business pattern is adopted, a set of related instance services will be automatically or semi-automatically located and embedded into the pattern with its related business processes. However, how to realize this process is a challenge. In the following, we discuss the problems that we need to address in order to bridge the gap.
- •
Service Description Does Not Take into Account Business Context: The existing Web services description standards, such as WSDL, are technical focused standards. They describe the technical details and specifications of Web services’ interfaces so that programmers can use them to develop services for applications. However, the technical based description is not sufficient and rich in semantics for them to directly match with the business requirements specified in a business pattern (where a business process is a part) without service developers’ interferences. Because of this gap between technical descriptions and abstract business requirements, human’s interpretation is required for a service to be linked and embedded into a business pattern.
- •
Inter-Service Relationships are Not Sufficiently Addressed: More often than not, a service needs to work together with other services to provide a richer functionality for a more complex task, and hence services need to interact with one another as a whole to supply a better business solution. Moreover, understanding interaction (operational relationships) of a service with other services is a better way to understand and interpret this service at both conceptual and technical levels. This kind of interactions between services is termed as inter-service relationships. Currently, none of the existing web services description standards, such as WSDL, addresses this aspect of business semantics/usage for Web services. If inter-service relationships are maintained in the service description, it will be much more efficient and effective to correlate services in a business pattern or process.