SOA with Web Services in Practice. SOA with Web Services

Size: px

Start display at page:

Download "SOA with Web Services in Practice. SOA with Web Services"

Pauline Jordan
5 years ago
Views:

in Practice Nicolai M. Josuttis IT-communication.

continuously learning since 1962 Systems Architect,

telecommunication SOA experience for multiple years Focus:

systems >500 services >10 million service calls per day

1 in Practice Nicolai M. Josuttis IT-communication.com 03/ Nicolai Josuttis Independent consultant continuously learning since 1962 Systems Architect, Technical Manager finance, manufacturing, automobile, telecommunication SOA experience for multiple years Focus: bringing SOA into operation Telco: >50 international systems >500 services >10 million service calls per day Automotive: Business SOA (top-down) Project SOA (bottom-up)

2 3 Service Oriented Architecture: SOA An architectural paradigm way of thinking, style, value system e.g.: use lose coupling where appropriate for distributed processes multiple companies, business units, departments, systems involved over heterogeneous systems multiple platforms, programming languages,... that may be under control of different owners different schedules, budgets, priorities,... 4 SOA Key Concepts Loose Coupling Decouple dependencies to gain flexibility and fault tolerance Services Integrate business language into IT High interoperability Make it easy to connect and reorganize systems and capabilities

(heterogeneous) distributed environment Tasks: mandatory: Providing connectivity Data transformation (Intelligent)

3 5 Motivation for a Service Bus up to 25 individual connections no central management 8 connections to the bus central management possible 6 Enterprise Service Bus (ESB) Infrastructure to provide high interoperability in a (heterogeneous) distributed environment Tasks: mandatory: Providing connectivity Data transformation (Intelligent) routing Monitoring and logging optional ( value-added services ): Dealing with security Dealing with reliability Service management ESB

4 7 ESB Approaches Stupid network s and consumers care for intelligence Intelligent network s and consumers with simple adapters Different ESB approaches for: Level of decoupling, (intelligent) routing, Logging, monitoring, security, reliability, Message exchange patterns (synchronous or asynchronous) which has different technical and organizational consequences 8 ESB Approaches in Practice just a common protocol: contracts with value-added services: individual integration of interfaces: Consumer Consumer Consumer Consumer Consumer Consumer Contract Contract native Web Services possible EAI approach

5 Web Services 9 10 Web Services SOA infrastructure using Internet technology Web Servers provide services XML as interface language Driven by Microsoft and IBM and others Core Standards: (Web Services Description Language) g as service interface description SOAP (Simple Object Access Protocol) as message format UDDI (Universal Description, Discovery and Integration) as registry/broker ( yellow pages )

6 <types> <element name="getaddress"> <complextype><sequence> <element name="customerid" type="long"/> </sequence></complextype> </element>... </types> <message name="getaddressinput"> <part name="params" element="getaddress"/> <message name="getaddressoutput"> <part name="params" element="getaddressresponse"/> <porttype name="customerinterface" > <operation name="getaddress"> <input message="getaddressinput"/> <output message="getaddressoutput"/> <fault message="customernotfound"/> </operation> </porttype> 11 and SOAP (Extract) <types> <element name="getaddress"> <complextype><sequence> <element name="customerid" type="long"/> </sequence></complextype> </element>... </types> <message name="getaddressinput"> <part name="params" element="getaddress"/> <message name="getaddressoutput"> <part name="params" element="getaddressresponse"/> <porttype name="customerinterface" > <operation name="getaddress"> <input message="getaddressinput"/> <output message="getaddressoutput"/> <fault message="customernotfound"/> </operation> </porttype> SOAP Request <Body> <getaddress> <customerid> </customerid> </getaddress> <Body> SOAP Response <Body> <getaddressresponse> <address> <street>gaussstr. 29</street> <city>braunschweig</city> <zipcode>d-38106</zipcode> </address> </getaddressresponse> <Body> + <binding> + <service> + Namespaces 12 Web-Services Overview Platform Consumer Generator Runtime HTTP: SOAP: POST /customer11 HTTP/1.1 Host: soa-in-practice.com Content-Type: text/xml; charset="utf-8" Content-Length: t th nnnn <?xml version='1.0'?> <soap:envelop xmlns:soap=" <soap:body> <getcustomeraddress xmlns=" <customerid> </customerid> </getcustomeraddress > </soap:body> </soap:envelope> Generator ESB Platform Deployment Host: soa-in-practice.com Port: 80 Path: customer11

7 Web Services in Practice Web Services Standards see

8 15 Web Services Standards Profiles make Standards interoperable - by WS-I Web Services Interoperability Organization For example: Basic Profile 1.1 : additional requirements - 24 extensibility points - for a specific version - of the 5 core standards: XML 1.0, HTTP , SOAP 1.1, UDDI V2 see 16 Native definitions types message porttype/interface operation input output What Technical Interface Operations Data-Types May be partially specified in multiple files e.g data types in xsd files How Technical Protocol e.g. SOAP with document style binding service port/endpoint Where Hardwired IP Address e.g.

