Service-Oriented Integration

(1)

Service-Oriented Integration

Goldschmidt, Balázs

Simon, Balázs

Szeberényi, Imre

(2)

Service-Oriented Integration

írta Goldschmidt, Balázs, Simon, Balázs, és Szeberényi, Imre Publication date 2015

(3)

Tartalom

Service-Oriented Integration ... 1

1. 1 Service Oriented Architecture ... 1

1.1. Outline ... 1

1.2. Topic of the course ... 1

1.3. System integration: within an enterprise ... 1

1.4. System integration: among government agencies ... 1

1.5. Task ... 2

1.6. Requirements ... 2

1.7. Service Oriented Architecture ... 2

1.8. Service ... 3

1.9. System integration: within an enterprise ... 3

1.10. System integration: among government agencies ... 4

1.11. Technology for implementing services ... 4

1.12. Definition of SOA ... 4

1.13. Official definition of SOA ... 5

1.19. Concepts in the definitions ... 6

1.20. SOA myths and facts (Microsoft) ... 6

1.21. SOA myths and facts (Microsoft) ... 7

1.22. Principles of SOA (by Web Services Journal) ... 7

1.23. Principles of SOA (by Web Services Journal) ... 7

1.24. Best definition of SOA ... 7

1.25. Requirements of software systems ... 7

1.27. System Qualities ... 8

1.28. Run-time Qualities ... 8

1.29. Run-time Qualities ... 8

1.30. Design Qualities ... 8

1.31. User Qualities ... 9

1.32. System integration topologies ... 9

1.33. Typical topologies ... 9

1.34. Direct communication ... 9

1.35. Bus topology (indirect communication) ... 10

2. 2 Web services: WSDL ... 10

2.1. Outline ... 10

2.2. Web service ... 11

2.4. Web services ... 11

2.5. WSDL (Web-Services Description Language) ... 12

2.6. WSDL ... 12

2.7. WSDL 1.1 ... 12

2.8. WSDL 1.1: types in XSD ... 14

2.9. WSDL 1.1: abstract part ... 14

2.10. WSDL 1.1: concrete part ... 14

2.11. WSDL 1.1 MEP ... 15

2.12. Equivalence of two interfaces ... 15

2.13. WSDL 1.1 summary ... 15

2.14. WSDL 2.0 ... 16

2.15. WSDL 2.0 summary ... 16

2.16. JAX-WS ... 17

2.17. JAX-WS ... 17

(4)

2.19. JAX-WS sample: interface with annotations ... 17

2.20. JAX-WS sample: implementation ... 18

2.21. JAX-WS sample: client ... 18

2.22. WCF ... 18

2.23. WCF ... 18

2.24. WCF sample: interface ... 19

2.25. WCF sample: interface with Attributes ... 19

2.26. WCF sample: implementation ... 19

2.27. WCF sample: client ... 19

2.28. References ... 20

3. 3 Web services: SOAP ... 20

3.1. Outline ... 20

3.4. Web services ... 21

3.5. SOAP (Simple Object Access Protocol) ... 21

3.6. SOAP history ... 21

3.7. SOAP ... 22

3.8. SOAP envelope ... 22

3.9. SOAP 1.1 ... 22

3.10. SOAP 1.2 ... 23

3.11. SOAP binding style ... 23

3.12. RPC/encoded ... 23

3.13. RPC/literal ... 24

3.14. Document/literal ... 24

3.15. Document/wrapped ... 24

3.16. WSDL 1.1 - SOAP 1.1 binding ... 25

3.17. WSDL 1.1 - SOAP 1.2 binding ... 25

3.18. JAXB ... 25

3.19. JAXB ... 26

3.20. JAXB ... 26

3.21. JAXB ... 26

3.22. Atomic types ... 27

3.23. Custom bindings ... 27

3.24. XML Schema support ... 27

3.25. Packages and namespaces ... 28

3.26. JAXB sample ... 28

3.27. JAXB sample: list ... 28

3.28. WCF DataContract ... 29

3.29. WCF DataContract ... 29

3.30. Atomic types ... 29

3.31. Packages and namespaces ... 29

3.32. WCF DataContract sample ... 30

3.33. WCF DataContract sample: list ... 30

4. 4 WS- standards ... 31

4.1. Outline ... 31

4.2. Integration requirements ... 31

4.3. Integration within a company ... 31

4.4. e-Gov integration ... 31

4.6. WS- standards ... 32

4.7. Web service standards ... 32

4.8. Messaging ... 32

4.9. Security ... 33

4.10. WS-Federation sample ... 34

4.11. Reliable messaging ... 34

4.12. WS-ReliableMessaging ... 34

4.13. Transactions ... 35

4.14. Metadata ... 36

(5)

4.15. WS- standards ... 36

4.16. Asymmetric-key cryptography ... 37

4.17. Asymmetric-key cryptography ... 37

4.18. Asymmetric-key cryprography ... 37

4.19. X.509 certificate ... 38

4.20. X.509 certificate: public key ... 38

4.21. X.509 certificate: private key ... 39

4.22. Certificate hierarchy ... 41

4.23. XML encryption, XML digital signature ... 41

4.24. XML digital signature ... 42

4.25. Steps of XML digital signature ... 42

4.26. 1. Collecting resources to sign ... 42

4.27. 2. Optional transformations ... 42

4.28. 3. Hash (message digest) ... 43

4.29. 4. Collecting references ... 43

4.30. 5. Canonicalization ... 43

4.31. 6. Signing ... 44

4.32. 7. Adding key information ... 44

4.33. 8. Adding optional information ... 44

4.34. 9. Packaging XML items ... 45

4.35. Digital signature summary ... 45

4.36. Result of the digital signature ... 45

4.37. Checking digital signature ... 46

4.38. Checking digital signature ... 46

4.39. XML encryption ... 46

4.40. Steps of XML encryption ... 47

4.41. Select encryption algorithm ... 47

4.42. Select/retrieve encryption key ... 47

4.43. Encryption/exchange of keys ... 47

4.44. Data to encrypt ... 48

4.45. XML encryption summary ... 48

4.46. Encryption process ... 48

4.47. Steps of decryption ... 49

4.48. Decryption summary ... 49

4.49. X.509. certificates in Windows and in Java ... 49

4.50. Certificate hierarchy ... 49

4.51. Windows certificate store ... 50

4.52. Java certificate store ... 50

5. 5 Representational State Transfer (REST) ... 51

5.1. Outline ... 51

