Service-Oriented Integration - tankonyvtar.hu · Created by XMLmind XSL-FO Converter. Service-Oriented Integration Goldschmidt, Balázs Simon, Balázs Szeberényi, Imre

Created by XMLmind XSL-FO Converter.

Service-Oriented Integration

Goldschmidt, Balázs Simon, Balázs

Szeberényi, Imre

Created by XMLmind XSL-FO Converter.

Service-Oriented Integration írta Goldschmidt, Balázs, Simon, Balázs, és Szeberényi, Imre

Publication date 2015 Szerzői jog © 2015 Goldschmidt Balázs, Simon Balázs, Szeberényi Imre

iii Created by XMLmind XSL-FO Converter.

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.14. Definition of SOA .................................................................................................. 5 1.15. Definition of SOA .................................................................................................. 5 1.16. Definition of SOA .................................................................................................. 5 1.17. Definition of SOA .................................................................................................. 5 1.18. Definition of SOA .................................................................................................. 6 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.26. Requirements .......................................................................................................... 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.3. 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 2.18. JAX-WS sample: interface ................................................................................... 17


iv Created by XMLmind XSL-FO Converter.

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.2. Web service ............................................................................................................ 20 3.3. Web service ............................................................................................................ 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 3.34. References ............................................................................................................ 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.5. Requirements .......................................................................................................... 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


v Created by XMLmind XSL-FO Converter.

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 4.53. References ............................................................................................................ 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 5.20. JAX-RS sample .................................................................................................... 56


vi Created by XMLmind XSL-FO Converter.

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.27. MessageBodyWriter sample ................................................................................. 58 5.28. MessageBodyWriter sample ................................................................................. 59 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 5.42. References ............................................................................................................ 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.3. Business processes .................................................................................................. 69 7.4. Business process ..................................................................................................... 69 7.5. Business processes .................................................................................................. 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.14. BPEL 1.1 structure ............................................................................................... 72 7.15. BPEL 2.0 structure ............................................................................................... 72 7.16. BPEL 2.0 structure ............................................................................................... 73


vii Created by XMLmind XSL-FO Converter.

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 7.43. References ............................................................................................................ 87

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.8. Activities ................................................................................................................. 89 8.9. Activities ................................................................................................................. 89 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 8.25. References ............................................................................................................ 96

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 9.6. Microsoft ................................................................................................................ 97


viii Created by XMLmind XSL-FO Converter.

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 9.18. Capabilities of an ESB ........................................................................................ 100 9.19. Capabilities of an ESB ........................................................................................ 100 9.20. Capabilities of an ESB ........................................................................................ 101

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


ix Created by XMLmind XSL-FO Converter.

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

1 Created by XMLmind XSL-FO Converter.


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



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



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



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



• 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


• "SOA is a framework enabling application functionality to be provided, discovered and consumed as re-

usable 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.


• "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


• "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


• "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



• 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.


• "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)



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



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.



• 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



• 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



• 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




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



• 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



• 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



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

2.13. WSDL 1.1 summary



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



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



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



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:



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



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




• 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/



• 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



3.13. RPC/literal

3.14. Document/literal

3.15. Document/wrapped



3.16. WSDL 1.1 - SOAP 1.1 binding

3.17. WSDL 1.1 - SOAP 1.2 binding

3.18. JAXB



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



• 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



• 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



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



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



• 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

4.5. Requirements



• 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:



• 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



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



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



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



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



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



4.21. X.509 certificate: private key





4.22. Certificate hierarchy

4.23. XML encryption, XML digital signature



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



• 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



• 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:



4.34. 9. Packaging XML items

• Packaging everything into a Signature element:

4.35. Digital signature summary

4.36. Result of the digital signature



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



• 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:

• RSA-v1.5



• 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



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



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



• 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



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



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.)



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



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)

• Mapping Java classes to REST resources



• 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



• @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)

• Not all Java types are supported



• e.g. String is, Double is not

• solution: implement the following interfaces:

• MessageBodyReader

• MessageBodyWriter

[fragile]

5.25. MessageBodyWriter

5.26. MessageBodyWriter sample





5.29. Calculator sample revisited

5.30. HTTP methods, mime-types

• HTTP method annotations:



• @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



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]



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



