TDT4250 - Model-driven Development of Information Systems, Autumn 2008 Service-oriented architecture (SOA) 1
SOA definition Service-oriented architecture (SOA) A set of components which can be invoked, and whose interface descriptions can be published, discovered and invoked over a network. (W3C - http://www.w3.org/) Evolution of architectural styles to designing software systems Data-orientation Procedure-orientation Object-orientation (object = data + procedures) Component- and message-orientation (distribution) Service-orientation (loosely coupled, distributed) 2
Web Services as a basis 3
Service-oriented model Service provider Provides software applications for specific needs as services. Service requester A requester could be a human user/application program/another service accessing the service through a desktop or a wireless browser; it could be an application program. Service broker: A service broker provides a searchable repository of service descriptions. Examples of service brokers are UDDI (Universal Description, Discovery, and Integration). 4
From isolated application systems to service-oriented systems SOA (architectural style) Web service (enabling technology) A set of components which can be invoked, and whose interface descriptions can be published and discovered. A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machine-processable format (WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. - W3C Web Services Glossary, http://www.w3.org/tr/ws-gloss/ System A System B System C System D 5
From isolated application systems to service-oriented systems SOA (architectural style) Web service (enabling technology) A set of components which can be invoked, and whose interface descriptions can be published and discovered. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. - W3C Web Services Glossary, http://www.w3.org/tr/ws-gloss/ System A System B System C System D 6
From isolated application systems to service-oriented systems System A System B System C System D 7
From isolated application systems to service-oriented systems System B System C 8
SOA and Web services SOA is the blueprint for IT infrastructure of the future. SOA extends the Web services value proposition by providing guidance on how enterprise IT infrastructures should be designed using services. Four step migration process. 1. 2. 3. 4. Implementing individual Web services: Creating services from tasks contained in new or existing applications Service-oriented integration of business functions Enterprise-wide IT transformation On-demand business transformations 9
Business process management (BPM) services 10
11
9 SOA challenges 1. 2. 3. 4. 5. 6. 7. 8. 9. Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service? Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services? Service domain definition. How should services be grouped together into logical domains? Service location. Where should a service be located within the enterprise? Service orchestration. How are composite services to be orchestrated? Service publication and discovery: How can we find the services we need Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain? Service governance. How will the enterprise exercise governance processes to administer and maintain services? Service messaging standards adoption. How will the enterprise adopt a given standard consistently? 12
Trends TDT4250 - Model-driven Development of Information Systems, Autumn 2009 Merging of Human Workflow and System Orchestration/Process services Integration of Business Rules Engines Support for Event Notification services (publish and subscribe) Integration of model-generated workplaces and role/task-oriented user interfaces, user interaction services, portals, and multi-device interfaces Explicit use of models (Enterprise and System) Enterprise Architecture + SOA Inclusion of semantics towards SESA Semantically-Enabled Service Architectures 13
TDT4250 - Model-driven Development of Information Systems, Autumn 2008 Prescription for a Good BPM Architecture Michael Havey: Essential Business Process Modeling Chapter 2 + a bit from Chapter 7 on Workflow (WfMC) 14
Classification of workflow Production-oriented vs. ad-hoc Most important differentiation, often coincide with Static vs. dynamic Static with separate build time and run time Process model cannot be changed during run-time Dynamic workflow Process-model can be changed and extended during runtime Enterprise vs. workgroup support Do not need to be contradictory Routines might have vague parts Different actors have different rights of change 15
Classification of workflow Derek Miers, Process Product Watch 1) 3 organizational dimensions... 16
WfMC Workflow Management Coalition Tool providers, consultants, etc. Terminology Reference model for workflow-systems, interfaces (APIs) Interoperability Across technical solutions from different vendor Between organizations 17
WfMC Terminology 18
The WfMC s reference model XPDL WAPI WfXML WAPI WAPI 19
WfMC - critique Slow standardization work Focus on production workflow Common, generic process meta-model seem problematic Primarily focus on automation 20
Towards a solution Design externalize knowledge of flow of work select necessary level of formalisation Run map from model to execution language and execute Monitor and administer Human interaction roles and privileges task queues and lists System interaction internal code exectution and external service invokation 21
Havey: BPM Architecture 22
User-role actions Assign system gives task to a particular role or user Claim user takes task from queue assigned to a role Yank user takes task from other user of same role Balk user puts task back into queue 23
System Interaction Receive process receives message from other system Receive-respond process receives message and responds Send process sends message to other system Send-Receive process sends message and waits for respons 24
An example of a BPM runtime data model ProcessDefinition Process Message Variable Activity WorklistTask 25
State of activity/task 26
Standards TDT4250 - Model-driven Development of Information Systems, Autumn 2009 27
Summary TDT4250 - Model-driven Development of Information Systems, Autumn 2009 BPM is replete with competing standards, but a sound architectural approach divides a BPM application into the right parts and selects the appropriate standard for each. The requirement of a BPM application is the ability to design, run, administer, and monitor processes that incorporate system and human interactions. Design, the modeling of processes by business and technical analysts, requires a graphical notation language and a graphical design tool. BPMN is often selected (but is not the only possibility) 28
Summary (continue) BPEL is the most widely adopted executable language, and our chosen notational language, BPMN, includes as part of its specification a detailed mapping to BPEL. BPEL now in version 2.0 Administration and monitoring is crucial for the success of a production application. A special Worklist web service manages human interactions on behalf of the process. Of the 17 major BPM standards, only 3 BPMN, BPEL, and WS-CDL belong in the presented architecture. 29
Summary (continue) System interactions are connections to internal or external system. The best approach is to offer the most common technologies natively and provide an adapter plug-in model for the rest. The BPM integration architecture must include a special web services listener that accepts SOAP requests and injects them into the process engine. The processes of this architecture are those of a particular corporation and are designed from a local perspective. The global perspective of choreography and collaboration helps build protocols with which the company must comply. 30
TDT4250 - Model-driven Development of Information Systems, Autumn 2008 Business Process Management (BPM) and Service Oriented Architecture (SOA) John Krogstie Professor, IDI, NTNU Senior Researcher, SINTEF ICT 31