Process Views with Flows for System Integration: A Service Requirement Approach

1. Process Views with Flows for Heterogeneous and Complex System Integration: A Service Requirement Approach

2. Introduction • B2B Interaction • consists of interoperation and integration with both internal and external enterprise applications • Process View (Workflow views) • a structurally correct subset of a workflow • interactions inter-operate in a gray box mode • providing external access to business processes • Flow • 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

3. Motivation and Objectives • 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

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

5. Conceptual Model of Process View and Flows

6. Control Flows • Control flows specify the execution order of activities which are allowed in the processes • Process logic in a cross-organizational process

7. Data Flows • 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 • many data flow in parallel • control flows are often inadequate, inflexible, or unclear for expressing data exchange sequence.

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

9. Semantic Flows • 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 • stored in a common UDDI directory • heterogeneous ontology and ontology integration problems as future work

10. Exception flow • 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 • require human attention and handling • send alerts to the appropriate personnel

11. Overview of Flows

12. e-Government Integration Case Study • 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). • BorderRecord (id-no, entry-or-exit, place, vehicle, day-of-event) are hold by the Immigration Department. • CrimeRecord (id-no, crime-description, sentence, day-of-event) are hold by the Police. • BankRecord (tax-file-no, bank-no, account-no, transaction, amount, balance, day-of-event) are hold by individual banks.

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

14. Eliciting Flows for Service Provision • 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 pre-conditions 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.

15. Eliciting Flows for Service Provision (cont) • 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 post-condition 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.

16. Flow Analysis and View Formulation • check for missing ones • organize them into process views • similar to data flow analysis • trace messages and transformations • 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

17. Views of the ID Service Process to other Departments

