ADoc-Oriented Programming - CiteSeerX

ADoc-Oriented Programming Prabir Nandi, Santhosh Kumaran Terry Heath

IBM T. J. Watson Research Center Route 134 Yorktown Heights, NY

Kumar Bhaskaran, Raja Das IBM Software Group Route 100 Somers, NY

ABSTRACT In this paper, we present a new programming model targeted to collaborative business process integration applications. This model is based on the object-oriented technology, but elevates the programming model to cover a new breed of business applications that are currently evolving. These applications are differentiated by their strong emphasis on “collaborations” in which a set of “collaborators” works together to attain business objectives, and on integration where new functionality is derived by integrating legacy systems with new components and applications. We propose two new modeling artifacts, ADoc (Adaptive Document) and Collaboration, to model this class of applications. We propose an XML-based language to assemble ADoc-based collaborative applications. We present the design of a runtime environment for ADocs and discuss the current implementation of this runtime. We present an in depth analysis of this programming model. We discuss our experience in using this model in real world applications.

1. INTRODUCTION As application areas for computer systems evolve, so do programming paradigms. Constraint-based models, logic programming, and symbolic computing are primarily targeted to applications in AI. Matrix-based languages (Fortran 90 and HPF) are popular in high performance scientific computing. Object-oriented programming has transformed the way business applications are developed. Agent-based systems are widely used to model emergent phenomena. Enterprise computing is undergoing radical changes. A new breed of enterprise applications is emerging where the emphasis is on collaborative business processes. We propose a new programming paradigm targeted to this class of applications. At the core of this paradigm is the concept of an Adaptive Document (ADoc). The purpose of this paper is to describe what ADocs are, how they can be used to model collaborative business processes, why this modeling technique is superior to existing technologies, and how ADoc-based systems can be realized. The outline of the paper is as follows. We begin with the description of the target application space in section 2. This includes a discussion on the current directions in enterprise computing and the role of collaborative business processes in enterprise applications. Section 3 introduces the ADoc-oriented Programming (ADOP) model. Next we describe a sample application to illustrate the use of ADOP in building real e-business systems. Section 5 discusses the IT level metamodel of an ADoc based application and the buildtime aspects. We then discuss the analysis of the ADOP model in section 6 and clearly establish how our work relates to existing work in this area in section 7. We conclude with our experience in applying this model to real world applications.

1

2. TARGET APPLICATION SPACE System integration is emerging as a key IT challenge. Recent surveys show approximately 40% of IT dollars, over $900 Billion, are spent on integration [1],[2],[3],[4],[5],[6]. Integration is a multi-faceted problem, spanning the complete IT spectrum. At the lower ends of the spectrum are device integration, OS integration, and middleware integration. At the higher levels, we have directory integration, data integration, information integration, and application integration. At the highest level is business process integration (BPI), since BPI typically entails all the other facets of the integration problem. The emphasis is on solution assembly rather than solution development, as system integrators attempt to harvest new functionality by integrating legacy systems, ISV applications, and new components in the backdrop of the Internet. Business processes are typically collaborative in nature. They bring together “role players” in organizations to form a collaborative community to accomplish shared goals. Thus the enterprise computing landscape is evolving towards software systems that support integration and collaboration. There is a need for programming paradigms, languages, tools, and technologies to adapt to this change. Of particular interest is adapting the OO paradigm to address these new requirements in enterprise computing. ADoc-Oriented Programming (ADOP) is conceived as a new programming model based on OO principles for assembling solutions with emphasis on collaboration and integration. Specifically, it is well suited for creating collaborative business process management and integration applications. Commerce, Product Lifecycle Management, Life Sciences, Engineering, Manufacturing, Financial Services, Health Care, and Supply Chain Management are examples of specific application areas.

3. ADOC PROGRAMMING MODEL The programming model is built on a concept called Adaptive Documents (ADocs). An ADoc models a “domain artifact” that displays state-dependent behavior. The domain artifacts are essentially the concepts by which the problems and their solutions in the domain are described. Using e-Commerce as a domain, the domain artifacts could potentially include Purchase Orders, Request-For-Quotes, Advanced Shipping Notice. There are three key aspects to an ADoc: (1) Dynamic data context. (2) State-dependent behavior manifested in the way an ADoc responds to external events. (3) Support for collaboration. The dynamic data context of an ADoc is the data associated with the domain artifact it is modeling. For example, consider the Request For Quote (RFQ) business process in the e-Commerce area. This process typically starts with a Buyer issuing an RFQ. Several Suppliers may respond to the RFQ by creating Quotes against the RFQ. After all the Quotes are received, the Buyer and prospective Sellers engage in a negotiation process. After several negotiation steps, the Buyer reaches an agreement with one of the Suppliers. The dynamic data content of an RFQ ADoc might consist of the original request, the modification history, the original quotes received from suppliers, the evaluation history, and several such fragments of business data. Though this data context is distributed and dynamic, the ADoc provides a mechanism to aggregate this based on the context. The second aspect of an ADoc is its adaptive behavior. The behavior of the ADoc is characterized by the way it responds to external events. Specifically, an ADoc responds to a predefined set of events by effecting the environment that it is in. It can

2

effect the environment in three ways: (1) By sending messages to systems or humans or software agents in the environment (2) By invoking methods on applications in the environment (3) By scheduling new events. This behavior is adaptive since the set of events that an ADoc handles and its response to these events changes based on the context. Collaboration is about bringing “agents” together to accomplish some task. An agent in this context is an entity that possesses some degree of autonomy. This includes human users and software agents. The collaborative aspect of an ADoc deals with its ability to facilitate collaboration among a set of agents to execute a task in the context of that ADoc. This is accomplished by making Collaborations first class objects and associating them with the ADoc. An instance of an ADoc may be associated with zero or more Collaborations and an instance of a Collaboration may be associated with one or more ADocs. There are three aspects to a Collaboration: (1) The participating agents (2) The “activities” through which these agents collaborate (3) The mechanism by which the activities are generated. An activity is a “unit of collaboration”. It represents a step in the collaborative process. We can create various kinds of collaborations by changing the activity generation mechanism. For example, a workflow collaboration can be created by using an “activity map” for generating the activities. An activity map is a directed graph where the nodes are the activities and the arcs denote the dependencies between the activities.

3.1 Programming Model In ADoc-oriented programming, the system design revolves around the identification and definition of the ADocs. The key information artifacts in the target solution domain are modeled as ADocs. These ADocs run in an environment consisting of a set of data stores, applications, human users, and Web services to build a dynamic and adaptive system. We make such an environment collaborative by defining Collaborations and associating these with ADocs. Figure 1 shows the high-level view of a system based on this model. The Environment (People, Web services, Applications, Etc.)

ADocs

Collaborations Collaborations Collaborations Collaborations

Figure 1: ADoc Programming Model

