Presented to: SOA Brown Bag #10 By: SWIM Governance Team/ Jason Bloomberg, president of ZapThink...

Presented to: SOA Brown Bag #10

By: SWIM Governance Team/ Jason Bloomberg, president of ZapThink

Date: November 9, 2011

Federal AviationAdministration

System Wide Information Management (SWIM)

REpresentational State Transfer (REST)–Based Service Oriented Architecture (SOA)

2Federal AviationAdministration

REST-Based SOANovember 9, 2011

What is SOA?• SOA is an Information

Technology (IT) architecture that defines systems as collections of interoperable, reusable services

• SOA is a set of best practices for the organization and use of IT, and the discipline to follow them

• In particular, an architecture oriented toward Services

Services: Lego-‘Ilities’

• Interoperability

• Unbreakability

• Composability

• Reusability

What the Business wants from IT!What the Business wants from IT!

• Pros– Relatively mature– Supported by most enterprise

software– Transport protocol independent– Robust security & governance

capabilities• Cons

– Don’t guarantee interoperability– Loose coupling still a challenge– Verbose messages– Technical complexity

Pros & Cons of Web Services (WS)

Definition of REST• REpresentational State Transfer (REST) is a

style of software architecture for distributed hypermedia systems such as the World Wide Web

• Introduced and defined in 2000 by Roy Fielding in his doctoral dissertation

• Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification

• The WS family of standards and REST are architectural styles– Protocol-specific constraints on

architecture– Neither requires or is necessary

for SOA

• SOA is itself an architectural style of Enterprise Architecture

Architectural Styles

REST Myths• Myth: REST requires HTTPFact: It’s the verbs and links that matter, not the

transport protocolBut: The vast majority of REST is done with HTTP

• Myth: You have to choose between REST and WS Fact: Web Services Description Language (WSDL)

2.0 has a REST bindingBut: WSDL 2.0 is not widely adopted

• Myth: REST depends upon Secure Sockets Layer (SSL) for security, which is often insufficient

Fact: Open Authorization (Oauth), eXtensible Access Control Markup Language (XACML), even WS- Security family can be used with REST

But: REST security is largely “roll your own”

Essential REST Terminology• Resource

– An entity or capability on a network

• Uniform Resource Identifier (URI)– String that identifies a resource over a network

• Representation– Concrete manifestation of a resource

• Hypermedia– A style of building systems for accessing information

via a network of multimedia nodes connected by hyperlinks

What is a Resource?• Abstraction of an entity or capability you

wish to expose

• Anything you can give a URI to

• Common resources:– Static Web pages– Dynamic Web pages– Documents– Images– Rich media (videos, etc.)– Method/procedure/operation calls– WS

Uniform Interface• Clients interact with resources via a fixed set

of verbs:– GET

• Query the current state of the resource

• Idempotent

• Cacheable

– POST• Create/initialize a resource

– PUT• Update a resource

– DELETE• Delete a resource

PUT vs. POST: Initializing a Resource

Wrong: PUT /resource/{id}PUT /resource/{id}

201 Created

Location: /resource/{id}

201 Created

Location: /resource/{id}

POST /resourcePOST /resourceRight:

Problem: ensuring id is unique

What is a URI?• A string of characters used to identify a name or a

resource over a network (typically the Internet)

• URIs are either Uniform Resource Locators (URLs) or Uniform Resource Names (URNs)

• URL: http://www.zapthink.com

– Identifies the resource– Specifies the means of acting upon or obtaining the

representation

• URN: urn:isbn:0-471-76858-8

– Identifies resource by name in a particular namespace (identifier system)

– Doesn’t specify location or how to access resource

RESTful vs. Remote Procedure Call (RPC)-based URIs• RPC-based URL:

– http://example.com/cart/updateCart?cartID=47– Server-driven implementation– Lack of uniform interface introduces tight coupling

• RESTful URL:– http://example.com/cart/47– Client can try GET, POST, PUT, DELETE– Resource responds with appropriate self-describing

representations

What is a Representation?• Data (and corresponding metadata) that provide a

concrete manifestation of a resource• Resources typically have multiple representations• Often conform to standard Internet media types

(formerly called MIME types)• Examples:

– text/html– text/plain– application/xml– application/json– image/svg+xml

Content Negotiation

The client lists the formats (Media types) that it understands

GET /resourceAccept: text/html, application/xml, application/json

200 OKContent-Type: application/json

The server chooses the most appropriate one for the reply

What is Hypermedia?• A style of building

systems for organizing, structuring and accessing information via a network of multimedia nodes connected by hyperlinks

• For example, the World Wide Web

Four Architectural Constraints• Separation of resource

from representation

• Manipulation of resources by representations

• Self-descriptive messages

• Hypermedia as the engine of application state

Without all four of these you’re not doing REST!

Separation of Resource from Representation

• Resources are abstractions

• The means for maintaining state of resources should be invisible to users of resource

