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

Transcription

1 Goldschmidt, Balázs Simon, Balázs Szeberényi, Imre

2 í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

3 Tartalom Service-Oriented Integration Service Oriented Architecture Outline Topic of the course System integration: within an enterprise System integration: among government agencies Task Requirements Service Oriented Architecture Service System integration: within an enterprise System integration: among government agencies Technology for implementing services Definition of SOA Official definition of SOA Definition of SOA Definition of SOA Definition of SOA Definition of SOA Definition of SOA Concepts in the definitions SOA myths and facts (Microsoft) SOA myths and facts (Microsoft) Principles of SOA (by Web Services Journal) Principles of SOA (by Web Services Journal) Best definition of SOA Requirements of software systems Requirements System Qualities Run-time Qualities Run-time Qualities Design Qualities User Qualities System integration topologies Typical topologies Direct communication Bus topology (indirect communication) Web services: WSDL Outline Web service Web service Web services WSDL (Web-Services Description Language) WSDL WSDL WSDL 1.1: types in XSD WSDL 1.1: abstract part WSDL 1.1: concrete part WSDL 1.1 MEP Equivalence of two interfaces WSDL 1.1 summary WSDL WSDL 2.0 summary JAX-WS JAX-WS JAX-WS sample: interface iii

4 2.19. JAX-WS sample: interface with annotations JAX-WS sample: implementation JAX-WS sample: client WCF WCF WCF sample: interface WCF sample: interface with Attributes WCF sample: implementation WCF sample: client References Web services: SOAP Outline Web service Web service Web services SOAP (Simple Object Access Protocol) SOAP history SOAP SOAP envelope SOAP SOAP SOAP binding style RPC/encoded RPC/literal Document/literal Document/wrapped WSDL SOAP 1.1 binding WSDL SOAP 1.2 binding JAXB JAXB JAXB JAXB Atomic types Custom bindings XML Schema support Packages and namespaces JAXB sample JAXB sample: list WCF DataContract WCF DataContract Atomic types Packages and namespaces WCF DataContract sample WCF DataContract sample: list References WS- standards Outline Integration requirements Integration within a company e-gov integration Requirements WS- standards Web service standards Messaging Security WS-Federation sample Reliable messaging WS-ReliableMessaging Transactions Metadata iv

5 4.15. WS- standards Asymmetric-key cryptography Asymmetric-key cryptography Asymmetric-key cryprography X.509 certificate X.509 certificate: public key X.509 certificate: private key Certificate hierarchy XML encryption, XML digital signature XML digital signature Steps of XML digital signature Collecting resources to sign Optional transformations Hash (message digest) Collecting references Canonicalization Signing Adding key information Adding optional information Packaging XML items Digital signature summary Result of the digital signature Checking digital signature Checking digital signature XML encryption Steps of XML encryption Select encryption algorithm Select/retrieve encryption key Encryption/exchange of keys Data to encrypt XML encryption summary Encryption process Steps of decryption Decryption summary X.509. certificates in Windows and in Java Certificate hierarchy Windows certificate store Java certificate store References Representational State Transfer (REST) Outline HTTP HTTP GET HTTP GET HTTP POST REST REST Goals of REST REST principles Identifying resources Identifying resources Linking things Processing URLs Standard operations on resources Standard operations Multiple data representation Stateless communication JAX-RS JAX-RS JAX-RS sample v

6 5.21. Calculator sample Parameters Param samples Result MessageBodyWriter MessageBodyWriter sample MessageBodyWriter sample MessageBodyWriter sample Calculator sample revisited HTTP methods, mime-types XML and JSON XML and JSON sample XML and JSON sample XML result JSON result REST client Jersey client Jersey client Jersey client main program WCF WCF for REST References Design and development guidelines for web services 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 Top-down design Exceptions Synchronous and asynchronous calls Stateless service Avoid implementation-specific parameters Granularity Overloading Responsibilities Paging large lists Changes Business Process Execution Language (BPEL) Outline Business processes Business processes Business process Business processes Designing business processes Automating business processes Typical business process patterns Basic Control Flow Patterns Business Process Execution Language (BPEL) BPEL BPEL process BPEL 1.1 structure BPEL 1.1 structure BPEL 2.0 structure BPEL 2.0 structure vi