The views of the system projected to the clients could be based on ADocs or based on collaborative Activities. Thus the clients can interact with the system by sending an “event” to the appropriate ADoc or the Activity. An ADoc responds to the event by executing a set of actions based on the event data and the state of the ADoc. These actions could also impact the Collaborations associated with the ADoc. For example, new Collaborations may be created and associated with the ADoc via

3

these actions. The events sent to the Collaboration can result in the creation of new Activities, claim of an Activity, or completion of an Activity. The ADocs provide the “data context” for the agents to complete an Activity. Once an Activity is claimed, the agent can perform operations on the associated ADocs by using the Activity as the “process context”. These operations are processed by the ADoc exactly as the ADoc event processing discussed above, except that the behavior of the ADoc dynamically adapts based on the process context. This dynamic behavior adaptation is discussed in detail in later sections.

3.2 Structure of an ADoc An ADoc is made up of three subcomponents: (1) Views (2) Behavior (3) Dynamic Content Definition. These subcomponents, their functional descriptions, and designs are discussed below.

3.2.1 Views The views are used to enable user interaction with the ADocs. An ADoc can have multiple views, and the view selected for a particular interaction depends on who is looking at it and in what context. For example, the view of an RFQ rendered for a Buyer while evaluating the quotes is different from the view rendered for a Supplier while creating a Quote against it. A view has three components: (1) The read-only data being rendered on the screen (2) The actions that can be triggered by the user (3) The data being collected from the user and processed by the ADoc in response to the user action. There is a oneto-many relationship between an input data item and the actions.

3.2.2 Controller The behavior of an ADoc is described using a finite state machine and implemented by the Controller subcomponent. The behavior describes the set of events the ADoc can process while in a specific state, the transitions permissible from a state, the conditions associated with each transition, and the actions invoked as part of these transitions. The action invocation mechanism utilizes the command design pattern [18]. This means there is a clear separation between what an action should do and how that is done. A command captures the definition of what an action should do. A Receiver is the entity that actually does the job. A Command is bound to a Receiver so that an action can be executed.

3.2.3 Context. An ADoc stores two kinds of information that helps it to aggregate content dynamically. The first is the reference data. This includes unique identifiers of data fragments distributed in different systems that the ADoc integrates. The second is access information through which an ADoc can connect to the systems that store the data and aggregate the content. This kind of information includes specifications of transport, protocol, and API.

3.3 Structure of a Collaboration A Collaboration object has three subcomponents: (1) The Agents that are collaborating (2) The Activities or steps in the collaborative process (3) A mechanism to choreograph these activities. There is a one-to-many relationship between an activity and the agents. These subcomponents and their functional descriptions and designs are discussed below.

4

The Agents in a Collaboration could be human users of the system or software agents. These Agents need to have the capability to perform the activities assigned to them. A Collaboration will have at least one Agent, and typically more. Agents may be added or removed from a Collaboration dynamically at runtime. For each Agent associated with the Collaboration, the Collaboration stores a unique Agent-ID. An ADOP implementation needs to define a mapping from the Agent-ID to the organization model stored in enterprise systems. The set of Activities associated with a Collaboration at a point in time are the steps in the collaboration that are “active” at that point in time. This is a dynamic set with new Activities being added and completed Activities being removed. Each Activity has one or more agents associated with it. Before an Activity can be worked on, one of the associated agents needs to “claim” it. Once the agents have finished the work, the Activity is completed. Activity Choreography is the third subcomponent of a Collaboration. A Collaboration does not hold an explicit list of all the activities or steps it needs to execute, it merely contains the current active set. Adding new activities is done via an optional activity choreography module. If present, this module may supply a new set of activities each time a current activity is completed. If this module is not present in a Collaboration, new activities are created manually using the Collaboration APIs. The structure of the Collaboration presented above is versatile enough to support various models of collaboration. For example, consider workflow collaboration. It is a well-understood model of collaboration and has been extensively used in business process management [24]. By using a directed graph to define the control flow to drive the activity choreography, and the dynamic content of the ADoc for the data context, we create Collaborations that implement the workflow model. The directed graph that defines the control flow has Activities as the nodes and dependencies among the activities as arcs. Real Time Collaboration (RTC) is another model of collaboration, much different from the workflow model. In RTC, an online community of users collaborates in real time to achieve common business goals. An example will be an online decision making session where several experts look at a patient’s record to make a decision on a course of treatment. In ADoc-Oriented Programming, the Patient Record is modeled as an ADoc. The Primary Care Physician (PCP) of the patient may initiate the collaboration by creating an instance of a Collaboration and associating it with this ADoc. The PCP will typically do this via one of the ADoc views. The Collaboration instance in this scenario will have just one activity, all the participating experts listed as agents, and no activity choreography. Once the collaborative activity is bound to the ADoc, the system triggers an online collaboration via Instant Messaging as soon as the collaborators are online. The views of the ADoc, containing the relevant data from the patient records, are rendered along with the Instant Messaging window to facilitate RTC. Once a decision is made, PCP signals the completion of the activity leading to the termination of the Collaboration.

3.4 Compositions As mentioned briefly in the section on programming model, compositions are key to realizing the power of ADoc-Oriented Programming. We discuss three kinds of compositions: (1) Composition of multiple ADocs (2) Composition of an ADoc with multiple Activities (3) Composition of an Activity with multiple ADocs. Below we discuss these compositions in detail.

5

Though the compositions add to the power of the programming model, ADocs may be used in standalone mode for modeling and implementing a large set of real world applications. In fact, in several of our customer engagements, we have built ADocbased systems without compositions.

3.4.1 Multiple ADocs ADOP model supports hierarchical composition of ADocs. Such a composition is defined using a rooted-tree structure of arbitrary depth, with an ADoc associated at each node in the tree. It is important to understand that this is not the same as a “Composite ADoc”, but merely provide a dynamic association among several ADoc instances. In fact, ADOP model does not support Composite ADocs. ADoc composition model enables imposition of hierarchical relationships dynamically at runtime on a set of ADocs. Such a relationship can then be used for automatic event propagation. For example, consider the RFQ business process discussed earlier. We may model this process using two ADocs: RFQ and Quote. There is a natural association between an RFQ instance and the Quote instances that are being created against this RFQ. ADoc composition captures this association using a rooted tree with the RFQ instance as the root and the Quotes as the leaves in the tree. A “Time-Out” event on a Quote ADoc instance can now be propagated to the right RFQ ADoc instance. Similarly, a “Change” event on RFQ ADoc instance can be propagated to all the associated Quote ADoc instances. The event propagation rules for ADoc compositions are as follows: An external event received at a node in the tree is propagated to all the child nodes and to the parent node, if any. An event received from the parent node is passed down to the children. An event received from a child is propagated to the parent.