5.2. HTTP ... 51

5.3. HTTP GET ... 51

5.4. HTTP GET ... 51

5.5. HTTP POST ... 52

5.6. REST ... 52

5.7. REST ... 52

5.8. Goals of REST ... 52

5.9. REST principles ... 53

5.10. Identifying resources ... 53

5.11. Identifying resources ... 53

5.12. Linking things ... 54

5.13. Processing URLs ... 54

5.14. Standard operations on resources ... 54

5.15. Standard operations ... 54

5.16. Multiple data representation ... 55

5.17. Stateless communication ... 55

5.18. JAX-RS ... 55

5.19. JAX-RS ... 55

(6)

5.21. Calculator sample ... 56

5.22. Parameters ... 56

5.23. Param samples ... 57

5.24. Result ... 57

5.25. MessageBodyWriter ... 58

5.26. MessageBodyWriter sample ... 58

5.29. Calculator sample revisited ... 59

5.30. HTTP methods, mime-types ... 59

5.31. XML and JSON ... 60

5.32. XML and JSON sample ... 60

5.33. XML and JSON sample ... 60

5.34. XML result ... 61

5.35. JSON result ... 61

5.36. REST client ... 61

5.37. Jersey client ... 62

5.38. Jersey client ... 62

5.39. Jersey client main program ... 62

5.40. WCF ... 62

5.41. WCF for REST ... 63

6. 6 Design and development guidelines for web services ... 63

6.1. Outline ... 63

6.2. WSDL version ... 64

6.3. SOAP version ... 64

6.4. SOAP encoding ... 64

6.5. XSD and WSDL ... 64

6.6. XSD constraints ... 65

6.7. Common types and common code ... 65

6.8. Top-down or bottom-up development ... 65

6.9. API ... 66

6.10. Interface design guidelines ... 66

6.11. Top-down design ... 66

6.12. Exceptions ... 66

6.13. Synchronous and asynchronous calls ... 67

6.14. Stateless service ... 67

6.15. Avoid implementation-specific parameters ... 67

6.16. Granularity ... 67

6.17. Overloading ... 68

6.18. Responsibilities ... 68

6.19. Paging large lists ... 68

6.20. Changes ... 68

7. 7 Business Process Execution Language (BPEL) ... 68

7.1. Outline ... 68

7.2. Business processes ... 68

7.4. Business process ... 69

7.6. Designing business processes ... 69

7.7. Automating business processes ... 70

7.8. Typical business process patterns ... 70

7.9. Basic Control Flow Patterns ... 70

7.10. Business Process Execution Language (BPEL) ... 71

7.11. BPEL ... 71

7.12. BPEL process ... 71

7.13. BPEL 1.1 structure ... 71

(7)

7.17. BPEL 2.0 ... 73

7.18. import ... 74

7.19. BPEL 2.0 ... 74

7.20. partnerLinks ... 75

7.21. partnerLinks ... 75

7.22. Sample ... 76

7.23. BPEL 2.0 ... 76

7.24. variables ... 77

7.25. BPEL 2.0 ... 77

7.26. Simple activities ... 78

7.27. Sample ... 78

7.28. Simple activities ... 79

7.29. Structured activities ... 79

7.30. flow ... 80

7.31. scope ... 81

7.32. BPEL 2.0 ... 82

7.33. Correlation ... 82

7.34. property and propertyAlias ... 83

7.35. correlationSets ... 83

7.36. BPEL 2.0 ... 83

7.37. faultHandlers ... 84

7.38. BPEL 2.0 ... 84

7.39. eventHandlers ... 85

7.40. BPEL 2.0 ... 85

7.41. compensationHandlers ... 86

7.42. Compensation sample ... 86

8. 8 Business Process Modeling Notation (BPMN) ... 87

8.1. Outline ... 87

8.2. Business Process Modeling Notation (BPMN) ... 87

8.3. BPMN ... 87

8.4. BPMN parts ... 87

8.5. Participants ... 88

8.6. Participants ... 88

8.7. Activities ... 88

8.10. Events ... 89

8.11. Gateways ... 90

8.12. Connections ... 91

8.13. Artifacts ... 91

8.14. Sample ... 92

8.15. B2B sample ... 92

8.16. Complex sample ... 93

8.17. BPMN and BPEL ... 93

8.18. Concepts ... 93

8.19. Concepts ... 94

8.20. BPM Hourglass ... 94

8.21. BPMN and BPEL ... 94

8.22. BPMN BPEL problem ... 95

8.23. Rewritten manually using links: unmaintainable ... 95

8.24. Automatic conversion causes redundancy ... 95

9. 9 Enterprise Service Bus ... 96

9.1. Outline ... 96

9.2. Defining the ESB ... 96

9.3. Bus topology (indirect communication) ... 96

9.4. Enterprise Service Bus (ESB) ... 96

9.5. ESB ... 97

(8)

9.7. IBM ... 97

9.8. Oracle ... 97

9.9. Oracle ... 97

9.10. JBoss ... 98

9.11. FuseSource ... 98

9.12. SearchSOA ... 98

9.13. MuleSoft ... 99

9.14. Wikipedia ... 99

9.15. Characteristics of an ESB ... 99

9.16. Common points in the definitions of the ESB ... 99

9.17. Capabilities of an ESB ... 99

10. 10 SOA Frameworks ... 101

10.1. Outline ... 101

10.2. Web Services Frameworks ... 101

10.3. Web Services Frameworks ... 101

10.4. Microsoft ... 101

10.5. IBM ... 102

10.6. Oracle ... 102

10.7. RedHat ... 102

10.8. Comparison ... 102

10.9. SOA Frameworks with ESB and BPEL/BPMN ... 103

10.10. SOA Frameworks ... 103

10.11. Microsoft BizTalk architecture ... 103

10.12. IBM: WebSphere Architecture ... 103

10.13. Oracle: SOA Suite Architecture ... 104

10.14. RedHat: JBoss ESB Architecture ... 104

10.15. Comparison ... 105

11. 11 Model Driven Development ... 105

11.1. Outline ... 105

11.2. Modeling framework ... 105

11.3. Motivation ... 106

11.4. Goal ... 106

11.5. Tools ... 106

11.6. Tools' capabilities ... 106

11.7. Architecture of such a framework ... 107

11.8. UML Profile ... 107

11.9. UML profile ... 107

11.10. XSD profile ... 107

11.11. BPEL profile ... 108

11.12. UML Model ... 109

11.13. Namespaces, packages: UML ... 109