7 7.17. BPEL import BPEL partnerlinks partnerlinks Sample BPEL variables BPEL Simple activities Sample Simple activities Structured activities flow scope BPEL Correlation property and propertyalias correlationsets BPEL faulthandlers BPEL eventhandlers BPEL compensationhandlers Compensation sample References Business Process Modeling Notation (BPMN) Outline Business Process Modeling Notation (BPMN) BPMN BPMN parts Participants Participants Activities Activities Activities Events Gateways Connections Artifacts Sample B2B sample Complex sample BPMN and BPEL Concepts Concepts BPM Hourglass BPMN and BPEL BPMN BPEL problem Rewritten manually using links: unmaintainable Automatic conversion causes redundancy References Enterprise Service Bus Outline Defining the ESB Bus topology (indirect communication) Enterprise Service Bus (ESB) ESB Microsoft vii

8 9.7. IBM Oracle Oracle JBoss FuseSource SearchSOA MuleSoft Wikipedia Characteristics of an ESB Common points in the definitions of the ESB Capabilities of an ESB Capabilities of an ESB Capabilities of an ESB Capabilities of an ESB SOA Frameworks Outline Web Services Frameworks Web Services Frameworks Microsoft IBM Oracle RedHat Comparison SOA Frameworks with ESB and BPEL/BPMN SOA Frameworks Microsoft BizTalk architecture IBM: WebSphere Architecture Oracle: SOA Suite Architecture RedHat: JBoss ESB Architecture Comparison Model Driven Development Outline Modeling framework Motivation Goal Tools Tools' capabilities Architecture of such a framework UML Profile UML profile XSD profile BPEL profile UML Model Namespaces, packages: UML Namespaces, packages : XSD Namespaces, packages : WSDL Namespaces, packages : WCF Namespaces, packages : JAX-WS Custom types: UML Custom types: XSD Custom types: WCF Custom types: JAX-WS (JAXB) Contract: UML Contract: XSD (2) Contract: WCF Contract: JAX-WS Fault: UML Fault: XSD (2) Fault: WCF (1) Fault: WCF (2) viii

9 Fault: JAX-WS (1) Binding: UML Service: UML SOA project management Outline Project management Project Project management SOA Projects Specific requirements Consequences SOA Roadmap Roadmap Zachman framework Evaluating Zachman Gartner EA Process Model ZapThink's SOA Roadmap Simplified roadmap SOA Maturity Business Process Interoperability Maturity BPIM Factors Maturity levels Maturity levels Application Microsoft SOA Maturity Model Microsoft SOA Maturity Model Gartner Assessment Framework ix

10

11 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

12 1.5. Task Communication between applications Different programming languages Different operating systems Different software vendors Legacy systems Business processes Integration 1.6. Requirements Simple Standardized Independent of programming languages and operating systems Well supported and widespread technology Middleware aspects: reliable message delivery encryption, digital signature transaction handling Solution: Service Oriented Architecture 1.7. Service Oriented Architecture "SOAs are like snowflakes - no two are alike." David Linthicum 2

13 1.8. Service Basic building block of the architecture Publishes a resource or capability Has a well defined and standard interface Hides implementation details Should be a very thin layer Can wrap legacy applications Good design is essential: published functionality appropriate granularity reuse 1.9. System integration: within an enterprise 3

14 1.10. System integration: among government agencies 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) Definition of SOA 4

15 What is SOA? there are several definitions high level and low level different points of view: technical, business What follows: some definitions from a survey ofsearchwebservices.com discussion of the definitions 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 Definition of SOA "SOA is a framework enabling application functionality to be provided, discovered and consumed as reusable Web Services sets. While Web Services do not equal SOA, it's one of the enabling standards. SOA abstracts complexity and implementation details, making it an ideal architectural mindset to leverage functionality trapped within mainframe/midrange systems."scott Rosenbloom is chief strategist with WRQ Inc Definition of SOA "Service Oriented Architecture is nothing but business oriented architecture, which allows the flexibility of business applications, to become independent but collaborative, while providing their services. The applications under this architecture are both 'client' and 'server' at the same time with freely available services." Satheesan Kunnel, USWWI Definition of SOA "A service oriented architecture is an approach to design and integrate software in a modular method where each module is precisely a 'loosely coupled service' that is accessible over a network and has the capability of being dynamically integrated with other services at run time. A service must present a standard Interface (be it WSDL today) for its functionality and invocation methods while the real implementation of the service is not a concern of an SOA."Rajesh Dawar Definition of SOA "A pattern of design, development, deployment, and management of applications and software infrastructure and frameworks in which: Applications are organized into business units of work (services) that are (typically) network accessible Service interface definitions are first-class development artifacts Quality of service (QoS) characteristics (security, transactions, performance, etc.) are explicitly identified at design time 5