3.4.2 ADoc with multiple Activities. As discussed in the section on programming model, ADocs facilitate collaborative processes by associating with instances of Collaboration. Multiple Collaborations may be associated with an ADoc concurrently. The active Activity instances from the associated Collaborations bind with the ADoc instance dynamically, forming compositions of an ADoc with multiple Activities. This composition models the scenario where concurrent activities work on the shared content. We illustrate the use of this composition using a variant of the RFQ example. Assume we have modelled the RFQ process using RFQ ADoc alone, unlike in previous examples where we modelled RFQ and Quote as ADocs. (This alternative makes sense if the business requirement dictates that there is no break in the environment where data objects related to RFQ and Quote are stored.) In this scenario, a separate Collaboration is created corresponding to each Quote Creation activity. These Collaborations are then associated with the RFQ ADoc instance. Assume each of these Collaborations has an Activity named “Create Quote”. As these Activities become available, they bind dynamically with the appropriate RFQ ADoc instance, forming an instance of a composition of an ADoc with multiple Activity instances. The event propagation model described earlier for ADoc compositions applies here as well. Essentially, the ADoc-Activity composition is a rooted tree with a depth of one, the ADoc as the root, and the Activities as the leaves. The event received by the ADoc is passed to the activities. Likewise, the event received by any one of the activities is passed to the ADoc.

6

3.4.3 Activity with multiple ADocs ADocs and Collaborations interlock in a many-to-many relationship. We discussed earlier the need for an ADoc to participate in multiple collaborations. A Collaboration may need to be associated with multiple ADocs as well, if the data context for that Collaboration is composed by those ADocs. Consider a design process in the automotive industry modelled using the ADOP paradigm. We may have a Collaboration for engaging a set of domain experts to evaluate an engine design. These experts may look at a set of candidate designs and rank them. The individual designs themselves may be modelled as ADocs. In this scenario, a collaborative design activity needs to be associated with all the relevant design ADocs. We can use the composition of an Activity with multiple ADocs to accomplish this. This composition is a rooted tree with the Activity as the root and the ADocs as the leaves. The event propagation model follows the same pattern as before. The external event received by the activity is propagated to all the ADocs, while the event received by the ADoc is passed to the activity.

3.5 Programming Model Revisited From the modeling perspective, ADocs and Collaborations may be thought of as components. The ADoc programming model is based on the composition of these components.. The behavior of an ADoc is adaptive, as it changes to adjust to the context it is in. This adaptation is made possible by the dynamic binding of ADocs with Activities from the associated Collaborations. The components are event-driven. The clients can send events to the ADocs or the Activities in Collaborations. The “client view” may be ADoc-based or Activity-based. In the ADoc-based view, the client can look at all the ADoc instances that it has access to. In the Activity-based view, the client can look at the Activity instances that it is permitted to access. Using the RFQ process as an example, a Buyer may look at the RFQ ADocs that were created by him or assigned to him. This is the ADoc-based view of the system. The Buyer may select an RFQ ADoc and decide to cancel it. The ADoc will process the event if cancellation is permissible at this stage of the RFQ and propagate the event to any Activities associated with it. External events are time-stamped as they arrive at an ADOP-based system. Internal events are time-stamped when they are generated. The time stamping serves two purposes: (1) it provides a mechanism to enforce temporal dependencies; (2) it eliminates processing of duplicate events.

4. SAMPLE APPLICATION We use a Private Trading Exchange as a sample application to illustrate the use of ADoc-Oriented programming paradigm in modeling complex applications. The Private Trading Exchange (PTX) is a trade exchange hosted by a single company to facilitate collaborative e-commerce with its trading partners. A typical PTX system is extremely complex with support for dozens of business processes and connects the IT systems of thousands of companies. We use the PTX at a retail company

7

as an example to illustrate the use of ADOP in building complex systems that enable large-scale integration and collaboration functions. The scope of the PTX typically includes CPFR (Collaborative Planning Forecasting & Replenishment) [28], RFQ (Request For Quote), Contract, PO (Purchase Order), ASN (Advanced Shipping Notice) and Delivery processes. Two of these, Contract and Delivery, are being used in this paper to illustrate the application of ADOP design paradigm.

4.1 Supplier Contract Management The Contract process deals with the collaboration involving the Retailer and its Suppliers to put a mutually acceptable contract in place that drive the delivery of goods. It starts with the Retailer generating a Contract using their legacy contract system and sending that to the Supplier for concurrence. The Supplier could accept it, reject it, or suggest a modification. If the Supplier modifies the Contract, Retailer can respond by an "accept" or a counter-offer. An "accept" or "reject" by either party terminates the Collaboration. An "accept" by the parties does not result in an immediate closing of the contract. Similarly, a “reject” does not cause the immediate cancellation of the contract either. After a mutually agreed grace period following the accept (or reject), the contract is closed and is binding to both parties (or cancelled resulting in the termination of business between the parties.) While in the grace period, either party can revoke their decision, leading to a repeat of the process described above. The Contract and the associated data is a very important part of modeling the Contract process. The Contract describes the terms and conditions under which Retailer and the Supplier engage in business, specifically with respect to delivery of goods. The Contract document specifies these terms and conditions. Additionally, it specifies several other documents that need to be referenced to correctly understand the Contract. For simplicity, we discuss two such documents here: (1) The Lab Test Procedures and Test Data that needs to be provided with the shipment of goods (2) The Quality Control process the Retailer has in place for this Supplier. These are examples of unstructured data associated with the Contract. Additionally, there is structured data stored in relational databases. These include Contract table, Supplier table, and Product table, to name a few. For modeling the Contract correctly, we need to capture these dependencies as well. Further, it is important to dynamically aggregate the content associated with a Contract and present views of this content based on the context in which these views are used. For example, the view of the Contract presented to the Suppliers for getting their approval may need to display not merely the terms and conditions of the contract but information on laboratory test requirements and quality control processes as well. But a view presented to the Retailer in the context of approving a modification suggested by a Supplier may show only the part of the contract that is being modified. The life cycle management of a Contract is important from the business perspective. A contract may begin its life as a “draft” document. Once it is approved, it becomes “active”. If it is rejected by either party, it is said to be “rejected” . After the term of the contract expires, it is “expired”. A Contract could also be “terminated”, “cancelled”, and “archived”. The set of business events it can handle depends on the state of the Contract. For example, a Supplier can modify a Contract only when it is in the “draft” state.

8

