Process Views with Flows for Heterogeneous and Complex

Process Views with Flows for Heterogeneous and Complex System Integration: A Service Requirement Approach Dickson K. W. CHIU Zhe SHAN, Qing LI Senior Member, IEEE City University of Hong Kong kwchiu@acm. org, dicksonchiu@ieee. org zenga@cs. cityu. edu. hk itqli@cityu. edu. hk Patrick C. K. HUNG S. C. Cheung Faculty of Business and Information Technology, University of Ontario Institute of Technology Patrick. Hung@uoit. ca Process Views and flow Dept. of Computer Science Hong Kong University of Science & Technology scc@cs. ust. hk 1

Introduction n B 2 B Interaction n n Process View (Workflow views) n n consists of interoperation and integration with both internal and external enterprise applications a structurally correct subset of a workflow interactions inter-operate in a gray box mode providing external access to business processes Flow n n n a directed relationship that transmits events from a source activity to a sink activity. partition activity relationships into control-flows, data-flows, semantic-flows, exception-flows, and security-flows workflow specification is a set of activities connected by these flows Process Views and flow 2

Motivation and Objectives n n n Systematic design of interactions Encapsulated in process views But workflows are too complex for large-scale IS Proposal: consider component flows Different flows: separation of concerns Process Views and flow 3

Project Background n Process View (implementation and requirement engineering immature) n D. K. W. Chiu et al. Information Technology and Management, 5(3/4): 221 n n Process View Implementations with Web Services n n Z. Shan, D. K. W. Chiu and Q. Li. Systematic Interaction Management in a Workflow View Based Business-to-business Process Engine, HICSS 38, Jan 2005 (best paper nomination). Flows n n 250, 2004. D. K. W. Chiu et al. Distributed and Parallel Databases 12(2 -3): 193 -216, 2002. P. C. K. Hung and Dickson K. W. Chiu. Developing Workflow-based Information Integration (WII) with Exception Support in a Web Services Environment, HICSS 37 Preliminary version n D. K. W. Chiu, Z. Shan, P. C. K. Hung and Q. Li. Designing Workflow Views with Flows for Large-scale Business-to-Business Information Systems, 5 th VLDB Workshop on Technologies for E-Services (TES-04), Toronto, Canada, Aug 2004. Process Views and flow 4

Conceptual Model of Process View and Flows Process Views and flow 5

Control Flows n n Control flows specify the execution order of activities which are allowed in the processes Process logic in a cross-organizational process Process Views and flow 6

Data Flows n n n define the flow of specific data or dataset required by a process. may often be almost the same as the control flows in processes that involve only simple data exchange In HCSI n n many data flow in parallel control flows are often inadequate, inflexible, or unclear for expressing data exchange sequence. Process Views and flow 7

Security Flows n n define the flow of security control information, e. g. , authentication creation, exchange, and revocation of security tokens n n n security policy n n n to implement security policies represent a collection of claims (i. e. , user ID information) like name, identity, privilege, and capability authentication and authorization set of laws, rules, and practices regulate how a flow prevents information and resources from being misused support the principle of single-sign-on n delegation or propagation should be well designed and described Process Views and flow 8

Semantic Flows n n Define the semantic relationship among the information used in the process execution Abstract the main concepts and describe their dependence in a more precise way. Such data schema can be represented in OWL as ontology. Assume partner organizations have an agreed semantics of the information exchanged n n stored in a common UDDI directory heterogeneous ontology and ontology integration problems as future work Process Views and flow 9

Exception flow n n n convey the occurrence of such exceptions from the service provider to the requestor trigger the corresponding exception handler processes pre-defined at the requestor side unexpected exceptions n n require human attention and handling send alerts to the appropriate personnel Process Views and flow 10

Overview of Flows Process Views and flow 11

e-Government Integration Case Study n n IDrecord (id-no, tax-file-no, name, sex, date-of-birth, area-code, phone-no, address, postal-code) are hold by the Immigration Department (in the case for Hong Kong). Border. Record (id-no, entry-or-exit, place, vehicle, day -of-event) are hold by the Immigration Department. Crime. Record (id-no, crime-description, sentence, dayof-event) are hold by the Police. Bank. Record (tax-file-no, bank-no, account-no, transaction, amount, balance, day-of-event) are hold by individual banks. Process Views and flow 12

Methodology Overview n Basic Service Provision n Elicit the flows required for service provision Analyze flows and formulate view for different types of users HCSI by composing basic services Process Views and flow 13