11.14. Namespaces, packages : XSD ... 110

11.15. Namespaces, packages : WSDL ... 110

11.16. Namespaces, packages : WCF ... 110

11.17. Namespaces, packages : JAX-WS ... 111

11.18. Custom types: UML ... 111

11.19. Custom types: XSD ... 112

11.20. Custom types: WCF ... 112

11.21. Custom types: JAX-WS (JAXB) ... 113

11.22. Contract: UML ... 113

11.23. Contract: XSD (2) ... 114

11.24. Contract: WCF ... 115

11.25. Contract: JAX-WS ... 115

11.26. Fault: UML ... 116

11.27. Fault: XSD (2) ... 116

11.28. Fault: WCF (1) ... 117

11.29. Fault: WCF (2) ... 117

(9)

11.30. Fault: JAX-WS (1) ... 118

11.31. Binding: UML ... 119

11.32. Service: UML ... 119

12. 12 SOA project management ... 121

12.1. Outline ... 121

12.2. Project management ... 121

12.3. Project ... 121

12.4. Project management ... 122

12.5. SOA Projects ... 122

12.6. Specific requirements ... 122

12.7. Consequences ... 123

12.8. SOA Roadmap ... 123

12.9. Roadmap ... 123

12.10. Zachman framework ... 123

12.11. Evaluating Zachman ... 124

12.12. Gartner EA Process Model ... 124

12.13. ZapThink's SOA Roadmap ... 125

12.14. Simplified roadmap ... 125

12.15. SOA Maturity ... 126

12.16. Business Process Interoperability Maturity ... 126

12.17. BPIM Factors ... 126

12.18. Maturity levels ... 127

12.19. Maturity levels ... 127

12.20. Application ... 128

12.21. Microsoft SOA Maturity Model ... 129

12.22. Microsoft SOA Maturity Model ... 129

12.23. Gartner Assessment Framework ... 130

(10)

(11)

Service-Oriented Integration

1. 1 Service Oriented Architecture

1.1. Outline

• Topic of the course

• Defining SOA

• Requirements of software systems

• Integration topologies

1.2. Topic of the course

System integration:

"Putting together a bunch of junk made by other people"

- Randy Waterhouse

(Neil Stephenson: Cryptonomicon)

1.3. System integration: within an enterprise

1.4. System integration: among government agencies

(12)

1.5. Task

• Communication between applications

• Different programming languages

• Different operating systems

• Different software vendors

• Legacy systems

• Business processes

• Integration

1.6. Requirements

• Simple

• Standardized

• Independent of programming languages and operating systems

• Well supported and widespread technology

• Middleware aspects:

• reliable message delivery

• encryption, digital signature

• transaction handling

• Solution: Service Oriented Architecture

1.7. Service Oriented Architecture

"SOAs are like snowflakes - no two are alike."

David Linthicum

(13)

1.8. Service

• Basic building block of the architecture

• Publishes a resource or capability

• Has a well defined and standard interface

• Hides implementation details

• Should be a very thin layer

• Can wrap legacy applications

• Good design is essential:

• published functionality

• appropriate granularity

• reuse

1.9. System integration: within an enterprise

(14)

1.10. System integration: among government agencies

1.11. Technology for implementing services

• RPC (Remote Procedure Call)

• RMI (Remote Method Invocation)

• CORBA (Common Object Request Broker Adapter)

• DCOM (Distributed COM)

• Web services: everything is based on XML

• protocol: SOAP

• interface: WSDL

• business processes: BPEL

• REST (REpresentational State Transfer)

• ...

1.12. Definition of SOA

(15)

• What is SOA?

• there are several definitions

• high level and low level

• different points of view: technical, business

• What follows:

• some definitions from a survey ofSearchWebServices.com

• discussion of the definitions

1.13. Official definition of SOA

• "SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations."OASIS

1.14. Definition of SOA

• "SOA is a framework enabling application functionality to be provided, discovered and consumed as reusable Web Services sets. While Web Services do not equal SOA, it's one of the enabling standards. SOA abstracts complexity and implementation details, making it an ideal architectural mindset to leverage functionality trapped within mainframe/midrange systems."Scott Rosenbloom is chief strategist with WRQ Inc.

1.15. Definition of SOA

• "Service Oriented Architecture is nothing but business oriented architecture, which allows the flexibility of business applications, to become independent but collaborative, while providing their services. The applications under this architecture are both 'client' and 'server' at the same time with freely available services." Satheesan Kunnel, USWWI

1.16. Definition of SOA

• "A service oriented architecture is an approach to design and integrate software in a modular method where each module is precisely a 'loosely coupled service' that is accessible over a network and has the capability of being dynamically integrated with other services at run time. A service must present a standard Interface (be it WSDL today) for its functionality and invocation methods while the real implementation of the service is not a concern of an SOA."Rajesh Dawar

1.17. Definition of SOA

• "A pattern of design, development, deployment, and management of applications and software infrastructure and frameworks in which:

• Applications are organized into business units of work (services) that are (typically) network accessible

• Service interface definitions are first-class development artifacts

• Quality of service (QoS) characteristics (security, transactions, performance, etc.) are explicitly identified at design time

(16)

• Software infrastructure takes active responsibility for managing QoS and enforcing policy for service access and execution

• Services and their metadata are cataloged in a repository

• Protocols and structures within the architecture are, optionally, based on industry standards (e.g., the emerging SOAP stack of standards)"Randy Heffner, vice president, Forrester Research Inc.

1.18. Definition of SOA

• "Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol- independent distributed applications composed from well-defined, self-contained software resources accessible as Services across the extended enterprise in a standardized way, enhancing re-usability and interoperability."Ankur Gupta, marketing manager, Fiorano Software Inc.

1.19. Concepts in the definitions

• abstracts complexity

• business process execution

• business-oriented architecture

• standardizing interfaces

• self-contained services

• autonomous services

• loosely-coupled

• standard protocols

• independent but collaborative

• dynamic integration

• reusable services

• service composition

1.20. SOA myths and facts (Microsoft)

(17)

1.21. SOA myths and facts (Microsoft)

1.22. Principles of SOA (by Web Services Journal)

• Standardized service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.

• Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

• Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.

• Service reusability: Logic is divided into services with the intention of promoting reuse.

1.23. Principles of SOA (by Web Services Journal)

• Service autonomy: Services have control over the logic they encapsulate.

• Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary

• Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

• Service composability: Services are effective composition participants, regardless of the size and complexity of the composition.