4.2 Delivery Management Next we describe the Delivery process. It has two subprocesses: (1) Shipment Verification (2) QC Booking. The purpose of Shipment Verification is to get confirmation from the suppliers on the delivery date, vessel, and carrier. This gives the suppliers an opportunity to notify the retailer on any changes in the previously agreed upon delivery dates. The contract specifies the time window in which such modifications can be made. A few days before the expiry of the time window, the suppliers are notified and asked to confirm the delivery date and provide the vessel and carrier information. A request to change the delivery date needs the approval of the retailer. If the request is not approved by the retailer, the Supplier may send in a new request. If the two parties are not able to resolve the issue before the expiry of the time window, the original date in the Purchase Order is binding. The Shipment Verification process operates on “shipments”. A shipment is a collection of goods shipped by a supplier to the retailer in one vessel. The goods in a shipment may come from different Purchase Orders, but share a delivery date, vessel name, and carrier. Figure 2 shows the relationships of Purchase Orders, Shipments, and Contracts. A Contract typically covers several Purchase Orders. A Purchase Order has multiple line items. Line items from several Purchase Orders could be bundled into a Shipment. Typically, a supplier cannot ship goods before they are inspected and certified by a quality control (QC) agent. Some suppliers are exempt from this requirement. The quality control requirements are outlined in the supplier contract. If QC inspection is required, then the suppliers may group a set of shipments together and present this group to the QC agent. Such a group is called a “ Lot”. The QC Booking process deals with the formation of such groups, and the assignment of a QC inspector and an inspection date to the Lot. Suppliers form the Lot and request the inspection agency to assign an inspector and a date. Once the supplier and the QC agency have agreed on a date, the information is sent to the Retailer for the final approval. Next we discuss the life cycle management of shipments and Lots. As a shipment is created by a Supplier, it has a delivery date derived from the Purchase Order line items being included in the Shipment. (All line items in a Shipment need to have the same delivery date.) The Shipment is said to be “open” at this point in time. Any changes to this delivery date or the addition of vessel and carrier information will result in the retailer being notified. The Shipment is then in “pending approval” mode. Contract

Purchase Orders

Line Items

Line Items

Shipment

Figure 2: Shipment and its dependencies

9

Once the Retailer has approved the date change or the time window for such changes has passed, the Shipment moves to either “pending QC” or “ready”, depending on whether the QC inspection is required. Shipments that need QC inspection moves to “ready” if certified by the inspector. If the goods fail the QC inspection, the Shipment us “rejected”. Only shipments that are “ready” can be shipped, and then it is “in transit”. Once the Retailer receives the goods, the Shipment is said to be “delivered”. The Lot has a shorter life cycle. A Lot is created by a supplier and initially it is a “draft”. It becomes “active” once the inspector and the date are assigned. From there, it could be “rejected” or “approved” based on the results of QC inspection. Eventually, it is “archived”.

4.3 System Design In object-oriented programming paradigm, identifying the “objects” is a key part of the design process. Similarly, in ADocoriented programming, the system design revolves around the identification and definition of the ADocs. The key information artifacts in the target solution domain are modeled as ADocs. In the subset of the PTX problem we discussed above, there are three such artifacts: (1) Contract (2) Shipment, and (3) Lot. We use them as ADocs in our design. There are three ADoc compositions possible in the system. A set of Shipment ADocs may be associated with a Contract ADoc. This association implies that the terms and conditions for the Shipment are dictated by the associated Contract. The second composition involves a Lot with a set of Shipments. This implies that the Lot is made up of the associated Shipments. The third involves a Contract with the Lots, implying that Lots are bound by the Contracts as well. Figure 3 shows the ADo cs and their compositions. Contract 10

Lot 20

Shipment 101

Lot 21

Shipment 102

Shipment 103

Shipment 104

Figure 3: Example of ADoc instances and their compositions

Next we look at the Collaborations in our design. Supplier contract management involves a collaboration between the Retailer and the Supplier, which we call Supplier Collaboration. This Collaboration binds with the Contract ADoc. The Shipment Verification process translates to another collaboration between the Retailer and Supplier. This binds with the Shipment ADoc, as an instance of this collaboration takes place in the context of a Shipment. The third and final collaboration involves Retailer, Supplier, and the QC Agency. The Lot provides the context for this collaboration. The second and third Collaborations are called Shipment Verification Collaboration and QC Collaboration respectively. The figure below shows the ADoc-Collaboration associations. Though this example shows a one-to-one mapping between ADocs and Collaborations, there could be a many-to-many mapping in general.

10

Contract ADoc

Supplier Contract Collaboration

Shipment ADoc

Shipment Verif. Collaboration

Lot ADoc

QC Collaboration

Figure 4: ADoc-Collaboration associations

In the remainder of this section, we describe the participating ADocs and Collaborations in detail.

4.3.1 ADocs Definition of an ADoc includes three sections, two of these are required while the third is optional. The required sections are the Data Context definition and the Behavior definition. The View definition is optional. The Views are used only in systems that support interactive user experience. Systems where all client interactions are strictly programmatic, Views are not required. For example, in the PTX application we discussed earlier, a Supplier may interact with the system via a Browser interface in which case the Views of the ADocs are used for user interaction. Alternatively, computer programs running in the Supplier’s IT environment could act as user proxies and programmatically exercise PTX functions. In this scenario, ADoc views are not used. In this paper, we focus on programmatic access of ADoc functions, hence we do not discuss the ADoc views in detail.

4.3.1.1 Contract ADoc The data context of a Contract ADoc is made up of the following: q

Contract ID and data access commands for retrieving/updating contract data.

q

Supplier ID and data access commands for retrieving supplier data from the data stores.

q

Lab Test Procedure ID and data access commands for retrieving lab test process documents.

q

QC Inspection Process ID and data access commands for retrieving QC inspection process documents.

The ADoc behavior is described using a Finite State Machine. Figure 5 shows the finite state machine of a Contract ADoc. Initially, when the Contract is created, the Contract ADoc is in DRAFT state. In this state, the Retailer can make as many modifications as necessary. Once the Retailer submits the Contract for Supplier approval, the ADoc executes a command to spawn the Supplier Contract Collaboration. The state machine transitions are tagged by the event causing it (Submit, Modify, etc), the guard condition (User==Retailer), and the Commands executed (Update; Spawn-Collaboration). From this Collaboration, an “approve”, “reject”, or “modify” event could be propagated to the Contract ADoc. Since there are events propagated from the Collaboration to the ADoc, these are specified as C::Approve, C::Reject, and C::Modify respectively in the Finite State Machine. The mechanism for this event propagation was discussed in section 3.4 on ActivityADoc compositions. In section 4.4, the dynamic compositions are discussed in detail for this specific scenario.

11

The C::Approve event transitions the Contract ADoc to APPROVED state, while C::Reject event transitions the Contract ADoc to REJECTED state. Either of these events signals the end of the collaboration. But C::Modify event could occur multiple times while the collaboration is ongoing. Supplier or Retailer could suggest modifications to the Contract in an infinite loop. The grace period starts as soon as the ADoc is in the APPROVED or REJECTED state. The end-of-grace-period signal moves the ADoc to an ACTIVE or CANCELLED state. From the ACTIVE state, the ADoc could move to EXPIRED state when the term of the contract expires.

4.3.1.2 Shipment ADoc The data context of a Shipment ADoc is composed of the following: q

Shipment ID and data access commands to retrieve and update shipment information in the persistent store.

q

Purchase Order Line Item Identifiers and data access commands to retrieve Line Item data from the enterprise information system that stores Purchase Orders.

When a shipment is first created by the Supplier, the corresponding ADoc is created and it is in the OPEN state. In this state, the Supplier can modify the delivery date if necessary. If they modified the date, they submit it for Retailer approval. This event, called “Request-Sate-Change” causes the ADoc to spawn QC Collaboration. The QC-Booked event transforms the state from OPEN to PENDING-QC. If QC inspection is not required, a “Ready” event from the manufacturing floor changes the state of the Shipment to READY. If QC inspection is required, the Shipment reaches READY state when “QC Pass” event is received.

4.3.1.3 Lot ADoc The data context of the Lot ADoc consists of a Lot ID and the data access commands for reading and updating Lot data from the data store. Date-Request event causes the ADoc to spawn the QC Collaboration. The Date-Entry event changes the state to ACTIVE. Depending on the result of QC inspection, the state then changes to REJECTED or APPROVED.

4.3.2 Collaborations There are three parts to defining a Collaboration: (1) The participating Agents (2) The definition of its Activity Choreography mechanism, and (3) The definition of the Activities. The activity choreography is used to identify the set of activities associated with a Collaboration and the order in which these Activities are executed. There are three ways this could be accomplished: 1.

The Activities may be associated with a Collaboration in an ad hoc manner while the system is running. The client programs may use the Collaboration APIs to add Activities.

2.

The set of activities and the order in which they are executed are defined a priori. There are different representation schemes for defining this. A commonly used mechanism is a directed graph, where the nodes are the Activities and the arcs represent the dependencies between them. This is the approach taken in the control flow of workflow graph [8].

12

3.

A hybrid approach may be employed in which the set of Activities are predefined, but not the order of execution. At runtime, an inference engine analyzes the context and determines the order of execution.

In this paper, we focus on the second activity choreography mechanism in the list above. An Activity is defined using the Finite State Machine controlling it. Each Activity is associated with a set of Agents that can act on it. The default Finite State Machine of an Activity is presented in section 3.3. For the Activities used in the sample application, we discuss below how the default behavior is extended for customization. Submit[ User==Retailer ] / Update; Spawn-Collaboration C::Modify[ None ] / Update

DRAFT

C::Reject[ None ] / Update Contract DB; Notify; Schedule Grace Period

C::Approve[ None ] / Update Contract DB; Notify; Schedule Grace Period

APPROVED REJECTED End-of-Grace-Period Signal[ None ] / Update; Notify; Schedule Term Expiry Signal

ACTIVE

End-of-Grace-Period Signal[ None ] / Update; Notify

CANCELLED Term-Expiry Signal[ None ] / Update; Notify

EXPIRED Archival Signal[ None ] / Archive; Purge

ARCHIVED

Figure 5: Finite State Machine for Contract ADoc

We discuss the details of the Supplier Contract Collaboration below. The Agent set associated with this Collaboration is {Supplier, Retailer}. There are two activities in this collaboration, one assigned to the Supplier and the other to the Retailer. The activities are S-Disposal and R-Disposal. The directed graph for activity choreography is shown in the figure below. Both FSMs have similar structure and extends the default behavior to support “Modify”, “Approve”, and “Reject” as valid events that trigger the state change from CLAIMED to COMPLETED. Since these activity instances are dynamically bound to the Contract ADoc instance in an ADoc-Activity composition, these events are propagated to the ADoc from the Activity. Processing of these events by the ADoc controller is discussed in section 4.3.1.1. The behavior of the system as it executes Supplier Contract Management Process is discussed in detail in section 4.4.

13

Supplier

PASSIVE

Retailer

Start Activate

Initiator?

AVAILABLE

Spawn[ Initiator==Retailer ] Spawn[ Initiator==Supplier ]

S-Disposal

Claim[ USER==Supplier ] / Claim-Command

R-Disposal

CLAIMED

Modify

Modify Modify[ USER==Claimed User ] / Complete-Command Approve[ (USER==Claimed User) ] / Complete-Command

Approve or Reject Approve or Reject

Reject[ USER==Claimed User ] / Complete-Command

End

COMPLETED

Figure 6: Activity Choreography for Supplier Contract Collaboration and the Activity Controller for S-Disposal Activity

4.4 Putting It All Together We discuss the behavior of the PTX system as it executes the Contract Management Process in detail in this section. At build-time, the three ADocs (Contract, Shipment, and Lot), the three Collaborations (Supplier Contract, Shipment Verification, and QC), all the Commands used by the ADocs and Collaboration Activities, and the Receivers invoked by these Commands are described. These descriptions are in a scripting language based on XML. The details of this language are discussed in section 5.1. At startup, the runtime reads in all these descriptions and configures the PTX application. We present a step-bystep description of a scenario for Supplier Contract Management in Figure 7. Steps 1 through 6 show the system response to a Retailer Client creating a new Supplier Contract. At the point in time, PTX is populated with a Contract ADoc in DRAFT state. Steps 7 through 13 show the system behavior in response to the submission of the Contract by Retailer for Supplier approval. This results in an S-Disposal Activity in AVAILABLE state to be bound to the Contract ADoc. In steps 14 through 25, Supplier claims the activity, and then proposes a modification to the Retailer. In response, S-Disposal Activity runs to completion and the R-Disposal Activity is made available to the Retailer. This Activity is in AVAILABLE state and bound to the Contract ADoc. Steps 26 through 37 show how system reacts to the Retailer accepting the modification. The R-Disposal Activity runs to completion, and the state of the Contract ADoc moves to APPROVED. It should be noted that real world PTX systems include a lot more details than the one we presented here. We have eliminated these details for better utilization of the limited space.

14

1: Create Contract

Retailer Client

Facade 6: 5:

2: Instantiate

7: Submit 19: Process Modify Event 31: Process Event

13: 3: Update 32: Update 27: 35:

Contract ADoc

26: Claim 28: Approve

Backend Systems 4: 33:

12:

8: Spawn

30: Propagate Event 24: Bind with ADoc 29: Process Event

20: 10: Bind with ADoc 17: Process Event

37: Terminate 18: Propagate Event

34: 25: 36: Signal completion

R-Disposal Activity

9: Activate

Contract Collaboration 23: Activate

S-Disposal Activity 11: 22: Notify Completion 14: Claim 16: Modify

15: 21:

Supplier Client

Figure 7: Sequence Diagram for Contract Management

5. ADOP METAMODEL AND BUILD-TIME In this section we describe a metamodel and associated build-time methodology for describing ADOP components. An Adaptive Document (ADoc) is described by two subcomponents and an optional service interface. The two main components are: (1) the object representation of the entity, containing information for content aggregated from various data sources and (2) the Service Broker or Controller associated with the ADoc. The View component discussed in section 3.2 is not in the scope of this implementation. In Figure 8, we present a concrete example of a Purchase Order ADoc to discuss the subcomponents of an ADoc. The PurchaseOrderADoc, PurchaseOrderController and the PurchaseOrderService are respectively the entity, broker and the optional service interface used to model the event driven behavior and life cycle of a Purchase Order.

5.1 Controller/Service Broker The Controller implements the behavior of an ADoc. Clients communicate with the ADoc by issuing a Service Request. When a service request arrives at the ADoc, it uses the state to determine if the request can be entertained, and if so, it uses the controller to broker the services needed to satisfy the request. The Controller is modeled as a finite state-machine.

15

AdocBean getAdocId() getAdocState() getAdocType() getAdocOwner() getAdocParent() getChildAdocs() serviceEvent()

Part Of The Framework

Client AdocProxy getBaseAdoc()

Data

PurchaseOrderService createPO() validatePO() approvePO() rejectPO() cancelPO() dispatchPO() query()

manipulate

event

PurchaseOrderAdoc

broker

PurchaseOrderController

getPurchaseOrderId()

transact

Applications

manage provides and maintains context for the Controller

Collaborations

Figure 8: Purchase Order ADoc

An instance of an ADoc moves from its starting state, through intermediate states to a completion state during its lifetime. These state changes (transitions) are triggered either through service requests (events) directed to the ADoc component or method calls on the optional service interface. In the latter case, the service interface will send the appropriate event to the ADoc component. Each state within the state machine has a set of transitions to other states. The selection of a particular transition is based on the identity of the caller, the type of event raised (based on which method was called) and whether a condition has been satisfied. In this respect, the State Machine is essentially a subset of the UML State Machine definition. Each transition may have one or more actions associated with it. An action provides the abstraction to access various systems participating in the process. Relational data sources, business objects, collaboration components (like workflows) or connectors to enterprise information system are examples of components that can be represented via the action abstraction. The state transitions are transactional. All the actions that are triggered by a service request are completed within the same logical unit of work. The ADoc moves to the target state on successful completion of the actions. Incase of a failure, the state change will not occur and if necessary, recovery procedures such as compensation actions will be executed. The Controller is specified using the XML Schema shown in Figure 9. An XML file consistent with this schema is generated by the ADOP tooling. The runtime reads this XML file at system startup and configures the system.

16

name state-machine

state

State Type

name

1..n

type timeout

Transition Type

transition

event

0..n

condition target-state action 0..n

Figure 9: ADoc Controller Schema CreatePO / spawn("CreatePOFlow")

'Received

Validate Invalid Data

CancelPO / terminate("CreatePOFlow"); spawn("CancelPOFlow")

'Validated

Approve CancelPO / terminate("CreatePOFlow"); spawn("CancelPOFlow")

Not Approved Approved

NotAllInStock

Allocate Stock Not in Stock Anywhere

BackOrder ed Allocate Stock

'Rejected Allocated

CancelPO / terminate("CreatePOFlow "); spawn("CancelPOFlow")

'Cancelled Package

Packaged

CancelPO / Terminate ("CreatePOFlow")

CancelPO / terminate("CreatePOFlow"); spawn ("CancelPOFlow")

Dispatch

Dispatched

ReceiptAcknowledged

Finished

Figure 10: State Machine for PO ADoc Controller

Figure 10 shows the state machine for a Purchase Order (PO) ADoc. When the PO ADoc is created, it is in the “Received” state. After creation and entering the initial state, the PO ADoc reacts to business events by transitions to other states, until it reaches the terminal state (Finished). Each transition is triggered by a named event and executes one or more actions before entering the target state. For example, the PO ADoc moves from the “Approved” to the “Cancelled” state on the ‘Cancel PO’ event. Two actions are performed during this transition. The first action terminates the ‘Create PO’ collaboration (modeled as a

17

workflow) that was spawned on an earlier transition. The second action spawns a new collaboration that handles the cancellation of the PO with the concerned agents being assigned activities to act on the cancellation process. Actions are modeled using the Command and Composite design pattern [18]. Using the composite design pattern, shown in Figure 11, it is possible to compose commands to form composite-commands or micro-flows. The commands are specified using XML. The XML command schema is shown in Figure 12.

Command

Basic Command

CompositeCommand

Figure 11: Composite Command Each command has zero or more input parameters and returns an output. Both input and output data structures are specified as a name-value pair. The command is identified by its method name. The commands executed within a state transition are in a single unit of work. In the event of a transaction failure, the actions executed by the commands are undone using the undo commands. Some of the end points that are engaged may not be transactional systems and recovery entails using compensation logic. Such logic can be encapsulated in the undo commands.

command id command list

name command 1..n

input 0..n

value name

output value method name receiver id undo command 0..n Figure 12: Command Schema

The receiver associated with a command is identified by the receiverId. The receiver is an interface to the service providers, i.e., implementations of the business logic expressed in the commands. This level of indirection provides by the receivers enables the dynamic mapping of the service providers to the commands.

18

There can be many types of receivers such as a JMS (Java Message Service) [20] receiver for asynchronous connectivity to various back-end applications and systems or RMI, EJB (RMI-IIOP), CORBA (IIOP) [20] receivers for synchronous connectivity to business objects and enterprise applications. Cross enterprise integration may be modeled by specifying externally exposed services as Web Service receivers, although Web Services may be used for intra-enterprise integration as well. Object-based interfaces, whether local (same JVM) or distributed (RMI, EJB, CORBA, Web Services), are easily mapped to the command-receiver paradigm. For the non-object based protocols (JMS, JCA, JDBC etc.), Java wrappers are provided as part of the runtime. The receivers are specified using XML as well. The structure of the receiver is shown in Figure 13. (Notice that the schema shows protocol bindings for EJB and Java only).

local | remote receiver id receiver list

Receiver

ejb

jndi name implementation class

protocol

1..n

home class

java

class name constructor parameters 0..n

name value

corba web service

Figure 13: Receiver Schema

5.2 Service Interface The service interface (PurchaseOrderService in Figure 8) acts as a façade and a single point of entry for clients. More importantly, the methods on the service provide a strongly typed interface for clients to pass event parameters. The service interface is typically generated by tooling and fits the J2EE programming model [20]. It implements the notion of a Message Driven Bean (MDB) to support asynchronous or message-based clients communicating via the Java Messaging Service (JMS). Calls to the service interface can be categorized into 3 types; (a) methods to manage the life cycle of ADocs (create, remove, archive) (b) solution specific methods for clients to send business events to particular ADoc instances and (c) query interfaces to inquire the status of a single or group of ADocs. Access to the service interface methods would normally be restricted based on the identity of the client (program or human) interacting with the system. For example, only the Administrator is allowed access to the CancelPO method.

19

5.3 Entity The ADoc entity holds the state information of the ADoc instance. It also provides the appropriate context and acts as an editable resource folder to the Controller and the services it brokers. It is modeled as a CMP (Container Managed Persistence) EJB and support for transactions and transactional isolation, thread-management and security are automatically provided by the EJB container. The ADoc entity is composed of a base part and a solution part. The base part is a system component. It persists the common attributes for the ADoc, such as state, owner, type of controller, and relations to other ADocs. It is also responsible for instantiating the Controller object and passing client service requests to the Controller object for execution. The role of the solution part of the ADoc is to hold domain-specific content. It extends the base and acts mostly as a container for aggregated data references. The Solution part of the ADoc entity is implemented as a Container-Managed EJB as well.