16 Software infrastructure takes active responsibility for managing QoS and enforcing policy for service access and execution Services and their metadata are cataloged in a repository Protocols and structures within the architecture are, optionally, based on industry standards (e.g., the emerging SOAP stack of standards)"randy Heffner, vice president, Forrester Research Inc Definition of SOA "Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocolindependent 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 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 SOA myths and facts (Microsoft) 6

17 1.21. SOA myths and facts (Microsoft) 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 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 Best definition of SOA "Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocolindependent 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 Requirements of software systems Requirements 7

18 1.27. System Qualities Supportability is the ability of technical support personnel to install, configure, and monitor computer products, identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service. Testability is the degree to which a software artifact supports testing in a given test context 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 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 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. 8

19 Maintainability involves a system of continuous improvement - learning from the past in order to improve the ability to maintain systems, or improve reliability of systems based on maintenance experience. Reusability defines the capability for components to be suitable for use in other scenarios 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 System integration topologies Typical topologies Direct communication Bus topology (indirect communication) Direct communication connections for N participants data conversion Poor maintainability Every participant must provide high availability Hard to add new participants 9

20 Typical use: between different enterpises published as web services 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 10

21 WSDL 1.1 WSDL 2.0 Web service APIs: JAX-WS, WCF 2.2. Web service 2.3. Web service WSDL = Web-Services Description Language SOAP = Simple Object Access Protocol UDDI = Universal Description, Discovery and Integration 2.4. Web services Definition: service available through SOAP messages Message format: SOAP = Simple Object Access Protocol Versions: 1.1 and 1.2 Interface descriptor: WSDL = Web-Services Description Language Versions: 1.1 and 2.0 Service repository: UDDI = Universal Description, Discovery and Integration Versions: 2.0 and

22 2.5. WSDL (Web-Services Description Language) 2.6. WSDL Web Services Description Language Descriptor for web services interface meta-data service address W3C Versions: 1.1 and WSDL

23 definitions: root element import: other WSDL types: used types XML schema (XSD) message: parameter list part: parameter porttype: interface operation: function input: input parameters output: output parameters 13

24 fault: exception binding: calling convention protocol, data format, encoding service: implementation port: location of the service with the given binding 2.8. WSDL 1.1: types in XSD 2.9. WSDL 1.1: abstract part WSDL 1.1: concrete part 14

25 2.11. WSDL 1.1 MEP MEP = Message Exchange Pattern Depends on the input/output parameters 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 WSDL 1.1 summary 15

26 2.14. WSDL 2.0 Not yet widespread and not yet widely supported Simpler than version 1.1 Root: description instead of definitions There is import and include Reduced redundancy: no message Reusable bindings interface instead of porttype (Multiple) inheritance among interfaces WSDL 2.0 summary 16

27 2.16. JAX-WS 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 JAX-WS sample: interface JAX-WS sample: interface with annotations 17

28 2.20. JAX-WS sample: implementation JAX-WS sample: client wsimport generates CalculatorService Client code: WCF 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 18

29 2.24. WCF sample: interface WCF sample: interface with Attributes WCF sample: implementation WCF sample: client SvcUtil generates CalculatorClient Client code: 19

30 2.28. References SOAP standard: WSDL standard: Web Services Tutorial: 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 20

31 WSDL = Web-Services Description Language SOAP = Simple Object Access Protocol UDDI = Universal Description, Discovery and Integration 3.4. Web services Definition: service available through SOAP messages Message format: SOAP = Simple Object Access Protocol Versions: 1.1 and 1.2 Interface descriptor: WSDL = Web-Services Description Language Versions: 1.1 and 2.0 Service repository: UDDI = Universal Description, Discovery and Integration Versions: 2.0 and SOAP (Simple Object Access Protocol) 3.6. SOAP history Originally: Microsoft SOAP = Simple Object Access Protocol 21