1.24. Best definition of SOA

• "Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol- independent distributed applications composed from well-defined, self-contained software resources accessible as Services across the extended enterprise in a standardized way, enhancing re-usability and interoperability."Ankur Gupta, marketing manager, Fiorano Software Inc.

1.25. Requirements of software systems

1.26. Requirements

(18)

1.27. System Qualities

• Supportability is the ability of technical support personnel to install, configure, and monitor computer products, identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service.

• Testability is the degree to which a software artifact supports testing in a given test context.

1.28. Run-time Qualities

• Availability is the proportion of time a system is in a functioning condition.

• Interoperability is the ability of diverse systems and organizations to work together (inter-operate).

• Manageability defines how easy it is to manage the application and tune its performance through a monitoring system.

• Performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.

1.29. Run-time Qualities

• Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time.

• Scalability is the ability of a system to adopt to changes of load and demand.

• Security of a system is the degree of its resistance to, or protection from harm.

1.30. Design Qualities

• Conceptual integrity means that the system and its components follow a single set of design rules and guidelines.

• Flexibility is the ability to make changes in the product being developed or in how it is developed, even relatively late in development, without being too disruptive.

(19)

• Maintainability involves a system of continuous improvement - learning from the past in order to improve the ability to maintain systems, or improve reliability of systems based on maintenance experience.

• Reusability defines the capability for components to be suitable for use in other scenarios.

1.31. User Qualities

• Usability of a system is the ability that allows users to effectively and efficiently accomplish the tasks for which it was designed and one that users rate positively on opinion or emotional scales.

1.32. System integration topologies

1.33. Typical topologies

• Direct communication

• Bus topology (indirect communication)

1.34. Direct communication

• connections for N participants

• data conversion

• Poor maintainability

• Every participant must provide high availability

• Hard to add new participants

(20)

• Typical use:

• between different enterpises

• published as web services

1.35. Bus topology (indirect communication)

• Bus provides connection between the participants

• Everyone communicates directly with the bus:O(N) connections

• Common data format on the bus:O(N) conversions

• Easier to maintain

• Only the bus must provide high availability and reliability

• Easy to add new participants

• Typical use:

• within an enterprise

• as an Enterprise Service Bus (ESB)

2. 2 Web services: WSDL

2.1. Outline

• Web service

(21)

• WSDL 1.1

• WSDL 2.0

• Web service APIs: JAX-WS, WCF

2.2. Web service 2.3. Web service

WSDL = Web-Services Description Language SOAP = Simple Object Access Protocol

UDDI = Universal Description, Discovery and Integration

2.4. Web services

• Definition:

• service available through SOAP messages

• Message format:

• SOAP = Simple Object Access Protocol

• Versions: 1.1 and 1.2

• Interface descriptor:

• WSDL = Web-Services Description Language

• Service repository:

• UDDI = Universal Description, Discovery and Integration

(22)

2.5. WSDL (Web-Services Description Language)

2.6. WSDL

• Web Services Description Language

• Descriptor for web services

• interface

• meta-data

• service address

• W3C

2.7. WSDL 1.1

(23)

• definitions: root element

• import: other WSDL

• types: used types

• XML schema (XSD)

• message: parameter list

• part: parameter

• portType: interface

• operation: function

• input: input parameters

• output: output parameters

(24)

• fault: exception

• binding: calling convention

• protocol, data format, encoding

• service: implementation

• port: location of the service with the given binding

2.8. WSDL 1.1: types in XSD

2.9. WSDL 1.1: abstract part

2.10. WSDL 1.1: concrete part

(25)

2.11. WSDL 1.1 MEP

• MEP = Message Exchange Pattern

• Depends on the input/output parameters

2.12. Equivalence of two interfaces

• The following must match:

• types and namespaces in the XSD part

• the Action

• the binding options

• the policy options

• if no explicit Action:

• the targetNamespace of the WSDL, the name of the portType, operation, input, output and fault

• Do not have to match:

• the name of the message or the part

• the name of the binding

• the name and address of the service

• if there is an Action:

• the targetNamespace of the WSDL, the name of the portType, operation, input, output and fault

(26)

2.14. WSDL 2.0

• Not yet widespread and not yet widely supported

• Simpler than version 1.1

• Root: description instead of definitions

• There is import and include

• Reduced redundancy: no message

• Reusable bindings

• interface instead of portType

• (Multiple) inheritance among interfaces

2.15. WSDL 2.0 summary

(27)

2.16. JAX-WS

2.17. JAX-WS

• Java API for XML-based Web-Services

• Goal:

• Simple implementation of web services

• Mapping between WSDL and Java

• Uses annotations

• Implementations:

• Apache CXF

• Apache Axis2

• Oracle

• JBoss: uses Apache CXF

• IBM: built on Apache Axis2

• Recommendation: Apache CXF with JBoss

2.18. JAX-WS sample: interface

2.19. JAX-WS sample: interface with annotations

(28)

2.20. JAX-WS sample: implementation

2.21. JAX-WS sample: client

• wsimport generates CalculatorService

• Client code:

2.22. WCF

2.23. WCF

• Windows Communication Foundation (from .NET 3.0)

• Goal:

• Simple implementation of web services

• Mapping between WSDL and .NET types

• Uses .NET Attributes

• Very similar to JAX-WS

• Supports WS- standards

(29)

2.24. WCF sample: interface

2.25. WCF sample: interface with Attributes

2.26. WCF sample: implementation

2.27. WCF sample: client

• SvcUtil generates CalculatorClient

• Client code:

(30)

2.28. References

• SOAP standard:http://www.w3.org/TR/soap/

• WSDL standard:http://www.w3.org/TR/wsdl

• Web Services Tutorial:http://www.w3schools.com/WebServices/default.asp

3. 3 Web services: SOAP

3.1. Outline

• Web services

• SOAP

• SOAP encoding styles

• XML serialization APIs:

• JAXB

• WCF DataContract

3.2. Web service

3.3. Web service

(31)

WSDL = Web-Services Description Language SOAP = Simple Object Access Protocol

UDDI = Universal Description, Discovery and Integration

3.4. Web services

• Definition:

• service available through SOAP messages

• Message format:

• Interface descriptor:

• WSDL = Web-Services Description Language

• Service repository:

• UDDI = Universal Description, Discovery and Integration

3.5. SOAP (Simple Object Access Protocol)

3.6. SOAP history

• Originally:

• 1998. Microsoft

(32)

• XML-based RPC

