SOA in the API World - Facades, Transactions, Stateless Services
Upcoming SlideShare
Loading in...5

SOA in the API World - Facades, Transactions, Stateless Services






Total Views
Views on SlideShare
Embed Views



8 Embeds 2,390 1918 358 82 15 8 6 2
http://mktg-new.local 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • <br /><iframe width="350" height="288" src="" frameborder="0"></iframe>
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Creative Commons Attribution-Share Alike 3.0 United States License

SOA in the API World - Facades, Transactions, Stateless Services SOA in the API World - Facades, Transactions, Stateless Services Presentation Transcript

  • SOA in the API World –Facades, Transactions, Stateless Services . . .Apigee@apigeeBrian Pagano@brianpaganoGreg Brail@gbrail
  • @brianpaganoBrian Pagano@gbrailGreg Brail
  • SOA’s Adventures in API-Land - RecapServices? I’ve got services! (Designing a Façade)Layers: Separation of Responsibility (which Transactions?)Do I make my services stateless?How to design internal APIs?Overview
  • Previously onSOA’s Adventures inAPI-Land…
  • Let’s make sure we’re all talking about the same thing.And let’s only talk about the core principles of SOA, notthe cruft that vendors have added on.Some product features have started to be thought of asnecessary for SOA.SOA recap
  • But SOA is about Service Oriented Architecture.Services are good.This taps into the deeper philosophy of breakingdown problems into components.Components are good.
  • A service oriented architecture might include,but does not require:• Heavyweight contracts• Service registries• Dynamic discoveryThese are product “features”.
  • Services? I’ve GotServices
  • You’ve got servicesNow you need to design a Facade
  • Avoid the forklift anti-pattern
  • What are your service consumers using?(Customers, partners, …)
  • What are your company goals for this API?revenue, reach, holding market share, re-using existing assets
  • Design a single, RESTful façade that looksoutside-inDon’t expose implementation complexity
  • Transformation OnboardingProtocol MediationBigSystemDBContentManagement SOAP JDBCAppAppDeveloperXMLRouting Authentication Traffic Mgmt Caching MonitoringAPI Facade
  • Be consistent
  • Do what developers are expecting.
  • Layers:Separation of Responsibility
  • What types of things should a proxy do?
  • What types of things would you not wantto do in a proxy?
  • Do I Make My ServicesStateless?
  • Yes. Make your services stateless.Unless you have a good reason not to.
  • But, what do we mean by “stateless”?State can be either data entity state or session/activitystate.
  • A stateless service never holds data or business domainstate.A stateless service minimizes holding any activity orprocessing state information. (Session data is especiallybad)
  • Consider a shopping cart:A. The client maintains the state and sends the whole thingback and forth every timeor:B. The server maintains the cart in memory via a temporary“session ID”, and the server empties the cart after someinactivityor:B. The server maintains the cart in a database via a permanent“shopping cart ID”
  • Plan A: Requiring the client to maintain all state – isimpracticalPlan C : Storing the state in a database – gives thedeveloper what they expect, and gives businessbenefits tooButPlan B: A “session” – was popular in the Web 1.0 erabut is unnecessary in today’s world of scalable andavailable databases
  • How To DesignInternal APIs
  • NoAre Internal APIs Just SOA?
  • Internal APIs are APIs which are not exposed tothe outside world.SOA is SOALet’s keep these things straight.
  • Design internal APIs with the same level ofconsumability as you would an externally-facing API.
  • Why should you use APIs rather than SOA as themodel for your internal services? You will want to use the same services for both mobile appsand your web apps You don’t know what kinds of device technology your API willneed to support in the future You don’t know what kinds of web app technology yourdevelopers will want to use in the future You do know that it will all change and you will have to adaptquickly
  • Down the road, who knows . . .What does “internal” mean anyway?Besides, you might use them again for adifferent audience.
  • In SumSOA still has uses in the API worldAn API layer is critical to meet today’s businessdemandsSometimes they work well togetherExpose functionality, not systems orimplementation complexity
  • Questions
  • THANK YOUQuestions and ideas