WIXLIB

TABLE I.Each business object is modeled by first modelingsharable data objects using nested relational model and thenmodeling data services affiliated with each data object usinggeneral operators of the nested relational model. We callthese business objects that are modeled directly fromindividual information systems as atomic business objects.Nested relational model is used to represent the internalstructure and external view of a data object. This is becausenested relational model is simple, intuitive, and expressiveenough to represent the semi-structured or structured data [5].For the definition of nested relational model, please refer topaper [6].UNARY OPERATORS FOR HANDLING THE NESTED EditSemanticsto create a new table by copying asub-relation or an atomic attributefrom one of the current tablesto create a new column and add it toa tableto delete a column from a tableto rename a column from a tableto filter a table by some condition,conditions is a group of conditionexpressions defined on the atomicattributes of this sub-relationto sort tuples in a table according tovalues of a certain attributeto edit a cell in a tableAnother challenge here is how to keep consistency whenmultiple services handle the same data object simultaneously.In our current design, the changes made by services shouldbe transactional. An operation should have the effect ofhaving exclusive control over the involved data object whenmaking its changes.Figure 2. A sample of nested relation model.B. Business objects composition from multiple informationsystemsFor certain business collaborations among severalorganizations, such as delivery of disaster relief materials,the information of each organization needs to be shared andintegrated on demand. So we need a simple way to composethe business objects of each organization in order to get anoverall collective data and service.Users can get composite business object by selectingneeded business objects and composing them via thefollowing steps: 1) choose business objects to be composed;2) select or transform the data objects in these businessobjects as needed using unary operators in Table I; 3)combine multiple different nested tables into a new oneusing multivariate operators (see below for details); 4)modify the combined table again if needed using the unaryoperators; 5) define the combined table as a data object; 6)define the operator process used in step 1-4 as one specialdata service of the data object, called “update”, andoptionally define more data service for the data object; 7)publish a new business object based on the data object andits data services.To facilitate operations on multiple tables, we definedtwo multivariate operators, namely Merge, and Fuse. Moreoperators could be defined for other functionalities.The merge operator merges schema of several tables andcreate a new head of a table. The formula of this operator fortwo tables is merge(a, b, a.X, b.Y ), where both a and bcan only be a relation or sub-relation, X and Y are atomicattributes of relation/sub-relation a and b. This operator isequivalent to the recursive union operation of the nestedrelational model. To note that only attributes with samenames from two sub-relations will be merged. If the namesof the attributes are not the same, users have to map theattributes first.The fuse operator is designed to fuse values of attributesin several tables. The formula of this operator for two tablesWith the nested relational model, business data can bevisually presented as nested tables. Figure 2 shows a samplenested table. It presents the delivering information of avehicle. The “Vehicle” relation has several atomic attributes(namely ID, currentLocation, status, source, target) and asub-relation one named “MaterialList”. The sub-relationdescribes the relief materials that are delivering or deliveredby this vehicle.As our previous work in [5], namely “Mashroom”, wetake “column” and “row” as first class objects of a nestedtable. A column represents an atomic attribute or a subrelation, while each row represents a tuple. An atomicworksheet attribute can be one of six types: text, textlink,img, imglink, video, and videolink. Furthermore, the syntaxof Mashroom formula is built from column references, rowreferences, operators, and constant values. The syntax ofcolumn references and row references are built from pathexpression in order to express the nested relational modelcorrectly. For example, a formula Vehicle/MaterialList/typespecifies the “type” column of the relation “MaterialList”which is a sub-relation of the relation “Vehicle”, andVehicle/MaterialList specifies the first row of the subrelationĀMaterialList”. When a row and a column of atomicattribute are given, then an array of cells is also defined. Inthe above example, when we choose the row 1and column“Vehicle/MaterialList/type”, then an array of cells, namely[tent, water], is found.As a data object is represented as a nested table, a dataservice can be built based on operators for handling nestedtables. A set of operators for handling nested tables has beenproposed in our previous work. Table I shows somecommonly used operators. Complete operators could befound in [5]. With these operators, users can easily definerequired data operations and assign them with properbusiness semantics. To be compatible with third-partyservices, data services are also encapsulated as Web services.56