18. HCSI by Service Composition • 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 OutMsg(s, m)  Depend(d, m). Let S denote the set of required services thus found. • For each s S, consider InMsg(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.

19. Mapping between the Conceptual Layers and Technologies

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

21. Graphical XML Representation of a Process View Commen t ed it ed w it h XM L SPY v 200 4 re l . 4 U ( htt p :/ / ww w . xmlsp y . co m ) by zhe sha n p r o c e s s n a m e IntelligenceBureau&CityBan k t a r g e t N a m e s p .. . h tt p :/ / ww w . dickso n - compute r . co m / servic e / WorkflowVie w x m l n s h tt p :/ / schema s . xmlsoa p . or g / w s / 200 3 / 0 3 / busines s - proces s / l n s x m l n s : h tt p :/ / ww w . dickso n - compute r . co m / w sd l / WorkflowVie w s u pp r e ss J o i n .. . ye s p a r t n e r L i n k s p a r t n e r L i n k ( 2 ) n a m e p a r t n e r L i n k T y .. . m y R o l e p a r t n e r R o l e 1 intelligenceBurea u ln s : intelligenceBureauL i in t elligence Se rvic e nkTyp e 2 cityB an k ln s : ci t yBankLink Typ e bankServic e v a r i a b l e s f l o w n a m e contro l - f lo w li n k s r e c e i v e n a m e S t ar t p a r t n e r L i n k intelligenceBurea u p o r t T y p e ini t ialize P T o p e r a t i o n initializ e v a r i a b l e r eque s t c r e a t e I n s t a n c e y e s s o u r c e linkNam e = initialize d i n v o k e ( 4 ) n a m e p a r t n e r L i n k p o r t T y p e o p e r a t i o n i n p u t V a r i a b l e ou t p u t V a r i a b l e t a r g e t s ou r c e 1 IDChec k intelligenceBurea u ln s : readP T rea d re que s t key s t a r g e t linkNam e .. . s ou r c e ( 3 ) li n k N a m e 1 key s - I D - t o - ban k 2 key s - I D - t o - crim e 3 key s - I D - t o - borde r 2 B an k Che c k cityB an k ln s : readP T rea d key s t a r g e t linkNam e .. . s ou r c e ( 1 ) 3 CrimeChec k intelligenceBurea u ln s : readP T rea d key s t a r g e t linkNam e .. . s ou r c e ( 1 ) 4 BorderChec k intelligenceBurea u ln s : readP T rea d s t a r g e t linkNam e .. . s ou r c e ( 1 ) key r e p l y n a m e En d p a r t n e r L i n k intelligenceBurea u p o r t T y p e completeP T o p e r a t i o n complet e v a r i a b l e resul t t a r g e t linkNam e = ban k - en d t a r g e t linkNam e = crim e - en d t a r g e t linkNam e = bo rd e r - en d f l o w nam e = semanti c - fl o w f l o w nam e = dat a - fl o w f l o w nam e = securi t y - fl o w f l o w nam e = exceptio n - fl o w

22. WSDL Generation <definitions> <types> <!-- XML Schema --> </types> <message name=“ViewNFlowFRequest” /> <message name=“ViewNFlowFResponse” />… <portType name=“ViewNActivityMInterface”> <operation name=“ViewNFlowF”> <input message=“ViewNFlowFRequest” /> <output message=“ViewNFlowFResponse” /> </operation> … </portType> … <binding name=“ViewNActivityMBinding” type=“ViewNActivityMInterface”> <soap:binding transport=“http://schemas.xmlsoap.org/soap/http” />… </binding>… <service name=“WfviewN”> <port name=“WfviewNActivityMPort” binding=“WfviewNActivityMBinding”> <soap:address location=“http://dept.gov.hk/ServicesS/ViewN” /> </port> … </service> </definitions> • Process View -> WSDL service • Activity -> WSDL port • Flows -> WSDL operation • Messages -> WSDL bindings

23. 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 … + Port3 - 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 … Basic WSDL for the process view of the ID service to the Customs

24. Integration for the Suspect Investigation Service

25. Data Schema in OWL <owl:Ontology rdf:about="#Identity"> <owl:versionInfo>v 1.00 2003/12/16 22:37:39</owl:versionInfo> <rdfs:comment>An example OWL ontology for Identity</rdfs:comment> ... <owl:Class rdf:ID="DataSchema"> <owl:unionOf rdf:parseType="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:unionOf> </owl:Class> ... </owl:Ontology>

26. Simplified BPEL Code for Semantic Flow <flow name="semantic-flow"> <ontology activityName="IDCheck"> <ontologyRef="http://www.example.org/identity.owl" /> </ontology> <ontology activityName="BankCheck"> <ontologyRef="http://www.example.org/banking.owl" /> </ontology> <ontology activityName="CrimeCheck"> <ontologyRef="http://www.example.org/legal.owl" /> </ontology> <ontology activityName="BorderCheck"> <ontologyRef="http://www.example.org/custom.owl" /> </ontology> … </flow>

27. <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="CrimeRecord" <attributes name="id-no" key="primary"/> <attributes name="crime-description"/> <attributes name="sentence"/> ... </dataset> <dataset name="BorderRecord" <attributes name="id-no" key="primary"/> <attributes name="entry-or-exit"/> <attributes name="place"/> <attributes name="date"/> ... </dataset> </integrate> <integrate name="data-flow-2"> <dataset name="CrimeRecord" <attributes name="id-no" key="primary"/> <attributes name="crime-description"/> <attributes name="sentence"/> ... </dataset> <dataset name="BorderRecord" <attributes name="id-no" key="primary"/> <attributes name="entry-or-exit"/> <attributes name="place"/> <attributes name="date"/> ... </dataset> <dataLinkage name="IDrecord"> <attributes name="id-no" key="foreign"/> <attributes name="tax-file-no" key=foriegn"/> <dataLinkage/> <dataset name="BankRecord" <attributes name="tax-file-no" key="primary"/> <attributes name="bank-no"/> <attributes name="account-no"/> <attributes name="transaction"/> ... </dataset> </integrate> </flow> BPEL Assertions for Data Flows

28. Security Token Example <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:wsse=http://schemas.xmlsoap.org/ws/2002/04/secext xmlns:wii="http://schemas.workflow.org/wii/2003/12/authentication"> <S:Header> ... <wsse:Security> <wsse:UsernameToken> <wsse:Username>93856543</wsse:Username> <wsse:Password>3875</wsse:Password> <wii:SubjectName>Sherlock Holmes</wii:SubjectName> <wii:SubjectDepartment>Police</wii:SubjectLocation> </wsse:UsernameToken> </wsse:Security> ... </S:Header> ... </S:Envelope>

29. <flow name="security-flow"> <sessionStart>generateSecurityToken</sessionStart> <clearance activityName="IDCheck"> <securityToken required="True"> <tokenType>SAML</tokenType> <securityToken/> </clearance> <clearance activityName="BankCheck"> <securityToken required="True"> <tokenType>SAML</tokenType> <securityToken/> </clearance> <clearance activityName="CrimeCheck"> <securityToken required="True"> <tokenType>SAML</tokenType> <securityToken/> </clearance> <clearance activityName="BorderCheck" <securityToken required="True"> <tokenType>SAML</tokenType> <securityToken/> </clearance> <sessionEnd>revokeSecurityToken</sessionEnd> </flow> Simplified BPEL Code for Security Flows

30. Exception Flows and SOAP Fault

31. BPEL Assertions for Exception Flow <flow name="exception-flow"> <exceptionHandling name="rule-1"> <event>anyActivitySpecificException</event> <condition>affectDataIntegration</condition> <action>remedyOrforwardRecoveryProcedure</action> </exceptionHandling> <exceptionHandling name="rule-2"> <event>anyCrossActivityException</event> <condition>affectDataLinkage</condition> <action>backwardRecoveryProcedure</action> </exceptionHandling> <exceptionHandlingDefault> <action>abortControlFlow</action> </exceptionHandlingDefault> </flow>

32. 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 B2B interaction • Especially useful for large-scale information systems

33. Future Work • Focus on the scalability and reusability of BPEL4WS • Wait for a WFMS to support BPEL4WS effectively and efficiently • Study focus on semantic help on exception handling • Privacy-flow • Conflicts between flows • Alerts and flow urgency • Requirements engineering