• Today:

• W3C

• the abbreviation remained SOAP, however, it is not extracted any more

3.7. SOAP

• Communication protocol

• Between applications

• Based on XML

• Platform independent

• Programming language independent

• Simple

• Extensible

• see later: WS- standards

• Independent of the transport layer, however, the most common transport is HTTP

3.8. SOAP envelope

3.9. SOAP 1.1

• SOAP message namespace:

• http://schemas.xmlsoap.org/soap/envelope/

(33)

• WSDL namespace:

• http://schemas.xmlsoap.org/wsdl/soap/

• HTTP request:

• POST [local URL] HTTP/1.1Content-Type: text/xml; charset="utf-8"SOAPAction: [Action]

• SOAPAction is mandatory

3.10. SOAP 1.2

• SOAP message namespace:

• http://www.w3.org/2003/05/soap-envelope

• WSDL namespace:

• http://schemas.xmlsoap.org/wsdl/soap12/

• The Fault element has a different structure than in version 1.1

• HTTP headers:

• POST [local URL] HTTP/1.1Content-Type: application/soap+xml;charset=utf-8;action="[Action]"

• action is optional

• GET method is also allowed

3.11. SOAP binding style

• Defines the encoding style of the parameters

• Styles:

• RPC/encoded

• RPC/literal

• Document/encoded (not implemented)

• Document/literal

• Document/wrapped (recommended)

3.12. RPC/encoded

(34)

3.13. RPC/literal

3.14. Document/literal

3.15. Document/wrapped

(35)

3.16. WSDL 1.1 - SOAP 1.1 binding

3.17. WSDL 1.1 - SOAP 1.2 binding

3.18. JAXB

(36)

3.19. JAXB

• Java Architecture for XML Binding

• JSR-222

• Why?

• XML handling: SAX, DOM

• SAX: event-driven, serial access, fast, small memory footprint

• DOM: builds a tree representation in memory, the tree is changeable, and can be validated

• Problems:

• they are too general

• access is not statically typed

• no compile-time check

3.20. JAXB

• Mapping between XSD and Java

• Annotations

• Model:

[fragile]

3.21. JAXB

• Specification:

• Subset of XML Schema

• Default mappings:

• XML names Java names

• Schema atomic types Java types

• Schema structured types Java classes

(37)

• Java package: javax.xml.bind

• Compiler:

• XML Schema-to-Java Compiler (xjc)

• Part of the JDK:

3.22. Atomic types

3.23. Custom bindings

• Customizable:

• generated package names, class names, method names

• return type of a method

• field types

• which elements belong to a class

• which element to omit

• fields are mapped to elements or attributes

• How:

• Special elements with a predefined JAXB namespace in the XML Schema part

• Separate XML descriptor (recommended)

3.24. XML Schema support

(38)

• Some XML Schema constructs are not supported:

• wildcard types

• any, anyAttribute

• identity-constraints:

• key, keyref, unique

• other constraints:

• restriction

• ...

3.25. Packages and namespaces

3.26. JAXB sample

3.27. JAXB sample: list

(39)

3.28. WCF DataContract

3.29. WCF DataContract

• Mapping between .NET types and XML Schema

• Metadata on classes: .NET attributes

• Similar to JAXB

3.30. Atomic types

3.31. Packages and namespaces

(40)

3.32. WCF DataContract sample

3.33. WCF DataContract sample: list

3.34. References

• SOAP standard:http://www.w3.org/TR/soap/

• WSDL standard:http://www.w3.org/TR/wsdl

(41)

• Web Services Tutorial:http://www.w3schools.com/WebServices/default.asp

4. 4 WS- standards

4.1. Outline

• Requirements

• WS- standards

• XML digital signature

• XML encryption

4.2. Integration requirements 4.3. Integration within a company

4.4. e-Gov integration

(42)

• Integration within a company

• transactions

• e-Gov integration, integration between companies:

• security: encryption, digital signature

• reliability: no messages are lost

• Standardized solution

4.6. WS- standards

4.7. Web service standards

4.8. Messaging

• WS-Addressing:

(43)

• SOAP headers:

• Action

• To

• From

• ReplyTo

• FaultTo

• MessageId

• RelatesTo

• MTOM (Message Transmission Optimization Mechanism): efficient byte transfer as MIME attachment

4.9. Security

• WS-Security:

• encryption, digital signature

• WS-SecureConversation:

• symmetric-key crypto

• (analogy: SSL)

• WS-Trust:

• issuing tokens

• (analogy: Kerberos)

• WS-Federation

• identity management between trusted domains

• single sign-on

(44)

4.10. WS-Federation sample

4.11. Reliable messaging

• analogy: TCP

• WS-Reliability:

• original version

• does not live well with the other WS- protocols

• WS-ReliableMessaging:

• widely supported

• lives well with the other WS- protocols

• pl. transactions, security, ...

4.12. WS-ReliableMessaging

(45)

Source: OASIS WS-RM standard

4.13. Transactions

• WS-Coordination:

• managing transactions

• WS-AtomicTransaction:

• short term transaction

• 2PC

• WS-BusinessActivity:

• long running transaction

• rollback: compensation

(46)

4.14. Metadata

• WS-Policy:

• describes the capabilities of the service

• extends the WSDL

• e.g.:

• WS-Security Policy

• WS-ReliableMessaging Policy

• WS-AtomicTransaction Policy

• WS-MetadataExchange:

• retrieving WSDL

• exchanging Policy information

• dynamic protocol discovery

4.15. WS- standards

(47)

4.16. Asymmetric-key cryptography

4.17. Asymmetric-key cryptography

• Key-pair:

• private: known only by the owner

• public: known by everyone

• It is hard to guess the private key from the public key

• Example: RSA

• public key:

• product of two large primes + an exponent

• basis: prime factorization is hard

4.18. Asymmetric-key cryprography

• Data encoded with the public key can only be decoded by the private key

• application: encryption

• anyone can encrypt with the public key

• only the owner of the private key can decrypt it

• Data encoded with the private key can only be decoded with the public key, and no one else can produce the same encoding without the private key

• application: digital signature

• the owner of the private key encrypts the data

• it can be decrypted (checked) by anyone, since the public key is known by everyone

(48)

4.19. X.509 certificate

• Contents:

• Subject: the owner, for whom the certificate has been issued

• Issuer: the one who vouches for the validity of the certificate by his own digital signature

• Serial number: assigned by the issuer

• Valid from/to: validity time

• Thumbprint: this is signed by the issuer

