1 / 33

Introduction

Process Views with Flows for Heterogeneous and Complex System Integration: A Service Requirement Approach. Introduction. B2B Interaction consists of interoperation and integration with both internal and external enterprise applications Process View (Workflow views)

mairi
Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related