[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

• API



• 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



• 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

• WSDL has to be constructed somehow



• 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



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:



• 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




• 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


• 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?

• Who are the participants?



• 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



• 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








7.17. BPEL 2.0



7.18. import

• Using WSDL and XSD files:

7.19. BPEL 2.0



7.20. partnerLinks

• Defines the provided and consumed web services

• References a partnerLinkType

• WSDL extension

• Roles:

• of the process: myRole

• of the partner: partnerRole

7.21. partnerLinks



7.22. Sample

7.23. BPEL 2.0



7.24. variables

• Store data

• Describe the state of the process

• Sent or received messages

• Temporary data

• The process stores these persistently

• Type: message, XSD type, XSD element

7.25. BPEL 2.0



7.26. Simple activities

• Receive

• receive a message from a partner

• attributes:

• partner

• port

• operation

• Reply

• synchronous reply for a receive

• Invoke

• send a synchronous or asynchronous request

7.27. Sample



7.28. Simple activities

• Wait

• the process waits until/for the specified time

• Empty

• does nothing

• Terminate

• terminates the process immediately

• Throw

• throws an exception

• Assign

• value assignment

• Compensate

• rollback

7.29. Structured activities

• Sequence

• serial execution

• Switch (BPEL 1.1), If (BPEL 2.0)

• conditional branching

• While

• repeating activities

• Pick



• defines a set of messages

• will be executed if one of the messages arrives

• time-out can also be specified

• can initiate a process (Receive/Pick)

7.30. flow

• Parallel execution

• Directed acyclic graph

• vertices: activities

• edges: links

• Each activity defines:

• for which link it is a source or a target



7.31. scope

• Defines the behavior of the environment of the activities

• Provides:

• Local variables

• Correlation sets

• Fault handlers

• Event handlers

• Compensation handlers



7.32. BPEL 2.0

7.33. Correlation

• All business process instances are published on the same URL, e.g.http://example.org/app/sampleprocess

• Question: how does a call finds the appropriate instance?

• Solution: information must be extracted from the call and it must me matched with the state of the process

(correlation)



7.34. property and propertyAlias

• property:

• what information to extract from the message

• WSDL extension, e.g.:

• propertyAlias:

• how to extract the information (typically by XPATH)

• at most one propertyAlias per propertyName-messageType pair

• WSDL extension, e.g.:

7.35. correlationSets

• The correlationSets section defines the properties to be correlated, e.g.:

• The values of the properties are calculated by the propertyAliases

• Initialization and check of correlationSets are done at requests and replies

• Initialization must happen exactly once

• E.g.:

7.36. BPEL 2.0



7.37. faultHandlers

• Handling exceptions

• a process can throw or receive an exception the same way as it sends or receives normal WSDL outputs

and inputs

• there can be inner exceptions (throw)

• When an exception occurs, the execution of the scope is terminated

• catch branches:

• fault name

• what to do:

• may call compensation

• If the faultHandler succeeds, the execution is resumed after the scope

• the scope remains failed

7.38. BPEL 2.0



7.39. eventHandlers

• Like the pick activity, but accepts events during the execution of the process

• The activities are executed if the appropriate message arrives (correlation)

• Messages can arrive at any time: interrupt

• Repeating events can also be specified

7.40. BPEL 2.0



7.41. compensationHandlers

• Long-running transaction: rollback with inverse operation

• compensationHandlers: rolls back the activities of a successfully executed scope

• Compensation activity can be anything, however, typically it is a WS call to the inverse operation

7.42. Compensation sample



7.43. References

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

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

• http://www.oracle.com/technetwork/middleware/bpel/overview/index.html

8. 8 Business Process Modeling Notation (BPMN)

8.1. Outline

• BPMN

• BPMN and BPEL

8.2. Business Process Modeling Notation (BPMN)

8.3. BPMN

• Business Process Modeling Notation

• OMG standard

• Graphical modelling language

• Describes business processes

• No formal textual representation

• initiative (for exchange):XPDL (XML Process Definition Language)

• Can model the behavior of multiple participants

• Choreography

• Goal:

• better description and understanding of processes through a graphical notation

• should enable automatic execution

8.4. BPMN parts

• Participants

• Activities

• Events

• Gateways

• Connections



• Artifacts

8.5. Participants

• Participants in the process, e.g:

• human

• group of humans

• system

• process

• Types of participants:

• system participant

• e.g. database, web service, rule engine etc.

• human participant

• pl. clerk, manager, etc.

• process participant

8.6. Participants

• swimlane, pool

source: BPMN standard

8.7. Activities

• Activities are performed by the participants

• Task: atomic activity

• Structurally:

• simple



• compound: can be elaborated

• Execution:

• human: performed by a human being

• automated: performed by the system or a process

8.8. Activities


8.9. Activities

8.10. Events




8.11. Gateways




8.12. Connections


8.13. Artifacts




8.14. Sample


8.15. B2B sample




8.16. Complex sample


8.17. BPMN and BPEL

8.18. Concepts

• BPMN: Business Process Modeling Language

• OMG standard

• graphical modeling notation

• multiple participants

• choreography

• BPEL: Business Process Execution Language

• OASIS standard

• XML-based, executable

• usually has graphical support, however, it is not standardized

• from the point of view of a single participant



• orchestration

8.19. Concepts

• BPA: Business Process Analysis

• analyzing, designing and breaking up processes into subprocesses until atomic tasks

• BPM: Business Process Management

• managing, administration, monitoring and measuring business processes to improve their efficiency

• BPMS: Business Process Management System

• a system supporting BPM

• BAM: Business Activity Monitoring

• real-time measurement of business processes, deriving aggregated data and KPIs

• KPI: Key Performance Indicator

• important information from the business point of view

8.20. BPM Hourglass

Source: http://www.omg.org/news/meetings/workshops/soa-bpm-mda-2006/00-T4_White.pdf

8.21. BPMN and BPEL

• BPMN is a graphical notation, not always executable

• BPEL is an XML-based language, executable

• Task: automatic transformation of BPMN BPEL

• Defined in the BPMN standard

• There are a lot of common concepts in them

• However, BPMN is like a state-machine, while BPEL is structured

• Some BPMN constructs can only be transformed redundantly to BPEL



8.22. BPMN BPEL problem

8.23. Rewritten manually using links: unmaintainable

8.24. Automatic conversion causes redundancy



8.25. References

• http://www.bpmn.org/

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

9. 9 Enterprise Service Bus

9.1. Outline

• Defining the ESB

• Characteristics of an ESB

9.2. Defining the ESB

9.3. 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 when using asynchronous communication

• Easy to add new participants

• Typical use:

• within an enterprise

• as an Enterprise Service Bus (ESB)

9.4. Enterprise Service Bus (ESB)

• Not a standard, just a buzz-word

• Therefore: no official definition

• It is more like a product than an architectural pattern

• Implements the SOA in a bus topology



• Provides conversion between different protocols and data formats

• What follows: definitions from different software vendors

9.5. ESB

9.6. Microsoft

• An Enterprise Service Bus (ESB) is a shared messaging layer that gives you a consistent, scalable, and

flexible means of coordinating across disparate loosely connected services to execute business processes.

9.7. IBM

• An ESB provides the connectivity to implement a service-oriented architecture (SOA), reducing the

complexity of integrating applications and services. It supports event-based interactions as well as message

exchange for service request handling. An ESB:

• realizes interactions with people involved in the underlying business process.

• provides adapters to existing applications that have to be integrated.

• choreographs the interaction of several services to achieve a business goal.

• watches for potential problems in the execution of the process, ready to take action to fix them if they

occur.

• manages resources that are needed to perform required business functions.

9.8. Oracle

• An enterprise service bus moves data among multiple endpoints, both within and outside of an enterprise. It

uses open standards to connect, transform, and route business documents as Extensible Markup Language

(XML) messages, among disparate applications. It enables monitoring and management of business data, with

minimal impact on existing applications. An enterprise service bus is the underlying infrastructure for

delivering a service-oriented architecture (SOA) and event-driven architecture (EDA).

9.9. Oracle

• An ESB's main features are:

• It has a set of service containers, used to adapt a wide variety of IT assets to the ESB.

• It has a reliable messaging system, used to allow the service containers to interact.



• It has a standard (WSDL) services model is used for inter-container interaction. That is, all adapted assets

are modelled using services. An asset can be a provider of services, a consumer of services, or both. The

services model is based on message exchange.

• It uses messages that are exchanged between containers using standard message exchange patterns.

• It uses messages that consist of XML data, and message metadata.

• It provides message transformation services

• It provides message routing services

• It provides security features to control access to services

• It is centrally administered, despite being a distributed system.

• It allows incremental changes to services without requiring shutdown or other disturbance to system

availability.

9.10. JBoss

• The ESB is seen as the next generation of EAI [Enterprise Architecture Integration] - better and without the

vendor-lockin characteristics of old. As such, many of the capabilities of a good ESB mirror those of existing

EAI offerings. Traditional EAI stacks consist of:

• Business Process Monitoring

• Integrated Development Environment

• Human Workflow User Interface

• Business Process Management

• Connectors

• Transaction Manager

• Security

• Application Container

• Messaging Service

• Metadata Repository

• Naming and Directory Service

• Distributed Computing Architecture.

9.11. FuseSource

• The enterprise service bus - the central backbone of SOA infrastructure - enables organizations to achieve

integration affordably and effectively. In order to leverage existing systems and mediate relationships

between loosely coupled and uncoupled business components, the enterprise service bus must be dynamic and

adaptable, technology-neutral, and easy to adopt incrementally, allowing step-by-step deployment and

minimal disruption to existing functionality.

9.12. SearchSOA



• ESB can be thought of as a mechanism that manages access to applications and services (especially legacy

versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side

front ends.ESB does for distributed heterogeneous back end services and applications and distributed

heterogenous front-end users and information consumers what middleware is really supposed to do: hide

complexity, simplify access, allow developers to use generic, canonical forms of query, access and

interaction, handling the complex details in the background. The key to ESB's appeal, and possibly also its

future success, lies in its ability to support incremental service and application integration as driven by

business requirements, not as governed by available technology.

9.13. MuleSoft

• An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for

integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build

this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core

concept of the ESB architecture is that you integrate different applications by putting a communication bus

between them and then enable each application to talk to the bus. This decouples systems from each other,

allowing them to communicate without dependency on or knowledge of other systems on the bus.

9.14. Wikipedia

• An enterprise service bus (ESB) is a software architecture model used for designing and implementing the

interaction and communication between mutually interacting software applications in service-oriented

architecture (SOA). As a software architecture model for distributed computing it is a specialty variant of the

more general client server software architecture model and promotes agility and flexibility with regards to

communication and interaction between applications. Its primary use is in enterprise application integration

(EAI) of heterogeneous and complex landscapes.

9.15. Characteristics of an ESB

9.16. Common points in the definitions of the ESB

• Implements the SOA

• Characteristics of an ESB:

• bus topology

• connects services

• hides differences among underlying platforms, software architectures, and network protocols

• provides adapters between different protocols and data formats

• message transformation and routing

• reliable message delivery

• flexible service orchestration

• incremental implementation and deployment

• central monitoring and management

9.17. Capabilities of an ESB



source: Wikipedia


source: Wikipedia





source: Wikipedia

10. 10 SOA Frameworks

10.1. Outline

• Web Services Frameworks

• SOA Frameworks with ESB

10.2. Web Services Frameworks

10.3. Web Services Frameworks

• Microsoft: Visual Studio and Windows Communication Foundation on IIS Server

• IBM: Rational Application Developer and WebSphere Application Server

• Oracle: JDeveloper and WebLogic Server

• RedHat: Eclipse with JBoss Tools and JBoss Application Server using the Apache CXF stack

• ...

10.4. Microsoft

• Development Environment:Visual Studio

• Server:Internet Information Services (IIS)

• Web Services Stack:Windows Communication Foundation

• Configuration:custom configuration in web.config

• Supported protocols:



• SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-AtomicTransaction, WS-Security, WS-

SecureConversation, WS-Trust, WS-Federation

10.5. IBM

• Development Environment:Rational Application Developer (RAD)

• Server:WebSphere Application Server (WAS)

• Web Services Stack:JAX-WS implementation

• Configuration:WS-Policy




10.6. Oracle

• Development Environment:JDeveloper

• Server:WebLogic Server (WLS)

• Web Services Stack:JAX-WS implementation

• Configuration:WS-Policy




10.7. RedHat

• Development Environment:Eclipse with JBoss Tools plugin

• Server:JBoss Application Server (JBoss AS)

• Web Services Stack:JAX-WS implementation (Apache CXF)

• Configuration:WS-Policy and a custom Spring configuration file


• SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-Security, WS-SecureConversation, WS-Trust

(partial)

10.8. Comparison



10.9. SOA Frameworks with ESB and BPEL/BPMN

10.10. SOA Frameworks

• Microsoft: BizTalk

• IBM: WebSphere ESB

• Oracle: Fusion Middleware SOA Suite

• RedHat: JBoss ESB

• ...

10.11. Microsoft BizTalk architecture

10.12. IBM: WebSphere Architecture



10.13. Oracle: SOA Suite Architecture

10.14. RedHat: JBoss ESB Architecture



10.15. Comparison

11. 11 Model Driven Development

11.1. Outline

• Modeling framework

• UML profile

• UML model and its mapping to XSD, WSDL, WCF and JAX-WS

11.2. Modeling framework



11.3. Motivation

• WSDL is hard to maintain by hand

• WS-Policy standards are complicated

• Different SOA products require different configuration methods

• Matching these configurations is difficult

• Better to have a conceptual overview of the system

• Productivity can be increased by generating software artifacts

11.4. Goal

• Produce executable code

• Promote top-down development

• Two main directions:

• modeling in UML using a UML profile (this presentation)

• modeling in a DSL specifically designed for SOA

• Automatic generation of:

• XSD

• WSDL

• BPEL skeleton

• C and Java sources (stub, skeleton)

• complete projects for SOA tools

11.5. Tools

• Microsoft Visual Studio, WCF, C (WS)

• Sun GlassFishESB (WS and BPEL)

• Oracle JDeveloper, WebLogic (WS and BPEL)

• ActiveVOS (BPEL)

• IBM WebSphere, RAD (WS and BPEL)

• JBoss (WS)

• Apache Axis2, CXF (WS)

11.6. Tools' capabilities



11.7. Architecture of such a framework

11.8. UML Profile

11.9. UML profile

• XSD:

• namespace

• sequence, choice, all

• single inheritance

• WSDL:

• abstract: message, portType

• concrete: binding, service

• for BPEL: partnerLinkType

• BPEL:

• process

11.10. XSD profile



11.11. BPEL profile



11.12. UML Model

11.13. Namespaces, packages: UML



11.14. Namespaces, packages : XSD

11.15. Namespaces, packages : WSDL

11.16. Namespaces, packages : WCF



11.17. Namespaces, packages : JAX-WS

11.18. Custom types: UML



11.19. Custom types: XSD

11.20. Custom types: WCF



11.21. Custom types: JAX-WS (JAXB)

11.22. Contract: UML



11.23. Contract: XSD (2)



11.24. Contract: WCF

11.25. Contract: JAX-WS



11.26. Fault: UML

11.27. Fault: XSD (2)



11.28. Fault: WCF (1)

11.29. Fault: WCF (2)



11.30. Fault: JAX-WS (1)



11.31. Binding: UML

11.32. Service: UML





12. 12 SOA project management

12.1. Outline

• Project management

• SOA projects

• SOA project roadmaps

• Zachman Framework

• Gartner EA Process Model

• ZapThing's SOA Roadmap

• SOA maturity

• Business Process Interoperability Maturity (BPIM)

• Microsoft Service Oriented Architecture Maturity Model

• Gartner Assessment Framework

12.2. Project management

12.3. Project

• A project consists of a temporary endeavor undertaken to create a unique product, service or result.

• Properties:

• unique

• complex

• clear goals

• quality-oriented

• time constraint

• resource constraints

• risks

Source: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project

Management Institute.



12.4. Project management

• Project management is the discipline of planning, organizing, securing, managing, leading, and controlling

resources to achieve specific goals.

• Phases:

• inception

• define goals, participants, stakeholders, resources, deliverables

• planning and design

• break down activities, planning resources and time

• production and execution

• complete the work

• monitoring and controlling

• measure activities, perform corrective actions, communication

• closing

• finalize activities, evaluate results

Source:

A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management

Institute.

Chatfield, Carl. "A short course in project management". Microsoft.

12.5. SOA Projects

12.6. Specific requirements

• Independent organizations

• loose coupling between organizations

• organizational level interoperability

• different organization maturity levels

• Legacy systems

• heterogeneous platforms, reverse engineering

• Development during continuous operation

• "changing wheels while driving"

• Complex services (BPMN, BPEL)

• 7/24, persistency

• redundancy and robust storage - price!



• Summary: VERY COMPLEX systems

12.7. Consequences

• For long term - consider business goals

• Tied development of organization and IT

• Structure of project organization

• Motivation

• Clean architecture

• Longer preparation

• Multiphase, iterative, incremental development

• More complex lifecycle model - roadmap

12.8. SOA Roadmap

12.9. Roadmap

• Itinerary

• starting from actual state

• getting to a system, which

• serves business goals efficiently

• builds on reusable services

• meets all quality requirements

• All major vendors and consultants have roadmap-recommendations

12.10. Zachman framework

• Universal, structured cognitive framework

• two dimensions

• communication: who, what, when, where, how, why

• reification: contextual, conceptual, logical, physical, detailed

• Each cell defines a representation

• Goal: each cell has to be considered



12.11. Evaluating Zachman

• Suitable for formally describing any complex system

• Does not specify project steps or methodology

• Reference:John A. Zachman:John Zachman'sConciseDefinitionof theEnterpriseFramework,2008

ZachmanInternational,http://zachmaninternational.com/index.php/home-article/13 maincol

12.12. Gartner EA Process Model

• Gartner Group - leading IT analyst

• Approach: closing the gap between current and future state by iterative development

• Environmental trends

• general (economics, politics, culture, etc)

• IT trends

• Business strategy

• declaration

• implementation

• interaction with EA

• GAP analysis

• Detailed guides, best practices, rational approach

[R. Scott Bittler, Gregg Kreizman: Gartner Enterprise Architecture Process: Evolution 2005,

Gartner Research, 21 October 2005,



ID Number: G00130849,

http://www.idi.ntnu.no/emner/tdt4175/pdfs/GartnerEA.pdf]

12.13. ZapThink's SOA Roadmap

• Iterative, incremental

• Key problems

• data access is complicated

• applications want to access legacy databases

• clear presentation of KPIs is needed

• processes should be reorganized

• Experiments

• Maturity

• organization

• IT infrastructure

• IT organization

• Silos - in separate areas

• Pilot

• Transition and migration

• Reference:

• http://www.zapthink.com/2008/09/15/zapthink-soa-implementation-roadmap-30/

12.14. Simplified roadmap



12.15. SOA Maturity

12.16. Business Process Interoperability Maturity

• Analogue: Capability Maturity Model (CMM)

• 5 representative factors

• 5 levels of maturity

• Defined by: Australian Government

• Reference:http://agict.gov.au/policy-guides-procurement/interoperability-frameworks/bpif/bpif-appendix-d

12.17. BPIM Factors



12.18. Maturity levels

• Siloed - ad hoc

• local results, interoperability is hard

• Tactical collaboration

• connections between islands

• only point-to-point addressing dedicated tasks

• Re-use

• business processes, shared services

• Shared services

• services in focus, BPM

• Service oriented

• monitored, dynamic services

12.19. Maturity levels



12.20. Application



12.21. Microsoft SOA Maturity Model

• Maturity level:

• Basic: ad-hoc

• Standardized: defined

• Advanced: managed

• Dynamic: optimizing

• Domain:

• Administration

• Consumption (clients)

• Implementation (services)

• Reference:http://download.microsoft.com/download/9/d/1/9d1b5243-21f6-4155-8a95-

1f52e3caeeaa/SOA_Assessment-and-Roadmap_Datasheet_2007.pdf

12.22. Microsoft SOA Maturity Model



12.23. Gartner Assessment Framework

• Aimed at e-Government solutions

• 3 dimensions

• time

• complexity / cost

• community value

• must increase in each phase

• Areas

• strategy and policy

• people

• process

• technology



Documents

Service-Oriented Integration - tankonyvtar.hu · Created by XMLmind XSL-FO Converter. Service-Oriented Integration Goldschmidt, Balázs Simon, Balázs Szeberényi, Imre