Eliciting Flows for Service Provision n n n Determine the main processes (e. g. , ID service process and border record service process) that are offered to partners as services. For each of the main service process, determine the sub-services, which includes different service options (e. g. , single basic ID information, single extend ID information, and batch ID information) and supporting services (e. g. , approvals). Data services provide information and deal with data flow; control services provide procedure automation and deal with control flow; security services deal with security check; exceptions services deal with exception situations. Usually, data or control services are the main ones to be considered first. For each service, determine the expected requestors and under which preconditions they are allowed to access. These are the incoming flows. If any of the pre-conditions is related to security, formulate security services that deal with security flow for the checking. A successful security check will become the required pre-condition. Relate the pre-conditions with any other service constraints, such as limitations of the request parameters. Process Views and flow 14

Eliciting Flows for Service Provision (cont) n n n n If any security check is related to pre-approval procedures, formulate control supporting services that deals with the control flow of the approval activity. A successful approval activity will initiate a security flow (via an internal token creation service) to grant a security token to the requestor. For each service, determine the possible outcomes. For each of the outcome, specify the post-conditions and whether any messages should be sent back to the requestor, any other parties, and/or any internal services. These are the outgoing flows. If the outcome message is targeted to any internal services, make sure that such service exist, the message is appropriate, and the postcondition of the former service matches with the pre-condition of the latter service. For each of the services, determine any possible abnormal outcome. For each abnormal outcome, forward the exception to an exception services (such as an exception manager) that can initiate exception flow towards one or more internal or external targets. Consider also the provision of exception handler services for handling internal and/or external exception flows. Process Views and flow 15

Flow Analysis and View Formulation n n check for missing ones organize them into process views similar to data flow analysis trace messages and transformations n n n Identification of Incoming Messages Identification of Outgoing Messages Identification of Immediate Responses of Incoming Messages Identification of Data and Flow Relevancy Identification of Independent Incoming or Outgoing Message Pairs View Tabulation Process Views and flow 16

Views of the ID Service Process to other Departments Department View Composed of the Flows (numbered in Table I) Police i 1 ->o 1, i 1 ->(o 2 ->)o 18, i 1 ->o 3, i 5 ->o 11, i 5 ->(o 12 ->i 13 ->)o 22, i 8 -> o 16, i 8 -> (o 17 ->i 15)->o 24, i 15 ->o 25 Customs i 3 ->o 7, i 3 ->(o 8 ->i 10 ->)o 19, i 6 -> o 13, i 6 ->(o 14 ->i 14 ->)o 23, i 8 ->o 16, i 8 ->(o 17 ->i 15 ->)o 24, i 15 ->o 25 Other Govt. Users i 4 ->o 9, i 4 ->(o 10 ->)o 19, i 8 ->o 16, i 8 ->(o 17 ->i 15 ->)o 24, i 15 ->o 25 i 8 ->(o 17 ->i 15 ->)o 25, Central IT Security Center i 7 ->(o 15 ->i 17 ->)o 25, i 19 ->o 25, Process Views and flow 17

HCSI by Service Composition 1. 2. 3. 4. 5. 6. 7. Determine the set of data items D required for the integration. Based on the services registered in the common UDDI directory, determine the service and organization from which those data items can be obtained from. That is, for each item d D, find service s such that Out. Msg(s, m) Depend(d, m). Let S denote the set of required services thus found. For each s S, consider In. Msg(s, n), the request n required by service s. For each d’ in Depend(d’, n), if d’ D, add d’ into D. Re-iterate from step 1 until no more items can be added to D, i. e. , all the transitively dependent data requirements D as well as the set of services S providing them are found. For each s S, consider the pre-condition requirements of the flows. Determine the extra security flow (such as approved security token) and control flow (such as approval applications) required. Re-iterate from Step 1 if extra data items are required or from Step 4 if only extra control and security services are required. Determine any relevant exception flows that could occur and design handler activities / services if necessary. Implement the internal process for the integration of the control, data, security, (semantic, ) and exception flows. Now, the new service process is ready. Design process views of this new service process for other organizations, according to the methodology discussed in the previous sub-sections. Process Views and flow 18

Mapping between the Conceptual Layers and Technologies Process Views and flow 19

System Architecture Partner Organizations … Public UDDI Directory System Integration Flows Web Services Interface Interaction Manager Flow & View Editor View Runtime Manager Flow & View Definitions Process View Instances Flow Manager Interaction Monitor Interaction Log Process View Engine Process Executor Process Definitions Process Editor Process Views and flow Process Instances Exception Manager Internal Process Engine 20