32 XML-based RPC Today: W3C Versions: 1.1 and 1.2 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: 22

33 WSDL namespace: HTTP request: POST [local URL] HTTP/1.1Content-Type: text/xml; charset="utf-8"soapaction: [Action] SOAPAction is mandatory SOAP 1.2 SOAP message namespace: WSDL namespace: 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 SOAP binding style Defines the encoding style of the parameters Styles: RPC/encoded RPC/literal Document/encoded (not implemented) Document/literal Document/wrapped (recommended) RPC/encoded 23

34 3.13. RPC/literal Document/literal Document/wrapped 24

35 3.16. WSDL SOAP 1.1 binding WSDL SOAP 1.2 binding JAXB 25

36 3.19. JAXB Java Architecture for XML Binding JSR-222 Why? XML handling: SAX, DOM SAX: event-driven, serial access, fast, small memory footprint DOM: builds a tree representation in memory, the tree is changeable, and can be validated Problems: they are too general access is not statically typed no compile-time check JAXB Mapping between XSD and Java Annotations Model: [fragile] JAXB Specification: Subset of XML Schema Default mappings: XML names Java names Schema atomic types Schema structured types Java types Java classes 26

37 Java package: javax.xml.bind Compiler: XML Schema-to-Java Compiler (xjc) Part of the JDK: Atomic types 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) XML Schema support 27

38 Some XML Schema constructs are not supported: wildcard types any, anyattribute identity-constraints: key, keyref, unique other constraints: restriction Packages and namespaces JAXB sample JAXB sample: list 28

39 3.28. WCF DataContract WCF DataContract Mapping between.net types and XML Schema Metadata on classes:.net attributes Similar to JAXB Atomic types Packages and namespaces 29

40 3.32. WCF DataContract sample WCF DataContract sample: list References SOAP standard: WSDL standard: 30

41 Web Services Tutorial: 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 31

42 Integration within a company transactions e-gov integration, integration between companies: security: encryption, digital signature reliability: no messages are lost Standardized solution 4.6. WS- standards 4.7. Web service standards 4.8. Messaging WS-Addressing: 32

43 SOAP headers: Action To From ReplyTo FaultTo MessageId RelatesTo MTOM (Message Transmission Optimization Mechanism): efficient byte transfer as MIME attachment 4.9. Security WS-Security: encryption, digital signature WS-SecureConversation: symmetric-key crypto (analogy: SSL) WS-Trust: issuing tokens (analogy: Kerberos) WS-Federation identity management between trusted domains single sign-on 33

44 4.10. WS-Federation sample 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, WS-ReliableMessaging 34

45 Source: OASIS WS-RM standard Transactions WS-Coordination: managing transactions WS-AtomicTransaction: short term transaction 2PC WS-BusinessActivity: long running transaction rollback: compensation 35

46 4.14. Metadata WS-Policy: describes the capabilities of the service extends the WSDL e.g.: WS-Security Policy WS-ReliableMessaging Policy WS-AtomicTransaction Policy WS-MetadataExchange: retrieving WSDL exchanging Policy information dynamic protocol discovery WS- standards 36

47 4.16. Asymmetric-key cryptography 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 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 37

48 4.19. X.509 certificate Contents: Subject: the owner, for whom the certificate has been issued Issuer: the one who vouches for the validity of the certificate by his own digital signature Serial number: assigned by the issuer Valid from/to: validity time Thumbprint: this is signed by the issuer Public key: the public key Private key: the private key X.509 certificate: public key 38

49 4.21. X.509 certificate: private key 39

50 40

51 4.22. Certificate hierarchy XML encryption, XML digital signature 41

52 4.24. XML digital signature Digital signature in XML Namespace: Specification: 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 Collecting resources to sign What to sign? Example: Website: Picture on the web: Referenced element in an XML on the web: sender1 Referenced element in the current XML: elem Optional transformations 42

53 Optional transformation of the resources Examples: binary data to BASE64 XML transformation with XSLT The result of the transformation will be signed 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) Collecting references Putting references together: SignedInfo Selecting canonicalization and signature algorithm This SignedInfo element will be signed Example: Canonicalization Normalizing SignedInfo element before signing it 43