• Public key: the public key

• Private key: the private key

4.20. X.509 certificate: public key

(49)

4.21. X.509 certificate: private key

(50)

(51)

4.22. Certificate hierarchy

4.23. XML encryption, XML digital signature

(52)

4.24. XML digital signature

• Digital signature in XML

• Namespace:

• http://www.w3.org/2000/09/xmldsig

• Specification:

• http://www.w3.org/TR/xmldsig-core/

4.25. Steps of XML digital signature

• 1. determining resources to sign

• 2. optional transformations

• 3. hash (message digest) of the resources

• 4. collecting resources, selecting a canonicalization and signature algorithm

• 5. canonicalization

• 6. signing

• 7. adding key information

• 8. adding optional information

• 9. packaging XML items

4.26. 1. Collecting resources to sign

• What to sign?

• Example:

• Website:

• http://www.abccompany.com/index.html

• Picture on the web:

• http://www.abccompany.com/logo.gif

• Referenced element in an XML on the web:

• http://www.abccompany.com/xml/po.xml sender1

• Referenced element in the current XML:

• elem20

4.27. 2. Optional transformations

(53)

• Optional transformation of the resources

• Examples:

• binary data to BASE64

• XML transformation with XSLT

• The result of the transformation will be signed

4.28. 3. Hash (message digest)

• Goal: the signed document should be small

• Solution:

• Create a small thumbprint with a hash function

• One-way:

• it is hard to create a document that has a given thumbprint

• Collision free:

• it is hard to create two documents with the same thumbprint

• Hash algorithms:

• SHA1, SHA256, SHA512,(MD5 is not recommended any more)

4.29. 4. Collecting references

• Putting references together: SignedInfo

• Selecting canonicalization and signature algorithm

• This SignedInfo element will be signed

• Example:

4.30. 5. Canonicalization

• Normalizing SignedInfo element before signing it

(54)

• Why?

• a a and a are the same

• White-space problems(e.g. a or a )

• Namespace declarations and prefixes

• Comments

4.31. 6. Signing

• Signing the normalized SignedInfo

• this already contains the hashes of the resources

• Method:

• create another hash from the SignedInfo element

• sign (encode) this hash with the private key

• Algorithms:

• DSA with SHA1

• RSA with SHA1

4.32. 7. Adding key information

• Optional:

• if it is omitted, the other side should know it

• Types of keys:

• asymmetric (e.g. RSA)

• X.509 certificate

• custom

4.33. 8. Adding optional information

• Adding optional information

• E.g. time-stamp:

(55)

4.34. 9. Packaging XML items

• Packaging everything into a Signature element:

4.35. Digital signature summary

4.36. Result of the digital signature

(56)

4.37. Checking digital signature

• 1. Transform the resources and calculate their hashes

• 2. Check the hashes with the ones in the SignedInfo element

• 3. Normalize the SignedInfo element with the canonicalization algorithm

• 4. Create the hash of the SignedInfo element

• 5. Check the validity of the SignatureValue using the public key

4.38. Checking digital signature

4.39. XML encryption

• Encryption in XML

(57)

• Namespace:

• http://www.w3.org/2001/04/xmlenc

• Specification:

• http://www.w3.org/TR/xmlenc-core/

4.40. Steps of XML encryption

• 1. Select algorithm

• 2. Select/retrieve key

• 3. Select data to encrypt

• 4. Encryption

• 5. Adding key information

• 6. Summary

• 7. Replace plaintext with the encrypted text

4.41. Select encryption algorithm

• No stream encryption algorithms in the standard

• But there are block-encryption algorithms:

• 3DES

• AES-128

• AES-256

• AES-192

4.42. Select/retrieve encryption key

• Methods for specifying the key:

• none: the other side knows it

• EncryptedKey: a key encrypted by another key

• AgreementMethod: key-exchange algorithm

• X509 certificate

• Attached in another way

4.43. Encryption/exchange of keys

• Key encrypted with an asymmetric key:

(58)

• Key determined by a key-exchange algorithm:

• Diffie-Hellman

• Key encrypted with a symmetric key:

• 3DES

• AES-128

• AES-256

• AES-192

4.44. Data to encrypt

• What to encrypt:

• XML element

• content of an XML element

• text or child elements

• any data

• another key

• Where to put the encrypted data:

• in-place (typically encoded in Base64)

• attached with a reference

4.45. XML encryption summary

4.46. Encryption process

(59)

4.47. Steps of decryption

• 1. Identify the decryption algorithm and key information

• 2. Retrieve the key (if it is encrypted then recursively continue from step 1)

• 3. Decrypt the contents of CipherData

4.48. Decryption summary

4.49. X.509. certificates in Windows and in Java

4.50. Certificate hierarchy

(60)

4.51. Windows certificate store

4.52. Java certificate store

• Format: JKS

• Typically two files (but not mandatory):

• cacerts.jks: public keys of root CAs

• keystore.jks: our private keys

• Management:

• public keys: keytool in JDK

• private keys: no support in JDK

• but there are custom programs on the web, e.g. pkcs12import

4.53. References

(61)

• WS-Addressing:http://www.w3.org/Submission/ws-addressing/

• WS-ReliableMessaging:https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx

• WS-Security:https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

• WS-Transaction:https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx

5. 5 Representational State Transfer (REST)

5.1. Outline

• HTTP

• REST

• JAX-RS

5.2. HTTP

5.3. HTTP GET

5.4. HTTP GET

(62)

5.5. HTTP POST

5.6. REST

5.7. REST

• REpresentational State Transfer

• RESTful HTTP

• HTTP protocol extension

• GET, POST, PUT, DELETE

• Input parameters:

• URL part

• URL query string

• POST parameter

• HTTP body

• Result:

• HTTP body

• Very simple: testable by browser

5.8. Goals of REST

• Scalability of component interactions

• Generality of interfaces

• Independent deployment of components

• Intermediary components to reduce latency, enforce security and encapsulate legacy systems

(63)

5.9. REST principles

• Identifying resources

• Linking things

• CRUD operations

• Multiple data representation

• Stateless communication [fragile]

5.10. Identifying resources

• URI: Universal Resource Identifier

• base of resource identification (URN, URL)

• URN: Universal Resource Name

• URI that does not contain location information

• e.g. urn:isbn:0307346617

• pro: valid forever

• con: contain no information on their resolution

• URL: Universal Resource Locator

• URI that contains location information