9 <types> <element name="getaddress"> <complextype><sequence> <element name="customerid" type="long"/> </sequence></complextype> </element>... </types> <message name="getaddressinput"> <part name="params" element="getaddress"/> <message name="getaddressoutput"> <part name="params" element="getaddressresponse"/> <porttype name="customerinterface" > <operation name="getaddress"> <input message="getaddressinput"/> <output message="getaddressoutput"/> <fault message="customernotfound"/> </operation> </porttype> <types> <element name="getaddress"> <complextype><sequence> <element name="customerid" type="long"/> </sequence></complextype> </element>... </types> <message name="getaddressinput"> <part name="params" element="getaddress"/> <message name="getaddressoutput"> <part name="params" element="getaddressresponse"/> <porttype name="customerinterface" > <operation name="getaddress"> <input message="getaddressinput"/> <output message="getaddressoutput"/> <fault message="customernotfound"/> </operation> </porttype> 17 Lifecycle 1. Design team specifies technical interface operations data types exceptions abstract file: 2. Infrastructure team specifies binding (protocol details) e.g. SOAP document literal/wrapped 3. Operation team specifies locations/endpoints Test&Integration QA Production concrete file: 18 Service Contract Description of a service more or less formal usually between a specific service provider and a specific service consumer Includes: Description what a service does (the semantics) Description how to use a service (the interface) The quality of a service (service level agreement, SLA) Availability (e.g. 24x7 ) Costs and limits (e.g. up to usages per day ) Performance (e.g. 80% of results in 0.5 seconds )

10 <types> <element name="getaddress"> <complextype><sequence> <element name="customerid" type="long"/> </sequence></complextype> </element>... </types> <message name="getaddressinput"> <part name="params" element="getaddress"/> <message name="getaddressoutput"> <part name="params" element="getaddressresponse"/> <porttype name="customerinterface" > <operation name="getaddress"> <input message="getaddressinput"/> <output message="getaddressoutput"/> <fault message="customernotfound"/> </operation> </porttype> 19 and Service Contracts files are inherently limited No semantic information No service level agreements (SLAs) Format modifications 1.1 and 2.0 are different Service Repository There are workaround/extensions Comments WS policies More sustainable: Specify services independent from infrastructure (in repositories) Generate files out of repositories 20 Web Services are Inherently Point-To-Point Connections Consumer 1 send requests to: Consumer 2 send requests to: ESB deployed at:

11 21 Load-Balanced s Consumer 1 send requests to: Consumer 2 send requests to: ESB deployed at: Load Balancer deployed at: deployed at: A B 22 ESB as Central Black Box Consumer 1 Consumer 2 Routing Monitoring ESB Security A B

12 23 Central Intelligence Effects Service Endpoints Consumer 1 Consumer 2 send requests to: send requests to: deployed at: Interceptor deployed at: Interceptor Routing Monitoring ESB Security Interceptor Interceptor deployed at: deployed at: A B 24 Web Services ESB s Might Internally Use Other Middleware Consumer 1 Consumer 2 send requests to: SOAP send requests to: SOAP deployed at: deployed at: Interceptor Interceptor App-Server MQ, JMS, JBI, App-Server Interceptor Interceptor SOAP SOAP deployed at: deployed at: A B

13 Bringing it all together Service Development Lifecycle Consumer1 Consumer2 Central Repository - domains - processes - contracts HTML Central Registry abstract full s service call Deployment Information abstract service call internal design time runtime

14 27 Service Development Lifecycle Rose Repository HTML Consumer1 Consumer2 Magic Draw Repository HTML Intermediate format: Signature SLA s URL for documentation Central Registry abstract full s service call service call Deployment Information abstract internal design time runtime 28 Service Development Lifecycle HTML Rose Consumer1 Consumer2 Repository Magic Draw Repository external HTML design time Intermediate format: Signature SLA s URL for documentation Deployment Information external Central Registry abstract full s abstract mapping service call service call internal runtime

15 Summary Model: Web Services in Practice Practice:

16 31 Problems with Web Services Open Standardization Leads to Standards that are not interoperable Low-level infrastructure For intelligent routing and management of services you need more Focus on technical aspects No inherent support for non-functional attributes Danger of harmonization trap There will be other infrastructures There will be multiple repositories 32 Web Services FAQ Should we use Web Services? What else: nothing (if you can avoid distribution, avoid it) proprietary solution self made What should we bear in mind using Web Services? Follow WS-I Basic Profile 1.1 Use SOAP protocol document/literal wrapped Don t expect everything to work, so be careful with new/special features provide resources to solve certain problems Don t use to specify service contracts Are we doing SOA when we use Web Services? You might only do JaBoWS (Just a Bunch of Web Services)

33 Web Services Summary Web Services are a de-facto standard Use it to provide standard

service modeling Web Services operate on a pretty low level Needs effort and/or tools to

technologies 34 Q&A Nicolai Josuttis www.it-communication.com josuttis@it-communication.

17 33 Web Services Summary Web Services are a de-facto standard Use it to provide standard interfaces Web Services only care for technical aspects Don t use it as a starting point for service modeling Web Services operate on a pretty low level Needs effort and/or tools to provide intelligent ESBs Web Services are just a current technology Be prepared for other technologies 34 Q&A Nicolai Josuttis josuttis@it-communication.com Gaussstr. 29 D Braunschweig Germany Tel.: / / / JOSUTTIS

Web Services. Lecture I. Valdas Rapševičius. Vilnius University Faculty of Mathematics and Informatics

Web Services. Lecture I. Valdas Rapševičius. Vilnius University Faculty of Mathematics and Informatics Web Services Lecture I Valdas Rapševičius Vilnius University Faculty of Mathematics and Informatics 2014.02.28 2014.02.28 Valdas Rapševičius. Java Technologies 1 Outline Introduction to SOA SOA Concepts: