INTRODUCTION

Nowadays, all of enterprises are nnder ever­ increasing pressure to deliver their products more quickly and with higher levels of quality and provide their service more effectively and efficiently. Consequently they have to face the increasing rate of change in the socio­ economic envirornnent. Even if they are best poised today to leverage the opportunities of the global marketplace, some envirornnental, regulatory, or market change will occur that will change their reality and thereby, require them to respond to that change. It is generally recognized today that success in a rapidly changing envirornnent is closely tied to how the enterprise proactively manages and evolves its business practices as part of an efficient implementation of its overall strategic plan and how quickly and effectively the enterprise leverages new opportmrities. We have, in fact, entered the age of Business Process Reengineering (BPR).

Today's challenge to BPR is determining how to effectively respond to and manage change, especially customer requirement change that is heart of enterprises viability. In the mid-1980's enterprises began to recognize that being technology-driven- the practice of creating new technologies and then trying to find markets for them­ was an inefficient approach to managing innovation and led to many failed efforts. As a result, momentum shifted to the customer-driven movement, which required enterprises to first nnderstand what the customer wanted before investing in the creation of a new product or service.

Logically, focusing on the customer-driven makes good sense, as it requires enterprises to listen closely to customers-but this practice has two major drawbacks: First, customers do not know what types of information are needed to create better products and services so they voice their requirements in a language that is convenient to them-e.g., solutions, specifications, needs and benefits-but not appropriate for the creation of breakthrough products and services. Second, because many enterprises apply the customer-driven so literally, they use the exact statements customers make as inputs into the innovation process-without recognizing the differences between the types of inputs they are likely obtaining. As a result, they often fail to consider how these different inputs may affect the way they identify opportunities, segment markets, generate and evaluate ideas, position products and services, measure customer satisfaction and perform other strategic development and marketing activities (Anthony, 2003). That is to say, customers cannot actually express generalizations that are powerful, precise and explicit, but they can discern which design they not want.

In the present study, we present an Integration Customer-Driven Scheme of Business Process Reengineering (ICDSBPR) for building a prototype to promote cooperation between enterprises and customers, through which customers can gradually amend what they want and enterprises can have a reliable requirement analysis. First, business process is described by BPEL4WS (Martin et al., 2004; Curbera et al., 2003) as common gronnd for their cooperation in terms of customers' requirement. Furthermore, when customers' requirements vary with an in-depth requirement analysis, business process, if necessary, will make corresponding change, that is business process reengineering based on customers' requirement. Finally we will generate a prototype based on ICDSBPR scheme to transform BPEL4WS to a software system that can provide early immediate experience for customers to refine on the requirement. Consequently enterprises and customers can iterate ICDSBPR scheme nntil satisfying results are obtained.

BPEL4WS

Business Process Execution Language for Web Services (BPEL4WS) is a specification that represents a convergence of the ideas in the XLANG and WSFL specifications and provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. Furthermoreit defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces (Curbera et oZ ., 2003).

BPEL4WS is layered on top of several XML specifications: WSDL 1.1. XML Schema 1.0 and XPathl.O. WSDL messages and XML Schema type definitions provide the data model used by BPEL4WS processes. XPath provides support for data manipulation. All external resources and partners are represented as WSDL services.

ICDSBPR SCHEME

ICDSBPR scheme IS based business process reengineering and composed of two modules. One aims at refining requirement based on BPEL4WS and the other aims at automatic generation of code and construction of database. as shown in Fig. 1. BPEL4WS. WSDL and XSD document are extracted from process model built by toolkit describing customers' requirement, such as WSAD-IE (Osamu et al ., 2003). which provide graphical interfaces in integrated envirornnent for customers to describe business process, thus customers and enterprises accomplishing requirement analysis in manner of what they favor.

Automatic code generation module include:

Fig. I:	ICDSBPR scheme

Having determined requirement, customers can generate prototype and verify their implementation by described earlier module.

RELATION BETWEEN PROCESS MODEL AND DATA MODEL

Generation of data access component and optimization of data access are based on conventional techniques, as well as XML parser can completes parse of relationship model. Relation between process model described by BPEL4WS and data model is illustrated in Fig. 2.

The BPEL4WS process itself is a kind of flow-chart. where each element in the process is called an activity. An activity is either a primitive or a structured activity.

Fig. 2:	Relationship of data between BPEL4WS document and database

Fig. 3:	Invoke operation in BPEL4WS

The set of primitive activities contains: invoke (invoking an operation on some web service), receive (waiting for a message from an external source), reply (replying to an external source), wait (waiting for some time), assign (copying data from one place to another), throw (indicating errors in the execution), terminate (terminating the entire service instance) and empty (doing nothing) operation.

In analysis ofBPEL4WS document, we will find part concerning data access such as invoke operation (Fig. 3), namely data access point, which ought to be consistent with operation on database (Fig. 2).

CASE STUDY

Figure 4 shows a toolbox developed to generate data access component according to ICDSBPR scheme. To verify ICDSBPR scheme, we apply it into practice. A scenario of travel agency (Fig. 5) specializing in travel bookings that require reservations of a flight and hotel is designed to illustrate its advantage (Peter et al., 2004). After customers described requirement in WSAD-IE, corresponding prototype is generated, including data access component.

Fig. 4:	Toolbox for generation of data access component

Fig. 5:	Basic outline ofthe travel agency

Then customers can nm code as if business process has been accomplished. As long as customers encmmter dissatisfactory service, they can adjust requirement and restart ICDSBPR scheme.

CONCLUSIONS AND FUTURE RESEARCH

A good requirement is a good start. In this study we proposed to use ICDSBPR scheme to develop prototype for refining requirement. The scheme fills the gap between requirement-refining and customer­ driven approaches. The result is a methodology for producing a BPEL4WS based application. which completely reflects the customer requirements and minimizes the ammmt of code development required. But business process reengineering is still at early stage of development; many researchers are improving on it (Mayer. 1997). The present study absorb more achievements, making ICDSBPR scheme more perfect.

ACKNOWLEDGEMENTS

Our thanks to the IBM China Research Laboratory (CRL) in Beijing for helping us investigate the challenge. We specially owe thanks to investigation participants for their ideas and efforts, including Guanqun Zhang (IBM).

The present study is supported by IBM University Joint Research Project (Process/Data Orchestrated Solution Design). 2005.