Service Oriented Architecture!

Service Oriented Architecture! TJTST21! Syksy 2010! Ville Seppänen! ville.seppanen@jyu.fi / AgD525.1!

What is a Service Oriented Architecture?! Depends on who you ask! Web Services! A technical architecture! An evolution of distributed computing and modular programming! An IT strategy based on a philosophy of sharing IT services with the aim of achieving business agility! All about business-it alignment!

Stupid Overused Acronym?!

What is a Service Oriented Architecture?! From a more practical point of view, the idea is to add an additional layer of abstraction upon to (existing) programmatic applications that renders their functionality as services! Services are typically fairly coarse-grained and businessoriented! Reusability is essential: We took designs and held them up to the light. We asked, if we built it, how much reuse would we get? G. Glass, BT Chief Architect!

An example, Data-as-a-Service! SELECT custname, custaddress FROM Customers WHERE custid = 21323; JDBC API Predefined reusable services No direct connection to db for the client ContactInfo PurchaseHistory Favorites Customer DB! Customer DB! SOA is about raising the level of abstraction so that requirements and business process can be discussed in a language understood by business people as well as IT folk (Graham, 2008)

What is a Service Oriented Architecture?! SOA organizes enterprise IT around services rather than applications! Discrete functions contained in enterprise applications become interoperable, standards based services that can be combined and reused quickly to meet business! Application functionality, components, data, processes,, even people! Because of their independent, modular nature, services can be used like building blocks to quickly and easily develop new business processes and composite applications, which can be simultaneously reused and deployed across multiple delivery channels! Services as the points of integration!

SOA solution stack http://www.ibm.com/developerworks/websphere/techjournal/0806_radcliffe/0806_radcliffe.html!

SOA gets too complicated. Lets use JBOWS architecture instead.! As we found in the recent Webservices.org survey, there were, out of 1,000 companies, only 50 that really were well advanced in their deployments, that could be considered true SOA sites.! Not orchestrated, does not have a registry, has no process-based testing, does not reuse services, and has no management tools. J. McKendrick!

Driven by the business needs! Combined loosely coupled services to support business requirements directly! Resources are made available to service consumers in the network as independent! Elevating the level of abstraction so that requirements and business process can be discussed in a language understood by business people as well as IT folk!

Technology agnosticism! Essential from the viewpoint of integration! Standards as the answer to interoperability problems?! The problem remains as there are too many ʻstandardsʼ: different programming languages and conventions, development environments, operating systems, technology platforms, etc.! Order Entry (J2EE) CRM (DCOM) Common technology subset Common technology subset Two J2EE apps Yet Another Application (RMI)

Technology agnosticism! The idea of loose coupling is to standardize the interface and not the implementation! Somewhat similar approach is used in the most EAI products as well (adapters)! Standardized Interface

Loose coupling! The key to SOA is that the services are made loosely coupled! W3C Glossary: Coupling is a dependency between interacting systems! Real dependency is the set of features or services that a system consumes from other systems. The real dependency always exists and cannot be reduced! Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Artificial dependency always exists but it or its cost can be reduced!

Loose coupling! The main goal of loose coupling is to minimize the amount of artificial dependency!

Tight vs. Loose coupling! Tightly Coupled! Loosely Coupled! Interaction! Synchronous! Asynchronous! Messaging Style! RPC! Document! Message Paths! Hard Coded! Routed! Technology Mix! Homogeneous! Heterogeneous! Syntactic Definition! By Convention! Published Schema! Bindings! Fixed and Early! Delayed! Semantic Adaptation! By Re-coding! Via Transformation! Software Objective! Efficiency! Broad Applicability! Consequences! Anticipated! Unexpected!

Four steps to SOA! Decompose the existing processes and siloed systems to their structural elements! Identify the reusable and frequently needed components! Create a pool of reusable service components! Base new applications and processes on these components using orchestration technologies (e.g., WS-BPEL)!