5.4 Putting It All Together To summarize, building an ADoc component comprises of the following steps: o

Generate the Solution ADoc entity EJB (for example, PurchaseOrderADoc)

o

Generate the Controller XML file containing the state machinedescription (for example, POADocController.xml)

o

Register Receivers in the receiver registry (for example, by specifying the receivers in a “Receiver.XML” file).

o

Register Commands in the command registry (for example, by specifying the commands in a “Commands.XML” file).

o

Generate the service interface (for example, PurchaseOrderService).

6. ANALYSIS OF ADOC-ORIENTED PROGRAMMING This section presents an analysis of ADoc-Oriented programming approach. We begin with the unique features and strengths of this approach, discuss the opportunities, and conclude the section with a discussion of our experience in using this system in customer engagements.

6.1 Strengths of ADOP Approach Below we list the unique features and strengths of ADOP:

o

ADOP provides an Object-Oriented solution for business process management. The prior work in business process management has focused heavily on flow models [7],[8],[9],[11],[12]. Even the work specifically targeted to build OO systems [10] has managed only to create a façade for flow control engines.

o

ADOP supports modeling of distributed BPM applications. Truly distributed BPM applications are inherently autonomous. An excellent example is Business-to-Business integration, where multiple businesses integrate their IT systems to execute cross-enterprise business processes [27]. The notion of a “conversation” is the key to modeling such integration scenarios. ADocs may be used to model the exchange of multiple correlated messages with arbitrary sequencing constraints that form a conversation [14].

20

o

ADocs are inherently scalable. Most business systems are embarrassingly parallel. ADOP based systems exploit this by associating a thread of control with every instance of a business document. All transactions on that business document are routed to this control thread, which is implemented as an ADoc Controller. The ADoc instances can be distributed in a network of machines. As the number of business documents increases, performance levels can be maintained by adding more nodes to the network [15],[16].

o

ADOP reduces software complexity via orthogonal decomposition of solution space. Well-designed OO systems reduce software complexity by enabling the modeling of the application space by orthogonal class families. This leads to the realization of rich application functionality by composing object instances from these class families. In ADoc-based systems, we observe the same feature, as ADocs and Collaborations are orthogonal modeling elements. Compositions of ADocs and Collaborations lead to powerful, yet simple, BPM solutions.

o

ADocs support a solution assembly paradigm and facilitates the realization of new functionality from existing components. The ADoc controller state machine serves up new business behavior while the legacy systems are utilized in providing pieces of the new functionality. The controller uses Command design pattern [18] to bind abstract actions to specific receivers, which in this case are the APIs of the legacy systems. In most cases, syntactic and semantic adaptation is necessary for this to work [17]. Java Connectivity Architecture provides a standardsbased technology to build such adapters [20]. ADocs serve as the glue that brings together all the components of a BPM solution, leading to the definition and implementation of reusable solution templates.

o

ADocs support event-driven programming. A façade object routes the external events to the appropriate ADoc or Activity. An ADoc may propagate this event to other ADocs or Activities if it is part of a composition. Similarly, an Activity may propagate the event to associated ADocs.

o

ADOP provides a unified model for integration and Collaboration. The ability of this system to present a unified model for integration and collaboration stems from the composition of ADocs and Activities.

o

ADOP brings together information integration and process integration. Traditionally, information integration and process integration has been treated in isolation. In reality, these are merely different aspects of the integration problem. In ADoc-Oriented programming, we present a model that supports both. From the information integration perspective, ADocs provide a way to dynamically aggregate content that is fractured and distributed. One could think of an ADoc as a virtual business artifact that provide context -specific views by aggregating content on demand. Additionally, by modeling the application state and the process state and tying that together with the content aggregation function, we present an approach to integration that subsumes process integration and information integration. A specific data integration technology, such as data federation, could still be used in the context of the data aggregation function of the ADoc.

o

ADOP provides native support for collaboration. There are several models of collaboration, examples include workflow collaboration, real-time collaboration, peer-to-peer and multiparty conversations, and team rooms. In ADOP, the notion of a Collaboration object is used to model the collaborative activities, with the ability to create various

21

types of collaboration by specifying an appropriate Activity Choreography mechanism and composing the Collaboration instance using that. o

ADOP supports Process Brokering. Non-trivial BPM systems have several processes that are concurrently active and manipulate shared business data. A business event, external or internal, could impact several of these processes and modify business data distributed across the enterprise. Consider a supply chain management application hosted by a large manufacturing company. The cancellation of a Purchase Order by a customer may impact the logistics processes, CPFR (Collaborative Planning, Forecast, and Replenishment) processes [28], and financial processes. There is a requirement to “broker” the event, such that the event can be propagated to the appropriate processes and business components. This event propagation is dependent on the application state. The ADoc instances in a BPM application serve as a distributed process broker. The event is routed to the appropriate ADoc instance. The ADoc instance processes the event based on its current state and the contents of the event, then propagates the event to other ADocs or Activities based on the compositions it is part of. The commands that are executed as part of this event processing could map to method invocations on enterprise information systems, notifications to enterprise users, creation of new ADocs and Collaborations, termination of existing Collaborations, etc.

o

The notion of “ADoc views” supports a RAD environment for interactive business process management applications. These views are defined as part of an ADoc and are adapted based on the “context” in which it is looked at. The context could include the role of the user, the state of the ADoc, the Activities associated with the ADoc, and the states of these Activities. The views represent only the information to be presented, the data to be garnered, and the set of available actions. The rendering of these views is decoupled from the view definition. The views are defined using XML and the rendering is specified using XSL.

o

ADocs provide the right granularity for server side componetization. One could visualize a solution assembly paradigm in which ADocs are retrieved from a repository, configured appropriately, and bound to the “environment” to realize BPM solutions. This vision becomes all the more powerful when universally accepted standards emerge for specification and runtime support of ADOP artifacts.

o

ADOP facilitates externalization of “wiring” logic. The XML files that describe the ADoc and Activity controllers, the command XML files, and the receiver XML files together encapsulate macro level system behavior. This logic can be easily modified, even programmatically, leading to adaptive and dynamic systems.

6.2 Validation in the Marketplace The technology discussed in this paper has been validated extensively in the marketplace via customer engagements as part of a core component of an eBusiness Platform for Integration and Collaboration [21]. These customer engagements have paved the way for the technology to evolve to its present form, our ideas to crystallize, and the strengths discussed above to surface. We list below some of these validation points:

22

o

A Virtual Corporation Management System in which multiple companies dynamically form virtual coalitions to serve specific customer opportunities. The coalitions disband once the service has been delivered and all the associated processes are completed [19].

o

A Web-based supply chain management system for a distributor in retail industry to integrate their partner systems with their enterprise systems.

o

A procurement portal for a large manufacturer to connect their suppliers with internal business processes.

o

A Private Trading Exchange for a large automobile manufacturer [27].

o

A public eMarket for retail industry.

o

A supply chain management system for a diversified heavy equipment manufacturer.

o