is fuse(a, b, a.X, b.Y , function), where a, b can only be arelation or sub-relation and X, Y have the same semantics asthey are in Merge operator. The function defines how to fusedifferent values. For example, for numeric values, we can docalculations including addition, subtraction, multiplicationand others. For string values, we can concatenate or reversethem. The common functions can be pre-defined. Users canchoose needed ones when fusing tables.The above business object composition steps show bothdata integration and service integration can be achievedduring the same process by including data and service inbusiness object models. After the steps, users can choose touse this business object immediately or publish it for otherusers to use. We note that the same steps can be used tosupport nested business object composition.By saving the composition process for each compositebusiness object as a special data service, namely “update”,the status and data of composite business objects can beautomatically updated based on their constituent businessobjects changes. When a business object changes, it cantrigger the changes of all composite business objects madefrom it by calling their “update” data services. Then theoperators used for each composite business object will becalculated again to get its newest status and data.changed business objects or the metadata of new businessobjects has been used in a business object composition, thecomposite business object can be automatically updated. Theautomatic update is done by including the new businessobjects and re-calculating its composition operators bycalling its “update” data service. Otherwise, the new businessobject has to be manually added into composite ones, whichwill result in new composition process and “update” service.For instance, new materials in delivery, triggered by oneECA rule, need to be shown as parts of overall materialinformation at the EO. If a composite business object alreadyhas vehicles as its constituent objects, its value can beautomatically updated. This example will be illustrated indetail in Section IV.In summary, dynamic interaction between dataintegration and service integration is achieved here. Firstexisting service integration can be changed based on dataupdates by instantiating new services via ECA rules.Meanwhile, data integration results in composite businessobjects can also be updated based on the changes of dataobjects related to new services by calling or updating their“update” services.C. Information Monitoring and Event ResponseIn many dynamic collaborations, existing systems needto promptly adapt themselves to fit new scenarios. In ourapproach, ECA rules are defined to dynamically respond tonew events.In the UDSI approach, we first define a set of values usedto measure the status of a data object as KPIs. A KPI can bequantified as a value or a vector containing multiple values.The range of values can be flexible, such as number,character or string. The real time information of each KPI isgotten through periodically invoking the data services. KPIhelps business users easily analyze the large-scale businessdata and quickly grasp their business semantics.Since KPI represents key information in collaboration,changes of each KPI are also important. So we model theevents and conditions of each ECA rule based on selectedKPI information.We model the action of each ECA rule as a service tointeract with other services. An action might need to operatemultiple services with dependencies, and these complexbusiness logics can be modeled in services through servicecomposition. In the service composition, both data servicesand third-party services could be employed.After services are instantiated based on certain ECA rules,the data behind the services can be integrated into existinginformation monitoring via business object composition.New service instances could cause changes of existingbusiness objects or creating new ones. As explained inSection III.B, business object composition processes are onlybased on the metadata of constituent business objects. So ifIn this section, the case for the delivery of earthquakerelief materials in Section II is refined to illustrate how to usethe UDSI approach. We will still use the three phases inSection III to demonstrate the application.IV.APPLICATIONA. Atomic Objects ModelingIn this phase, each organization in the collaboration willmodel its information systems as a set of atomic businessobject, namely data objects as well as their data services.Main business objects in the case are showed in Fig. 3.(1) DPC: StorageThe DPCs will model the Storage business object torepresent their storage information about materials. DifferentDPC may have heterogeneous internal data structures andcorresponding data services. In this case, we will use twodifferent Storage business objects.(1.a) DPC StorageAThe DPC StorageA mainly stores and manages thefollowing materials: tents, stretcher, water and clothes.Therefore, its data object is StorageA (tents, stretcher, water,clothes). Several data services are provided for this ableStretcherNumber().(1.b) DPC StorageBThe DPC StorageB mainly stores and manages thefollowing materials: stretcher, medicine and war. So its dataobject is StorageB (stretcher, medicine and water). It cineQuantity(), etc.57

Figure 3. Data objects and visual representation with nested-tables.The EO will model the DestinationDepot business objectto represent received material information in a temporarydepot at disaster area. Its corresponding data object is (ID,type, number). An example of its data service isgetAvailabelNumberOfMaterial(type).(2) EO: RequiredMaterialThe EO will model the RequiredMaterial business objectto represent the required materials in the disaster area. Thecorresponding data object is RequiredMaterial (type,number). In that, the type attribute is for the type of requiredmaterial, such as tent, water and so on. The number attributeis for the required quantity of a material.Based on this data object, several data services can quiredMaterialNumber(type).(3) EO: VehicleThe EO will model the Vehicle business object torepresent the information of a vehicle that is in charge oftransporting materials to the disaster area. The correspondingdata object is Vehicle (ID, currentLocation, status, source,target, MaterialList(ID, type, number)). For this data rentLocation (), getStatus(), deliver(), etc.(4) EO: DestinationDepotB. Business Objects CompositionFurthermore, the above business objects can becomposed into new business objects on demand. Forexample, when an earthquake happens, the materials liketents, water and medicine consume very fast. The EO needsto monitor the information about how many materials havebeen in delivery and how many materials are still available.The expected data object is CollectiveMaterial (type,numberInDelivery, availableNumber).However, this CollectiveMaterial information isdistributed among different kinds of data objects: Vehicle,StorageA, StorageB. With the operators defined in SectionIII, we can easily create a composite business object for thispurpose and get its real time value. The combination processis illustrated in Fig. 4.Figure 4. Composition of different data objects.58