Or twelve steps by Dave Linthicum! 1. Understand your business objectives and define success! 2. Define your problem domain! 3. Understand all application semantics in your domain! 4. Understand all services available in your domain! 5. Understand all information sources and sinks available in your domain! 6. Understand all processes in your domain! 7. Identify and catalog all interfaces outside of the domain you must leverage (services and simple information)! 8. Define new services and information bound to those services! 9. Define new processes, as well as services and information bound to those processes! 10. Select your technology set! 11. Deploy SOA technology! 12. Test and evaluate! There is plenty to do to tackle the Step 1 alone. And no, when crea8ng SOA, you re not supposed to start from the Step 10!

Web Services! Business data as XML messages! Sent in a SOAP body! Enriched with metadata in SOAP headers! Described in WSDL and XML schema! Configured through WS-Policy (security, SLA, QoS)! Registered in UDDI registry, discovered using WS-Discovery!

Web Services! UDDI gives a services listing WSDL! UDDI! WSDL describes the service Technical service interface (+SLA, policies, etc.) WSDL! reads Is accessed using SOAP describes + registers Application! SOAP client! communicates! SOAP server! Application! SOAP messages (envelopes) carrying the message payload

WSDL! Web Services Description Language! A document written in XML that describes a Web Service! Specifies the location of a service and the methods the service exposes, as well as the structure of messages to be transfered and corresponding data types! Without WSDL, the calling syntax must be determined from a documentation prior to execution! With WSDL, the generation of proxies for Web Services can be automated in a language and platform independent way!

UDDI! Universal Description, Discovery and Integration! An open industry initiative sponsored by Organization for the Advancement of Structured Information Standards (OASIS)! Either public or private registry that can be used to publish and discover service listings! Contains information about the service provider, service metadata and technical instructions for the use of service!

UDDI! Registry contains three components for different types of information! White Pages: Providerʼs addresses, contant information, identifiers! Yellow Pages: Industrial categorization based on standard taxonomies (e.g., branch of industry, geographical locations)! Green Pages: Technical information about the provided services (e.g., functions, network address)!

SOAP! An XML-based protocol for the communication between a client and a service! Originates in XML-RPC! Implementations available practically for every programming language! Defines! An envelope that encapsulates an XML message (payload)! Headers for additional functionality (e.g., security, transactions)! Data serialization for RPC and document-styled communications! Binding to a carrier protocol (usually HTTP)! Formerly known as Simple Object Access Protocol. Now just SOAP it is not simple and has nothing to do with objects.

SOAP (RPC)!

SOAP (Document)!

SOAP w/ attachments!

SOAP communication models! It is possible to implement different distributed applications on top of SOAP! Request/Response interaction style similar to object- ja procedure-oriented programming (RPC)! Asynchronous messaging similar to MOM systems (document style messaging)! Broadcasting! Forwarding via SOAP intermediaries (e.g., routing and caching)! Can use an additional functionality of messaging services and middleware (e.g., JMS, EBS)!

Advantages of WS technologies! Independent of programming language, platform, data models, etc.! Open standards! Some vendor-specific extensions! Should enable reasonably easy (and inexpensive) interoperability and integration over the boundaries of systems and organizations, and firewalls (HTTP)! Can be used to expose existing application functionality as a service!

WS Standards pyramid! Vertical Non-Standard Business Semantics Horizontal (Non-)Standard Security, Routing, Workflow, Transaction Management Horizontal Standard WSDL, UDDI SOAP, XML-RPC XML, XML Schema HTTP, FTP, SMTP Internet, Intranet, Exranet

On a side note, please read The Raise of Fall of CORBA by Michi Henning, ACM Queue, Vol. 4., Issue 5, June 2006 available at http://portal.acm.org/citation.cfm? id=1142044&coll=portal&dl=acm&cfid=515653495&cftoken=515653495! Depending on exactly when one starts coun8ng, CORBA is about 10-15 years old. During its life8me, CORBA has moved from being a bleeding- edge technology for early adopters, to being a popular middleware, to being a niche technology that exists in rela8ve obscurity. It is instruc8ve to examine why CORBA despite once being heralded as the next- genera8on technology for e- commerce suffered this fate. CORBA s history is one that the compu8ng industry has seen many 8mes, and it seems likely that current middleware efforts, specifically Web services, will reenact a similar history.

Tapaus X-Tee!