A collaborative product lifecycle management application [29].

o

Straight Through Processing for financial industry.

7. RELATED WORK The UML (Unified Modeling Language) state machines [23] are used extensively in object oriented analysis. We use a subset of UML state machine to define the ADoc and Activity controllers. From the ADoc-oriented programming perspective, a finite state machine is merely one of the ways to define a controller. For instance, a rule engine [25] could be used for choreographing the controllers in place of the finite state machine. While deterministic finite state machines have the benefit of predictable behavior, they define “closed” systems and may not be suitable for modeling emergent phenomena. Rule-based ADocs may be better equipped to model such behavior. In any case, it is important to realize that crux of our approach is not the use of finite state machines, but the modeling of the solution space via business artifacts and collaborations and their compositions. Harel and Polity [22] discuss modeling of reactive systems with statecharts. They use statecharts and activity charts to develop a conceptual model of the system. Harel’s statecharts are a generalization of the UML state machine [26], while the activity chart describes the system activities and the data that flows between them. The statecharts present the behavioral view while the activity charts present the functional view of the system. In contrast, the power of the ADOP approach is in the modeling of the system behavior via compositions of ADocs and Collaborations. The design patterns [18] have influenced our work in many ways. In particular, the Command design pattern, the Composite design pattern, and the Façade design pattern are heavily used in designing the system. Most work in business process management has focused on flow models [9],[11],[25]. While flow models have an important role to play, they are not sufficient to model BPM solutions for the enterprise. The shortcomings of the flow models in modeling non-trivial BPM applications are discussed in detail in [12]. In this paper, we have presented a modeling approach that is based on OO principles, while leveraging the flow models as appropriate.

23

8. CONCLUSION Enterprise computing landscape is evolving in various dimensions. There is increased focus on solution assembly as opposed to solution development. There is an emphasis on integrated solutions, as opposed to functional silos. It is not enough to have multi-user environments, but collaborative systems that facilitate enterprise collaboration among an online community of users is the norm. In this paper, we introduced the notion of an ADoc as a higher level modeling artifact, formalized collaborations, and showed how compositions of ADocs and Collaborations can serve as a powerful tool to model enterprise applications that focus on business process management, integration, and collaboration. 9.

REFERENCES

[1] Ross Altman, “Total Business Integration, Strategy & Tactics/Trends & Direction,” Gartner Reports, February, 2001 [2] David McCoy, Jess Thompson, “Application Integration Thriving Among Standards, Strategy & Tactics/Trends & Direction,” Gartner Reports, July, 2001

[3] Joanne Correia, “Looking Forward to 2005 in the AIM Market, Strategy & Tactics/Trends & Direction,” Gartner Reports, July, 2001 [4] Joanne Correia, “What's Happening in the Infrastructure Software Market, Strategy & Tactics/Trends & Direction,” Gartner Reports, August, 2001

[5] Roy Schulte, Ross Altman, “Application Integration: Success Amid Turmoil, Strategy & Tactics/Trends & Direction,” Gartner Reports, August, 2001

[6] Roy Schulte Ross Altman, “Integration Middleware Vendors Mix and Match Functionality, Strategy & Tactics/Trends & Direction,” Gartner Reports, August, 2001.

[7] F. Leymann, and D. Roller, “Workflow-based Applications,” IBM Systems Journal, vol 36, no 1, 1997, 102-123. [8] F. Leymann, “Web Services Flow language”, IBM, http://www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf [9] BPMI.org. “Business Process Modeling Language”, http://www.bpmi.org/bpml.esp [10] Schulze W., "Fitting the Workflow Management Facility into the Object Management Architecture", Workshop on Business Object Design and Implementation III, OOPSLA, 1997

[11] Thatte, S. XLANG: Web Services for Business Process Design. Microsoft Corporation, 2001. [12] D. Georgakopoulos, H. Schuster, A. Cichocki, and D. Baker, “Managing Process and Service Fusion in Virtual Enterprises,” Information Systems, Vol. 24, No. 6, 1999, 429-456

[13] McGregor, C., Kumaran, S. An Agent-Based System for Trading Partner Management in B2B e-Commerce, Proceedings of RIDE 2002, San Jose, CA.

[14] Hanson, J., Nandi, P., Kumaran, S. Conversation Support for Business Process Integration. Submitted to EDOC 2002.

24

[15] Liu, T., Kumaran, S. Layered Queuing Models for Enterprise Javabean Applications. Proceedings of the Enterprise Distributed Objects Computing Conference, 2001, Seattle WA.

[16] Liu, T., Kumaran, S. Enterprise JavaBean Response Time Analysis. Proceedings of CMG, 2001, San Jose, CA. [17] IBM WebSphere Business Integrator, IBM Corporation, http://gwareview.software.ibm.com/software/webservers/btobintegrator/library.html

[18] E. Gamma, R. Helm, R. Johnson, J. Vlissides, “Design Patterns – Elements of Reusable Object Oriented Software,” Addison-Wesley Publishing Company, NY, 1995.

[19] Nayak, N.; Bhaskaran, K.; Das, R., “Virtual enterprises-building blocks for dynamic e-business,” Proceedings of the Workshop on Information Technology for Virtual Enterprises, 2001. Page(s): 80 –87

[20] Java 2 Platform Enterprise Edition (J2EE), Platform specification, version 1.3. http://java.sun.com/j2ee/.

[21] Bhaskaran, K., Kumaran, S., Nandi, P., Das, R., Heath, T., Chung, J-Y. An e-Business Integration & Collaboration Platform for B2B eCommerce. In the Proceedings of WECWIS, 2001, San Jose, CA.

[22] Harel, D., Politi, M. The Statemate Approach: Modeling Reactive Systems with Statecharts. McGraw-Hill, 1998. [23] Rational Corporation. Documents on UML. http://www.rational.com/uml.

[24] Grosof, B. N., Labrou, Y., Chan, H. Y., A Declarative Approach to Business Rules in Contracts: Courteous Logic Programs in XML. Proceedings of the first ACM Conference on Electronic Commerce. 1999. Denver, CO.

[25] Nguyen, T.N., “Modeling EAI-based e-business solutions,” IEEE International Conference on Systems, Man, and Cybernetics, 2000, Page(s): 286 –291.

[26] Harel, D. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8, 1987. [27] Kumaran, S., Huang, Y., Chung, J-Y. A Framework-based Approach to Building Private Trading Exchanges. IBM Systems Journal (To Appear in June 2002).

[28] VICS Committee “Collaborative Planning, Forecasting and Replenishment Voluntary Guidelines”, June, 1998. [29] Kumaran, S. Collaborative PLM. IBM Technical Report, 2001. [30] T. Budd. An Introduction to Object-Oriented Programming. Addison-Wesley, 1991. [31] WebSphere Application Server, IBM Corporation, http://www.ibm.com/software/webservers/. [32] Process Broker Services Concepts Guide, ftp://ftp.software.ibm.com/software/btobintegrator/bizaam00.pdf

25