• con: may not be valid forever, especially if they contain technology-specific parts, e.g.http://someserver.com/ActionServlet?blah=blah

• but they can be used correctly, e.g.http://company1.com/customer/123456

5.11. Identifying resources

• Use URLs!

• unique identifier for the resource

• easy to resolve due to the location information

• should be independent of the underlying technology

• Examples for resources:

• documents (blogs, news, etc.)

• data (calculation result, metadata, etc.)

• services (SOAP web service, REST, etc.)

• concepts (people, organizations, etc.)

(64)

5.12. Linking things

• URLs must be chosen carefully

• Has a lot of advantages:

• easy to forward

• resource behind it can be accessed later

• analogy: C++ pointers

• more secure: easier to configure access rights to the resource

5.13. Processing URLs

• URL seems hierarchic

• Client:

• should not process the contents of an URL

• should only use it as a reference

• like browsers

• the structure of the URL may change by time

• Hence, no need for interface description

• The four basic operations are enough for handling resources: GET, POST, PUT, DELETE

5.14. Standard operations on resources

• CRUD: create, read, update, delete

• Properties (from the HTTP specification):

• safe: the client only retrieves data, it is not responsible for side effects

• idempotent: repeating the same operation results in the same state

• Repeating different idempotent operations may result in different results

• e.g. read-delete-read

• Repeating operations without side effects has the same results

5.15. Standard operations

(65)

POST: the servers assigns the identifier PUT: the client assigns the identifier [fragile]

5.16. Multiple data representation

• HTML:

• only for humans

• structure may often change

• computers require more formal representation (e.g. XML, JSON)

• The client should be able to choose between the representations

• A possible but bad solution:

• http://company1.com/2009/report.html

• http://company1.com/2009/report.xml

• http://company1.com/2009/report.xls

• Correct solution: "Accept" HTTP header, e.g.

• GET /2009/report HTTP/1.1

• Host: company1.com

• Accept: application/xml

• If the server does not support it, it may send: HTTP 406 Error

5.17. Stateless communication

• REST is stateless

• But the application may have a state:

• stored in a resource (not in memory)

• stored on the client side (always sent to the server)

• Advantage:

• scalability: no session required on the server side

5.18. JAX-RS

5.19. JAX-RS

• JAX-RS: Java API for RESTful Web Services (JSR-311)

•

(66)

• Java annotations

• Implementations:

• official (Sun-Oracle): Jersey

• JBoss: RESTeasy

• Apache CXF

• Restlet [fragile]

5.20. JAX-RS sample

• Application servlet:

• general servlet for a RESTful application

• returns which classes are published as REST resources

• requires a web.xml, too

• always looks like as:

@javax.ws.rs.ApplicationPath(,,resources'')public class ApplicationConfig extends javax.ws.rs.core.Application

5.21. Calculator sample

[fragile]

5.22. Parameters

• Annotations:

• @PathParam: URI template parameter (part of the URI)

• @QueryParam: URI query parameter

• @MatrixParam: URI matrix parameter

(67)

• @FormParam: POST parameter

• @CookieParam: Cookie parameter

• @HeaderParam: HTTP header parameter

• Supported types:

• 1. primitive types

• 2. T types having a constructor with a single String parameter

• 3. T types containing one of the following static methods:

• public static T valueOf(String)

• public static T fromString(String)

• 4. List , Set , SortedSet , where T is from cases 2 or 3 above [fragile]

5.23. Param samples

• @Path("add"), @QueryParam

• http://\dots/calculator/add?left=3.0\&right=5.0

• @Path("add/{left}/{right}"), @PathParam

• http://\dots/calculator/add/3.0/5.0

• @Path("add"), @MatrixParam

• http://\dots/calculator/add;left=3.0;right=5.0

• @Path("add"), @PostParam

• http://\dots/calculator/add

5.24. Result

• Possible values:

• void, null: empty result, "204 No Content"

• Response: response stream

• GenericEntity: for generic types (type erasure)

• other types (serialized in XML, JSON or other format)

(68)

• e.g. String is, Double is not

• solution: implement the following interfaces:

• MessageBodyReader

• MessageBodyWriter [fragile]

5.25. MessageBodyWriter

5.26. MessageBodyWriter sample

5.27. MessageBodyWriter sample

(69)

5.28. MessageBodyWriter sample

5.29. Calculator sample revisited

5.30. HTTP methods, mime-types

• HTTP method annotations:

(70)

• @GET, @POST, @PUT, @DELETE, @HEAD

• HTTP content-type annotations:

• @Consumes: what kind of inputs the operation accepts

• @Produces: what kind of outputs can the operation produce

5.31. XML and JSON

• Input and output parameters are usually XML or JSON

• Good news: they can be handled in a unified way

• JAXB technology:

• Java-XML mapping, serialization

• originally for SOAP web services

• it can serialize into JSON, too

5.32. XML and JSON sample

5.33. XML and JSON sample

(71)

5.34. XML result

5.35. JSON result

5.36. REST client

• Not part of the JAX-RS specification

• Each vendor implements it differently

• Jersey (Sun-Oracle):

• only low-level access

• RESTeasy (JBoss):

• low-level access

• statically typed high-level access (annotated interface) [fragile]

(72)

5.37. Jersey client

import com.sun.jersey.api.client.Client; import com.sun.jersey.api.client.WebResource;import com.sun.jersey.api.client.config.ClientConfig;import

com.sun.jersey.api.client.config.DefaultClientConfig;import javax.ws.rs.core.MediaType;

5.38. Jersey client

5.39. Jersey client main program

5.40. WCF

(73)

[fragile]

5.41. WCF for REST

• WCF can also applied to REST

• Just like for SOAP web services

• Same hosting: IIS or self-hosting

• Same project structure

• Same attributes: ServiceContract, OperationContract, DataContract, etc.

• Additional attributes: WebGet, WebInvoke

• They specify the format of the URL

• Same configuration file

• Binding to use in the configuration: webHttpBinding

• For more information see:

• http://msdn.microsoft.com/en-us/magazine/dd315413.aspx [fragile]

5.42. References

• http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm

• http://www.infoq.com/articles/rest-introduction

• http://en.wikipedia.org/wiki/Representational_state_transfer

6. 6 Design and development guidelines for web services

6.1. Outline

• WSDL version

• SOAP version

• SOAP encoding

• XSD and WSDL

• XSD constraints

• Common types and common code

• Top-down or bottom-up development

(74)

• Interface design guidelines

6.2. WSDL version

• WSDL 1.1

• redundant

