Service Oriented Architecturecs.jyu.fi/el/tjtse56_11/TJTSE56_Syllabus_files/TJTSE56062011VilleS… · An example, Data-as-a-Service! Customer DB! Customer DB! JDBC API SELECT custName,

JYVÄSKYLÄN YLIOPISTO

Service Oriented Architecture!

TJTST21!Syksy 2010!

Ville Seppä[email protected] / 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?!



  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 business-

oriented!–  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!

Customer DB! Customer DB!

JDBC API

SELECT custName, custAddress FROM Customers WHERE custID = 21323;

ContactInfo PurchaseHistory

Favorites

Predefined reusable services No direct connection to db for the client

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)



  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!Order Entry (J2EE) CRM (DCOM)

Common technology subset

Common technology subset

Yet Another Application (RMI)

Two J2EE apps

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


Technology agnosticism!

Standardized Interface

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


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!

Application! Application!

SOAP

client!

SOAP

server!WSDL! WSDL!

describes + registers reads

communicates!

SOAP messages (envelopes) carrying the message payload

Technical service interface (+SLA, policies, etc.)

WSDL describes the service UDDI gives a services listing

Is accessed using SOAP


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!

Business Semantics

Security, Routing, Workflow,

Transaction Management

WSDL, UDDI SOAP, XML-RPC

XML, XML Schema HTTP, FTP, SMTP

Internet, Intranet, Exranet

Horizontal Standard

Horizontal (Non-)Standard

Vertical Non-Standard



  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!


PICMET´05! 36!

X-road Internet

SS AS

SS

SS AS

SS AS

SS

IS of Estonian Tax and Customs

Board

Services

Popula- tion

Register

Services

Estonian Motor

Vechicle Registration

Centre

Services

… other IS

for ex. MISP II

Information systems X-road centre

KIT (Citizens’ portal)

Information portal http://www.eesti.ee

Riik.ee (for civil servants)

CA of X-road

Centr.server I

Centr.server II (Elion)

Monitoring

SS

Central register of DBs

HELPDESK

Environments developed by government

SS AS

Banks

x 5 Hansa bank Union bank.

Kreditb. Sampo bank. Nordea bank

a) authent. b) payment c) services

SS

EIT (Enterpreneurs’ portal)

Information portal for enterpreneurs

AIT (Civil servants’ portal)

SS

ID-card

CA

Certification agency

AS

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

Documents

Service Oriented Architecturecs.jyu.fi/el/tjtse56_11/TJTSE56_Syllabus_files/TJTSE56062011VilleS… · An example, Data-as-a-Service! Customer DB! Customer DB! JDBC API SELECT custName,