54 Why? a a and a are the same White-space problems(e.g. a or a ) Namespace declarations and prefixes Comments 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 SHA 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 Adding optional information Adding optional information E.g. time-stamp: 44

55 Packaging XML items Packaging everything into a Signature element: Digital signature summary Result of the digital signature 45

56 4.37. Checking digital signature 1. Transform the resources and calculate their hashes 2. Check the hashes with the ones in the SignedInfo element 3. Normalize the SignedInfo element with the canonicalization algorithm 4. Create the hash of the SignedInfo element 5. Check the validity of the SignatureValue using the public key Checking digital signature XML encryption Encryption in XML 46

57 Namespace: Specification: 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 Select encryption algorithm No stream encryption algorithms in the standard But there are block-encryption algorithms: 3DES AES-128 AES-256 AES 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 Encryption/exchange of keys Key encrypted with an asymmetric key: RSA-v1.5 47

58 Key determined by a key-exchange algorithm: Diffie-Hellman Key encrypted with a symmetric key: 3DES AES-128 AES-256 AES 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 XML encryption summary Encryption process 48

59 4.47. Steps of decryption 1. Identify the decryption algorithm and key information 2. Retrieve the key (if it is encrypted then recursively continue from step 1) 3. Decrypt the contents of CipherData Decryption summary X.509. certificates in Windows and in Java Certificate hierarchy 49

60 4.51. Windows certificate store 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 References 50

61 WS-Addressing: WS-ReliableMessaging: WS-Security: WS-Transaction: Representational State Transfer (REST) 5.1. Outline HTTP REST JAX-RS 5.2. HTTP 5.3. HTTP GET 5.4. HTTP GET 51

62 5.5. HTTP POST 5.6. REST 5.7. REST REpresentational State Transfer RESTful HTTP HTTP protocol extension GET, POST, PUT, DELETE Input parameters: URL part URL query string POST parameter HTTP body Result: HTTP body Very simple: testable by browser 5.8. Goals of REST Scalability of component interactions Generality of interfaces Independent deployment of components Intermediary components to reduce latency, enforce security and encapsulate legacy systems 52

63 5.9. REST principles Identifying resources Linking things CRUD operations Multiple data representation Stateless communication [fragile] 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: 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. but they can be used correctly, e.g 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.) 53

64 5.12. Linking things URLs must be chosen carefully Has a lot of advantages: easy to forward resource behind it can be accessed later analogy: C++ pointers more secure: easier to configure access rights to the resource 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 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 Standard operations 54

65 POST: the servers assigns the identifier PUT: the client assigns the identifier [fragile] 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: 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 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 JAX-RS JAX-RS JAX-RS: Java API for RESTful Web Services (JSR-311) Mapping Java classes to REST resources 55

66 Java annotations Implementations: official (Sun-Oracle): Jersey JBoss: RESTeasy Apache CXF Restlet [fragile] 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 class ApplicationConfig extends javax.ws.rs.core.application Calculator sample [fragile] Parameters URI template parameter (part of the URI query URI matrix parameter 56

67 @FormParam: POST Cookie 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] @PostParam 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 57

68 e.g. String is, Double is not solution: implement the following interfaces: MessageBodyReader MessageBodyWriter [fragile] MessageBodyWriter MessageBodyWriter sample MessageBodyWriter sample 58

69 5.28. MessageBodyWriter sample Calculator sample revisited HTTP methods, mime-types HTTP method annotations: 59

70 @HEAD HTTP content-type what kind of inputs the operation what kind of outputs can the operation produce 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 XML and JSON sample XML and JSON sample 60

71 5.34. XML result JSON result 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] 61

72 5.37. Jersey client import com.sun.jersey.api.client.client; import com.sun.jersey.api.client.webresource;import com.sun.jersey.api.client.config.clientconfig;import com.sun.jersey.api.client.config.defaultclientconfig;import javax.ws.rs.core.mediatype; Jersey client Jersey client main program WCF 62

73 [fragile] 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: [fragile] References fielding/pubs/dissertation/top.htm 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 63

74 Interface design guidelines 6.2. WSDL version WSDL 1.1 redundant widespread well supported WSDL 2.0 richer: interface inheritance, reusable bindings not very supported Recommendation: WSDL 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 64