• widespread

• well supported

• WSDL 2.0

• richer: interface inheritance, reusable bindings

• not very supported

• Recommendation: WSDL 1.1

6.3. SOAP version

• SOAP 1.1

• well supported

• bound to HTTP: SoapAction header

• SOAP 1.2

• well supported

• independent of HTTP

• Recommendation:

• both, but SOAP 1.2 is preferred

6.4. SOAP encoding

• RPC/encoded

• RPC/literal

• Document/encoded (doesn't exist)

• Document/literal

• Document/wrapped (WS-I Compliant)

• Recommendation:

• Document/wrapped: widespread, easy to validate the message

6.5. XSD and WSDL

• XSD embedded in the types section

(75)

• XSD separated and included into the WSDL

• Recommendation: separated

• WSDL is smaller and simpler

• XSD is reusable

6.6. XSD constraints

• Advantages:

• interface is stricter

• checked at message level

• Disadvantages:

• cannot be mapped to Java/C APIs

• have to be maintained

• Recommendation:

• do not use them, check at application level

6.7. Common types and common code

• Types generated from XSD and WSDL

• Should be used on client and server side

• Vendor tools usually generate client side

• Recommendation:

• generate the client files

• put them in a separate project

• always use the same project for the same XSD even if referenced from multiple WSDLs

• add this project to the server and client side as a dependency

6.8. Top-down or bottom-up development

• Bottom-up/Implementation-first:

• started from program code

• rapid development

• WSDL is not stable

• Top-down/Contract-first:

• started from WSDL

(76)

• WSDL is stable: required for interoperability

• Recommendation: top-down

6.9. API

• Programming API for web services

• Recommendation:

• Java world: Java API for XML-based Web Services (JAX-WS)

• .NET world: Windows Communication Foundation (WCF)

• Both of them are type safe

• They map classes to XSD types, interfaces to WSDLs

• JAX-WS implementations have WS- extensions

• WCF supports WS- by default

6.10. Interface design guidelines

6.11. Top-down design

• Use top-down design

• Define interface first

• Advantages:

• implementation has no effect on the interface

• server and client can be developed independently

• WSDL is hard to create manually:

• use graphical tools

• or generate them

6.12. Exceptions

• Define exceptions (faults)

• Use request-response operations

• Throw exception if the request cannot be completed

• Use both error codes and textual description in exceptions

• Error code: for automatic processing

• Textual description: for humans

• also include information to resolve the problem

(77)

6.13. Synchronous and asynchronous calls

• Synchronous call: client waits for the result

• Asynchronous call: client starts the process and continues

• Do not mix synchronous and asynchronous calls in a single interface

• Define separate interfaces instead

• Long running activities with synchronous calls:

• start the activity in background or throw an exception

• return immediately from the operation

• the client can access/get the result later

6.14. Stateless service

• Design the interface for stateless interaction

• Server side should not store state in memory

• Solutions:

• store state in persistent storage (e.g. database) on the server side, transfer identifiers between the client and server

• store state on the client side and transfer it in every call

6.15. Avoid implementation-specific parameters

• Avoid putting implementation-specific parameters into the interface

• Use only general data types

• Use only general identifiers

• Do not publish:

• internal identifiers

• special data types

• special encodings

6.16. Granularity

• Fine-grained operations:

• each query returns a small portion of data

• lot's of calls are required

• Coarse-grained operations:

(78)

• a single query returns all the data

• lot's of unnecessary data transferred

• Recommendation:

• use general, reusable operations

• lean toward coarse-grained operations, since the network overhead may be large

6.17. Overloading

• Overloading: same operation name with different parameter types

• Do not use overloading in interfaces

• Do not use templates and generics in interfaces

6.18. Responsibilities

• Define separate interfaces for different responsibilities

• If the operations of an aspect changes, only the corresponding interface will change

• Avoid gaps and overlaps between interfaces

6.19. Paging large lists

• If large lists are returned, provide paging for the results

• State must be preserved somewhere

6.20. Changes

• If an interface changes:

• either make it backwards compatible

• or create a new interface and also provide access through the old one until all clients are updated

• Use interface versioning

• Use service repository for storing different versions

7. 7 Business Process Execution Language (BPEL)

7.1. Outline

• Business processes

• BPEL

7.2. Business processes

(79)

7.3. Business processes

• Simple services

• Aim:

• more complex services

• business processes

• Questions:

• How to describe business processes?

• How to automate execution?

• What are the typical process patterns?

7.4. Business process

• A business process connects tasks in order to reach the desired effect

• Types of business processes:

• Management process: controls system operation

• Operational process: basic process of an organization producing the primary value

• Supporting process: supports basic processes

• Business processes can be split up to smaller processes

7.5. Business processes

• Business process analysis: breakdown of processes into subprocesses until elementary tasks

• Development steps:

• identifying processes

• documentation

• implementation

• change management

• systematic organization

7.6. Designing business processes

• Key questions:

• Who?

(80)

• Which?

• Which tasks and activities build up the process?

• What?

• What kind of entities and data does the process operate on?

• When?

• When does it start or stop?

• What order?

• What is the order of the tasks and activities?

• Why?

• What is the value the process produces?

7.7. Automating business processes

• Goal: executing business processes by computers

• Advantages:

• speed

• consistency

• quality improvement

• Requirement:

• formalized description (e.g. BPMN, BPEL)

7.8. Typical business process patterns

• Source: http://www.workflowpatterns.com

• Basic Control Flow Patterns (5)

• Advanced Branching and Synchronization Patterns (14)

• Multiple Instance Patterns (7)

• State-based Patterns (5)

• Cancellation and Force Completion Patterns (5)

• Iteration Patterns (3)

• Termination Patterns (2)

• Trigger Patterns (2)

7.9. Basic Control Flow Patterns

• 1. Sequence

(81)

• 2. Parallel Split

• 3. Synchronization

• 4. Exclusive Choice

• 5. Simple Merge

7.10. Business Process Execution Language (BPEL)

7.11. BPEL

• Business Process Execution Language for Web Services (BPEL4WS, WS-BPEL)

• OASIS standard

• XML-based

• Web services

• Executable

• Describes business processes

• Provides and consumes web services

• Orchestration

7.12. BPEL process

• Executable

• Describes:

• activities

• order of execution

• data

• partners

• exception handling

• long running transactions

7.13. BPEL 1.1 structure

(82)

7.14. BPEL 1.1 structure

7.15. BPEL 2.0 structure

(83)