• Resource providers must hide limitations of underlying media/technology from users

Manipulation of Resources by Representations• A representation of a resource (including its

metadata) can provide sufficient information to modify or delete the resource on the server

– Provided client has permission

• Such representations contain contract metadata for the resource

Self-Descriptive Messages• Each message includes

enough information to describe how to process the message

• For example, which parser to invoke may be specified by an Internet media type

• Responses also explicitly indicate their cacheability

Hypermedia as the Engine of Application State• “HATEOAS”

• Client interacts with application entirely through hypermedia

• Representations reflect current state of app through hyperlinks

• Hyperlinks contain opaque references to persistent state on the server– State does not necessarily mean data stored in

representations

HATEOAS and URIs• Instead of having to learn all URIs a priori, the client

can extract URIs from links at runtime

• The server is free to change URIs or introduce new URIs on the same or some other server that provide a compatible behavior

• Links that a server returns in representations can be contextual, by directing what the client can do subsequently

• Links dynamically describe the contract between the client and the server in the form of a workflow at runtime

Contracted Services• Operations on resources are necessary but

not sufficient to define Service contract

• Each resource is responsible for returning contract metadata either for itself or for any resource it hyperlinks to

• Example: Web form

GET /formpageGET /formpage…<form action=“/order” method=“POST”><input……<form action=“/order” method=“POST”><input…

POST /order{data entered in form}POST /order{data entered in form}

Contract Metadata for REST• Hyperlinks that create workflow at runtime

• Contract metadata in representations that constrain further requests

• Media types (standard and custom)

• Namespaces

Essential REST-Based SOA Policies• All endpoints (clients, resources, topics) SHOULD

follow common URI format

• All requests and topics SHOULD be handled on the intermediary

• Intermediaries SHOULD resolve all URIs into physical endpoints

• Every resource SHOULD have a contracted representation (may have others as well)

• Payloads MAY be loosely typed, MAY contain hyperlinks, MAY conform to custom media types

Differences Between WS-Based SOA & REST-Based SOA

Contracts

Compositions

Handling State

Operations

Questions and Comments?

The SWIM.gov website describes the SWIM program and provides news announcements for current issues

It also contains key documentation, including select briefings, the SWIM Newsletter and the SWIM Q&A

There are several ways to learn more about SWIM

http://www.faa.gov/nextgen/swim

Presented to: SOA Brown Bag #10 By: SWIM Governance Team/ Jason Bloomberg, president of ZapThink...

Documents

Transcript of Presented to: SOA Brown Bag #10 By: SWIM Governance Team/ Jason Bloomberg, president of ZapThink...

Bloomberg Tutorial

swim fishy swim

Bloomberg Reference

Trading and Price Discovery · bloomberg markets, bloomberg news, bloomberg professional, bloomberg terminal and bloomberg.com. Absence of any trademark or service mark from this

Bloomberg SWPM

Copyright © 2009, ZapThink, LLC 1 Cloud Computing and SOA: Same but Different Ronald Schmelzer Managing Partner ZapThink LLC.

cds Bloomberg

Copyright © 2001, ZapThink, LLC Service Orient or Be Doomed! Ronald Schmelzer Senior Analyst ZapThink, LLC.

BLOOMBERG NEW ENERGY FINANCE SUMMIT - Bloomberg Finance LP · BLOOMBERG NEW ENERGY FINANCE SUMMIT In search of the miraculous Michael Liebreich ... Source: Bloomberg Intelligence,

Bloomberg Equity Indices Bloomberg SASB ESG

Bloomberg CSLite

Copyright © 2006, ZapThink, LLC 1 Achieving the “5 Nines” of Business Continuity in SOA Applications Jason Bloomberg Senior Analyst ZapThink, LLC.

the Media/2016/05 - May/2016.05.16...Bloomberg the Company & Its Products v Bloomberg Mækets Pursuits LUXURY TRAVEL Bloomberg Anywhere Remote Login Bloomberg Terminal Demo Request

Bloomberg Corporate Profile - SIG - Sourcing …sig.org/docs2/Procurements_Role_in_Third_Party_Risk_Management.pdf · Bloomberg Corporate Profile Bloomberg, the global business and

Bloomberg Manual

Copyright © 2007, ZapThink, LLC 1 SOA for eGov: Credentialing and Certification Ronald Schmelzer Following the ZapThink Roadmap ZapThink, LLC.

Practical SOA Pragmatic Approach for Vordel DRAFT€¦ · The ZapThink SOA Roadmap • An SOA roadmap provides a customizable, visual guide to SOA implementation • The ZapThink

GETTING STARTED Bloomberg Professional · About Bloomberg Professional Service About the Bloomberg Professional Service Bloomberg was founded in 1981 with one core mission : to bring

FINISH‚¹イムフィニッシュ Swim Finish スイムスキップ Swim Skip スタートチェック Start Check 試泳エリア Swim Trial Area スイムスタート Swim Start

Bloomberg Without Bloomberg