75 XSD separated and included into the WSDL Recommendation: separated WSDL is smaller and simpler XSD is reusable 6.6. XSD constraints Advantages: interface is stricter checked at message level Disadvantages: cannot be mapped to Java/C APIs have to be maintained Recommendation: do not use them, check at application level 6.7. Common types and common code Types generated from XSD and WSDL Should be used on client and server side Vendor tools usually generate client side Recommendation: generate the client files put them in a separate project always use the same project for the same XSD even if referenced from multiple WSDLs add this project to the server and client side as a dependency 6.8. Top-down or bottom-up development Bottom-up/Implementation-first: started from program code rapid development WSDL is not stable Top-down/Contract-first: started from WSDL WSDL has to be constructed somehow 65

76 WSDL is stable: required for interoperability Recommendation: top-down 6.9. API Programming API for web services Recommendation: Java world: Java API for XML-based Web Services (JAX-WS).NET world: Windows Communication Foundation (WCF) Both of them are type safe They map classes to XSD types, interfaces to WSDLs JAX-WS implementations have WS- extensions WCF supports WS- by default Interface design guidelines 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 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 66

77 6.13. Synchronous and asynchronous calls Synchronous call: client waits for the result Asynchronous call: client starts the process and continues Do not mix synchronous and asynchronous calls in a single interface Define separate interfaces instead Long running activities with synchronous calls: start the activity in background or throw an exception return immediately from the operation the client can access/get the result later 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 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 Granularity Fine-grained operations: each query returns a small portion of data lot's of calls are required Coarse-grained operations: 67

78 a single query returns all the data lot's of unnecessary data transferred Recommendation: use general, reusable operations lean toward coarse-grained operations, since the network overhead may be large Overloading Overloading: same operation name with different parameter types Do not use overloading in interfaces Do not use templates and generics in interfaces 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 Paging large lists If large lists are returned, provide paging for the results State must be preserved somewhere 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 68

79 7.3. Business processes Simple services Aim: more complex services business processes Questions: How to describe business processes? How to automate execution? What are the typical process patterns? 7.4. Business process A business process connects tasks in order to reach the desired effect Types of business processes: Management process: controls system operation Operational process: basic process of an organization producing the primary value Supporting process: supports basic processes Business processes can be split up to smaller processes 7.5. Business processes Business process analysis: breakdown of processes into subprocesses until elementary tasks Development steps: identifying processes documentation implementation change management systematic organization 7.6. Designing business processes Key questions: Who? Who are the participants? 69

80 Which? Which tasks and activities build up the process? What? What kind of entities and data does the process operate on? When? When does it start or stop? What order? What is the order of the tasks and activities? Why? What is the value the process produces? 7.7. Automating business processes Goal: executing business processes by computers Advantages: speed consistency quality improvement Requirement: formalized description (e.g. BPMN, BPEL) 7.8. Typical business process patterns Source: 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 70

81 2. Parallel Split 3. Synchronization 4. Exclusive Choice 5. Simple Merge Business Process Execution Language (BPEL) 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 BPEL process Executable Describes: activities order of execution data partners exception handling long running transactions BPEL 1.1 structure 71

82 7.14. BPEL 1.1 structure BPEL 2.0 structure 72

83 7.16. BPEL 2.0 structure BPEL

84 7.18. import Using WSDL and XSD files: BPEL

85 7.20. partnerlinks Defines the provided and consumed web services References a partnerlinktype WSDL extension Roles: of the process: myrole of the partner: partnerrole partnerlinks 75

86 7.22. Sample BPEL

87 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 BPEL

88 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 Sample 78

89 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 Structured activities Sequence serial execution Switch (BPEL 1.1), If (BPEL 2.0) conditional branching While repeating activities Pick 79

90 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) flow Parallel execution Directed acyclic graph vertices: activities edges: links Each activity defines: for which link it is a source or a target 80

91 7.31. scope Defines the behavior of the environment of the activities Provides: Local variables Correlation sets Fault handlers Event handlers Compensation handlers 81

92 7.32. BPEL Correlation All business process instances are published on the same URL, e.g. 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) 82

93 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.: 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.: BPEL

94 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 BPEL

95 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 BPEL

96 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 Compensation sample 86

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

98 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 88

99 compound: can be elaborated Execution: human: performed by a human being automated: performed by the system or a process 8.8. Activities source: BPMN standard 8.9. Activities Events 89