C. Information Monitoring and Event ResponseFirst, real time value monitoring can be realized via KPIon business objects. Suppose the required tent number is onekey information during an earthquake rescue process. Whenan earthquake happens, the required tent number needs toreported timely from the earthquake location. We can createa KPI based on the RequiredMaterial business object and itsdata service getRequiredTentNumber(). Its real time value isgotten through periodically invoking the data services, andnotified to related users during the earthquake responseperiod.Data changes in KPI can trigger existing serviceintegration changes. Once a new required tent number isreported, an event will be automatically created based on theKPI information and trigger its action defined by ECA rules.The action will trigger service invocation to get arecommended tent dispatch plan.TABLE II.V.IMPLEMENTATIONWe developed a prototype to support and validate theUDSI approach, which is shown in Fig. 5. Fig. 5(a) showsthe tool to support the creation of an atomic data object. Withthis tool, users can first create the head of a nested table todescribe the metadata of a data object. Then required datawill be extracted from the data sources and transformed intoa set of nested relations. Our current implementation cansupport several common data sources, including therelational database, XML, json and HTML. This process hastwo key issues. The first one is how to transform a given datasource (such as HTML, XML, etc.) to the nested relations.The second one is how to let users decide what data shouldbe transformed and how to realize it. The correspondingtechniques can be found in our previous papers [8] [9].Based on the nested relation model, the created atomicdata objects can be easily visualized in a nested table. AsFig.5(b) shows, users may create data services by wrappingcolumns of a data object and choose required operators onthem. The operators can be provided as services. The inputparameters of an operator will be the input parameters of theservice. For example, in Fig.5(b), when we select the citycolumn, then we can choose the filter operators. The operatorneeds users to input the filter value. Here, we input the “࣫Ҁ(Beijing)”. This causes to establish a query service. It willquery all rows in the table where the value of city attributeequals to “࣫Ҁ(Beijing)”.Fig. 5(c) shows our tool to combine multiple businessobjects. The user interface is implemented on Flex [10]. Theworkspace is divided into several regions. Region ķdisplays the data service list. Once a data service is clicked,its example data will be displayed in region ĸ as a nestedtable. Region Ĺ is the current worksheet where theintermediate composition results will be displayed. Users cancompose the services by simple drag the target columns fromregion ĸ to region Ĺ and use appropriate operatorsaccordingly.The KPI and corresponding ECA rules are realized withthe EQL (Esper Query Language) [11]. The service for eachaction is either an existing Web service or a composite Webservice expressed by BPEL. With the predefined ECA rules,the collaboration process can be realized in a more flexibleway. When an ECA rule is triggered, the correspondingservice will be invoked and the users who subscribe thecaptured event will be notified.SAMPLE ECA RULES1 If RequiredMaterial.getAvailableTent() 0, then redTentNumber());2. If Vehicle.getStatus() ‘broken’, then mple ECA rules are listed in Table II. The servicelogic of createDispatchPlan action is as follows. It will firstrank the DPCs based on their distances to the disasterlocation (the nearer, the higher rank), then it dispatch allavailable tents in each repository until the summary tentnumber reach requested number. Detailed service logic candescribed using service composition language like BPEL [7].Another KPI example is vehicle status. If a vehiclereports its status as “broken”, the EO has to respond quickly.The same createDispatchPlan service in Table II can be usedhere to get a new plan based on the material amount in thevehicle.Existing data integration result will reflect changesaffected by new service instantiation reversely. For example,StorageA and StorageB need to decrease their materialamount if more materials are sent out. And new Vehiclebusiness objects are created for delivering the additionalmaterials. CollectiveMaterial business object should reflectthese changes. As shown in Fig. 4, business objectCollectiveMaterial is composed from StorageA, StorageBand Vehicle. Existing changes for business object StorageAand StorageB and new Vehicle business objects can be easilyincorporated into changes of the CollectiveMaterial object.59

Figure 5. The implementation of the prototype.VI.their COREPRO approach, which supports dynamic businessprocess adaptation driven by its data [18]. However, thesestudies mainly focus on how data can help business processmodeling and/or adaptation, and do not consider much onhow to get a collective data results during business processexecution and how the results are affected by businessprocess changes. In contrast, our UDSI approach treats dataand services equally in our business object model, exploreshow to model and compose data and services in a unifiedway, and specially investigates how data and servicecomposition results can influence each other dynamically.RELATED WORKIn current research works, data integration and serviceintegration usually belong to two different research areas.Although they have underlying relations, there still lack apowerful abstraction and practicable approach to coherentlyconnect them.Most data integration work aims to combining dataresiding at different sources, and providing the user with aunified view of these data [12]. In current works, a lot ofattentions have been paid on how to establish a globalschema, which can provide a reconciled and virtual view ofthe underlying sources [13][14][15]. Yet these works do notpay attention on how to enable data integration throughservices, and how to update it when services on the datachanges.Service integration study mainly focuses on combiningthe functionalities of Web services [2][3][4]. However,business data behind these services are hard to be combined.Only servic

data and service integration approach, called UDSI, is proposed for dynamic collaboration. The approach includes business object modeling and composition, key information monitoring and dynamic event response. Via the approach, we can achieve on demand and automatic updates of both data integration results and service integration results.