Graphical XML Representation of a Process View Comment process editedwith XMLSPYv 2004 rel. 4 U (http: //www. xmlspy. com) by zheshan n ame Intelligence. Bureau&City. Ban k t arget. Namesp. . . http: //www. dickson-computer. com/service/Workflow. Vie w xmlns http: //schemas. xmlsoa p. org/ws/2003/03/business-process/ xmlns: lns http: //www. dickson-computer. com /wsdl/Workflow. View supp r ess Join. . . yes partner. Link (2) na me part ner. Li nk. Ty. . . my Ro l e 1 intelligence. Burea u lns: intelligence. Bureau. L i intelligence. Service nk. Type 2 city. Bank lns: city. Bank. Link Type vari abl es fl ow na me control-flow li n ks receive na me Start partner. Link intelligence. Burea u port. Type initialize. PT op erat ion initialize va r i a b l e request create. I nstance yes source link. Name=initialized invoke (4) na me partner. Link port Type 1 IDCheck intelligence. Burea u lns: read. PT part ner Rol e bank. Servic e operat ion read i nput. Var iab le request ou tput Variable keys target link. Name. . . sou rce (3) li nk Name 1 keys-ID-to-bank 2 keys-ID-to-crime 3 keys-ID-to-border 2 Bank. Check 3 Crime. Check 4 Border. Chec k city. Bank intelligence. Burea u lns: read. PT read keys target link. Name. . . sou rce (1) reply na me End partner. Link intelligence. Burea u port. Type complete. P T op erat ion complete va r i a b l e result target link. Name=bank-end target link. Name=crime-end target link. Name=border-end fl ow flow name=semantic-flow name=data-flow name=security-flow name=exception-flow Process Views and flow 21

WSDL Generation n n Process View -> WSDL service Activity -> WSDL port Flows -> WSDL operation Messages -> WSDL bindings Process Views and flow <definitions> <types> <!-- XML Schema --> </types> <message name=“View. NFlow. FRequest” /> <message name=“View. NFlow. FResponse” />… <port. Type name=“View. NActivity. MInterface”> <operation name=“View. NFlow. F”> <input message=“View. NFlow. FRequest” /> <output message=“View. NFlow. FResponse” /> </operation> … </port. Type> … <binding name=“View. NActivity. MBinding” type=“View. NActivity. MInterface”> <soap: binding transport=“http: //schemas. xmlsoap. org/soap/http” />… </binding>… <service name=“Wfview. N”> <port name=“Wfview. NActivity. MPort” binding=“Wfview. NActivity. MBinding”> <soap: address location=“http: //dept. gov. hk/Services. S/View. N” /> </port> … </service> 22 </definitions>

Basic WSDL for the process view of the ID service to the Customs Name: ID Check Service Location/Provider: Immigration Department <!-- Control Flow --!> +Port 1 - Input: Batch ID Approval Request * User Name * User Organization * Suspect Names * Request Reason - Output: Approval Message/Rejection Message * Request Status (Approved/Rejected) * Security Token (if approved) <!-- Data Flow --!> + Port 2 - Input: Single ID Request * Suspect Name * Suspect Description - Output: Basic ID Information/Error Message * Suspect ID * Suspect Birthday * Suspect Phone Number * Suspect Address … Process Views and flow + Port 3 - Input: Single Extended ID Request … - Output: Extended ID Information/Error Message… + Port 4 - Input: Batch ID Request … + Output: Batch Suspect Analysis Report (with ID information) … <!—Security Flow --!> + Port 5 - Input: Any Government Department Security Token - Output: Accept Message/Rejection Message + Port 6 - Output: Batch ID Token + Port 7 - Input: Batch ID Token - Output: Accept Message / Rejection Message… <!—Exception Flow --!> + Port 8 - Output: ID Not Found Exception + Port 9 - Output: Analysis Error Exception + Port 10 - Output: Token Invalid Exception/Security Alert Exception … 23

Integration for the Suspect Investigation Service Process Views and flow 24

Data Schema in OWL <owl: Ontology rdf: about="#Identity"> <owl: version. Info>v 1. 00 2003/12/16 22: 37: 39</owl: version. Info> <rdfs: comment>An example OWL ontology for Identity</rdfs: comment>. . . <owl: Class rdf: ID="Data. Schema"> <owl: union. Of rdf: parse. Type="Collection"> <owl: Class rdf: about="#id-no"/> <owl: Class rdf: about="#name"/> <owl: Class rdf: about="#sex"/> <owl: Class rdf: about="#date-of-birth"/> <owl: Class rdf: about="#area-code"/> <owl: Class rdf: about="#phone-no"/> <owl: Class rdf: about="#address"/> <owl: Class rdf: about="#postal-code"/> <owl: Class rdf: about="#tax-file-no"/> </owl: union. Of> </owl: Class>. . . </owl: Ontology> Process Views and flow 25

Simplified BPEL Code for Semantic Flow <flow name="semantic-flow"> <ontology activity. Name="IDCheck"> <ontology. Ref="http: //www. example. org/identity. owl" /> </ontology> <ontology activity. Name="Bank. Check"> <ontology. Ref="http: //www. example. org/banking. owl" /> </ontology> <ontology activity. Name="Crime. Check"> <ontology. Ref="http: //www. example. org/legal. owl" /> </ontology> <ontology activity. Name="Border. Check"> <ontology. Ref="http: //www. example. org/custom. owl" /> </ontology> … </flow> Process Views and flow 26

BPEL Assertions for Data Flows <flow name="data-flows"> <integrate name="data-flow-1"> <dataset name="IDrecord"> <attributes name=" id-no" key="primary"/> <attributes name="sex"/> <attributes name="age"/>. . . </dataset> <dataset name="Crime. Record" <attributes name=" id-no" key="primary"/> <attributes name="crime-description"/> <attributes name="sentence"/>. . . </dataset> <dataset name="Border. Record" <attributes name=" id-no" key="primary"/> <attributes name="entry-or-exit"/> <attributes name="place"/> <attributes name="date"/>. . . </dataset> </integrate> Process Views and flow <integrate name="data-flow-2"> <dataset name="Crime. Record" <attributes name=" id-no" key="primary"/> <attributes name="crime-description"/> <attributes name="sentence"/>. . . </dataset> <dataset name="Border. Record" <attributes name=" id-no" key="primary"/> <attributes name="entry-or-exit"/> <attributes name="place"/> <attributes name="date"/>. . . </dataset> <data. Linkage name="IDrecord"> <attributes name=" id-no" key="foreign"/> <attributes name=" tax-file-no" key=foriegn"/> <data. Linkage/> <dataset name="Bank. Record" <attributes name=" tax-file-no" key="primary"/> <attributes name="bank-no"/> <attributes name="account-no"/> <attributes name="transaction"/>. . . </dataset> </integrate> </flow> 27

Security Token Example <S: Envelope xmlns: S="http: //www. w 3. org/2001/12/soap-envelope" xmlns: wsse=http: //schemas. xmlsoap. org/ws/2002/04/secext xmlns: wii="http: //schemas. workflow. org/wii/2003/12/authenticatio n"> <S: Header>. . . <wsse: Security> <wsse: Username. Token> <wsse: Username>93856543</wsse: Username> <wsse: Password>3875</wsse: Password> <wii: Subject. Name>Sherlock Holmes</wii: Subject. Name> <wii: Subject. Department>Police</wii: Subject. Location> </wsse: Username. Token> </wsse: Security>. . . </S: Header>. . . </S: Envelope> Process Views and flow 28

Simplified BPEL Code for Security Flows <flow name="security-flow"> <session. Start>generate. Security. Token </session. Start> <clearance activity. Name="IDCheck"> <security. Token required="True"> <token. Type>SAML</token. Type> <security. Token/> </clearance> <clearance activity. Name="Bank. Check"> <security. Token required="True"> <token. Type>SAML</token. Type> <security. Token/> </clearance> Process Views and flow <clearance activity. Name="Crime. Check"> <security. Token required="True"> <token. Type>SAML</token. Type> <security. Token/> </clearance> <clearance activity. Name="Border. Check" <security. Token required="True"> <token. Type>SAML</token. Type> <security. Token/> </clearance> <session. End>revoke. Security. Token</se ssion. End> </flow> 29

Exception Flows and SOAP Fault Process Views and flow 30

BPEL Assertions for Exception Flow <flow name="exception-flow"> <exception. Handling name="rule-1"> <event>any. Activity. Specific. Exception</event> <condition>affect. Data. Integration</condition> <action>remedy. Orforward. Recovery. Procedure</action> </exception. Handling> <exception. Handling name="rule-2"> <event>any. Cross. Activity. Exception</event> <condition>affect. Data. Linkage</condition> <action>backward. Recovery. Procedure</action> </exception. Handling> <exception. Handling. Default> <action>abort. Control. Flow</action> </exception. Handling. Default> </flow> Process Views and flow 31

Conclusions § § New perspective of process views through a subset of various flows of original workflow Process views are now enriched with the support of data flow, semantics flow, exception flow, and security flow Systematic design of process views for better B 2 B interaction Especially useful for large-scale information systems Process Views and flow 32

Future Work n n n n Focus on the scalability and reusability of BPEL 4 WS Wait for a WFMS to support BPEL 4 WS effectively and efficiently Study focus on semantic help on exception handling Privacy-flow Conflicts between flows Alerts and flow urgency Requirements engineering Process Views and flow 33