100 source: BPMN standard Gateways 90

101 source: BPMN standard Connections source: BPMN standard Artifacts 91

102 source: BPMN standard Sample source: BPMN standard B2B sample 92

103 source: BPMN standard Complex sample source: BPMN standard BPMN and BPEL 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 93

104 orchestration 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 BPM Hourglass Source: 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 94

105 8.22. BPMN BPEL problem Rewritten manually using links: unmaintainable Automatic conversion causes redundancy 95

106 8.25. References 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 96

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

108 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 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 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 SearchSOA 98

109 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 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 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 Characteristics of an ESB 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 Capabilities of an ESB 99

110 source: Wikipedia Capabilities of an ESB source: Wikipedia Capabilities of an ESB 100

111 9.20. Capabilities of an ESB source: Wikipedia SOA Frameworks Outline Web Services Frameworks SOA Frameworks with ESB Web Services Frameworks 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 Microsoft Development Environment:Visual Studio Server:Internet Information Services (IIS) Web Services Stack:Windows Communication Foundation Configuration:custom configuration in web.config Supported protocols: 101

112 SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-AtomicTransaction, WS-Security, WS- SecureConversation, WS-Trust, WS-Federation IBM Development Environment:Rational Application Developer (RAD) Server:WebSphere Application Server (WAS) Web Services Stack:JAX-WS implementation Configuration:WS-Policy Supported protocols: SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-AtomicTransaction, WS-Security, WS- SecureConversation, WS-Trust, WS-Federation Oracle Development Environment:JDeveloper Server:WebLogic Server (WLS) Web Services Stack:JAX-WS implementation Configuration:WS-Policy Supported protocols: SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-AtomicTransaction, WS-Security, WS- SecureConversation, WS-Trust, WS-Federation 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 Supported protocols: SOAP 1.1, SOAP 1.2, MTOM, WS-ReliableMessaging, WS-Security, WS-SecureConversation, WS-Trust (partial) Comparison 102

113 10.9. SOA Frameworks with ESB and BPEL/BPMN SOA Frameworks Microsoft: BizTalk IBM: WebSphere ESB Oracle: Fusion Middleware SOA Suite RedHat: JBoss ESB Microsoft BizTalk architecture IBM: WebSphere Architecture 103

114 Oracle: SOA Suite Architecture RedHat: JBoss ESB Architecture 104

115 Comparison Model Driven Development Outline Modeling framework UML profile UML model and its mapping to XSD, WSDL, WCF and JAX-WS Modeling framework 105

116 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 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 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) Tools' capabilities 106

117 11.7. Architecture of such a framework UML Profile UML profile XSD: namespace sequence, choice, all single inheritance WSDL: abstract: message, porttype concrete: binding, service for BPEL: partnerlinktype BPEL: process XSD profile 107

118 BPEL profile 108

119 UML Model Namespaces, packages: UML 109

120 Namespaces, packages : XSD Namespaces, packages : WSDL Namespaces, packages : WCF 110

121 Namespaces, packages : JAX-WS Custom types: UML 111

122 Custom types: XSD Custom types: WCF 112

123 Custom types: JAX-WS (JAXB) Contract: UML 113

124 Contract: XSD (2) 114

125 Contract: WCF Contract: JAX-WS 115

126 Fault: UML Fault: XSD (2) 116

127 Fault: WCF (1) Fault: WCF (2) 117

128 Fault: JAX-WS (1) 118

129 Binding: UML Service: UML 119

130 120

131 SOA project management 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 Project management 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. 121

132 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 Source: finalize activities, evaluate results 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 SOA Projects 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! 122

133 Summary: VERY COMPLEX systems 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 SOA Roadmap 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 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 123

134 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, maincol 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, 124

135 ID Number: G , 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: Simplified roadmap 125

136 SOA Maturity Business Process Interoperability Maturity Analogue: Capability Maturity Model (CMM) 5 representative factors 5 levels of maturity Defined by: Australian Government Reference: BPIM Factors 126

137 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 Maturity levels 127

138 Application 128

139 Microsoft SOA Maturity Model Maturity level: Basic: ad-hoc Standardized: defined Advanced: managed Dynamic: optimizing Domain: Administration Consumption (clients) Implementation (services) Reference: Microsoft SOA Maturity Model 129

140 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 130

141 131