Tapaus X-Tee! Estonian Information Policy Framework valmistelu aloitettiin vuosituhannen vaihteessa. Keskeisinä tavoitteina seuraavat! Lainsäädännön modernisointi! Yhteistyö julkisen ja yksityisen sektorin välillä! Valtion ja kansalaisten välisen tiedonkulun ja viestinnän tukeminen! Tietoyhteiskuntaohjelmien tavanomaisten ongelmien ennakointi ja välttäminen!

Tapaus X-Tee! Viro on toistuvasti sijoittunut YK:n tekemien sähköisen hallinnon vertailututkimusten kärkipäähän! Sijalla 13 vuoden 2008 maailman E-Government Readiness Indexissä. Suomi sijalla 15.! Viron sähköisen hallinnon infrastruktuuri on rakennettu suurelta osin X-Tee (X-Road) konseptin päälle! Vuonna 2001 käynnistetty hanke, jonka tavoitteena luoda yleinen viitekehys julkisen hallinon ICT-palveluille! Taustalla State Information Systems Department of the Ministry of Economic Affairs and Communication ja Estonian Informatics Center!

Tapaus X-Tee! Rakentuu SOA-standardeille! Viestinvälityksessä järjestelmien välillä käytetään SOAP:ia! Adapterit kääntävät X-Road XML muotoillut viestit järjestelmien sisäisesti käyttämään muotoon ja tekevät mappauksen järjestelmäkohtaisiin tietomalleihin (tuloksena tavallisesti SQL-kysely)! Standardiratkaisuille valmiit adapterit, osa tapauskohtaisesti tehtyjä! Palvelut ja rajapinnat kuvattu WSDL:a käyttäen! Mahdollistaa jopa automaattisen koosteisten palvelujen (composite services) luonnin! Alkuun lähinnä tietokantakyselyjä, sittemmin myös sähköiset dokumentit SOAP-kirjekuoriin pakattuina!

IS of Estonian Tax and Customs Board Services Information systems Population Register Services Estonian Motor Vechicle Registration Centre Services other IS for ex. MISP II Banks x 5 Hansa bank Union bank. Kreditb. Sampo bank. Nordea bank a) authent. b) payment c) services CA of X-road Centr.server II (Elion) X-road centre HELPDESK Monitoring Central register of DBs AS SS AS SS AS SS AS SS AS SS Centr.server I SS X-road Internet Information portal http://www.eesti.ee SS Information portal for enterpreneurs SS Riik.ee (for civil servants) SS ID-card KIT (Citizens portal) EIT (Enterpreneurs portal) AIT (Civil servants portal) CA Environments developed by government PICMET 05! Certification agency 36! Kalja, Reitsakas & Saard, 2005

Tapaus X-Tee! Kansalaisten tunnistaminen perustuu PKI-teknologiaa käyttävään (sähköinen allekirjoitus ja salaus) henkilökortiin ja pankkien tunnistautumisjärjestelmiin! Vrt. Suomi: toistakymmentä päällekkäistä tunnistautumisjärjestelmää, joiden kehittäminen on maksanut kymmeniä miljoonia ja joista yksikään ei ole levinnyt käyttöön! Virastot ja myös yksityiset toimijat voivat rakentaa X- Roadiin yhdistettyjen tietovarantojen päälle uusia palveluja! Käyttöoikeuksien säätely on rakennettu järjestelmään, joten sen toteuttaminen ei ole palveluntarjoajien eikä palvelujen vastuulla! Kansalaisella on pääsy julkisiin ja itseään koskeviin tietoihin, viranomaisilla pääsy tietoihin valtuuksiensa rajoissa jne.!

Tapaus X-Tee! Käytännössä kaikki viranomaisten tietokannat kytketty! Palveluja 700+ (2007)! Kustannukset ~1 000 000 (2005)! Ratkaisulla erinomainen penetraatio ja se on edullinen, joustava, avoin, perustuu standardeille, teknologiariippumaton, jne.! Miksi X-Road tai vastaavat mallit eivät ole yleisemmin käytössä?! Miten tilanne vertautuu yritysten tietojärjestelmien integrointiin?!