api and soa: two sides of the same coin?

Copyright © 2001-2013 SOA Software, Inc. All Rights Reserved.

API and SOA : Two sides of the

same coin?

Alistair FarquharsonCTO, SOA Software

Sachin Agarwal, VP Product MarketingSOA Software


Speakers

Alistair FarquharsonCTOSOA Software

Sachin AgarwalVP, Prod. MarketingSOA Software


API and SOA Resources

• Resource Center

– http://resource.soa.com/

• Webinar Recording

– http://resource.soa.com/resource/webinars

• Follow us on:

www.facebook.com/soasoftware

www.linkedin.com/company/soasoftware

@soasoftwareinc

http://resource.soa.com/resource/webinars



SOA


Key to Adoption

• Two keys:

– Interestingly it started off similarly to APIs – with the promise of new

revenue and the IoT was on the tip of everyone’s tongues.

– The fact is that, five/ten years ago the demand for IoT and Mobile was

almost non-existent compared to today.

– SOA turned inward, even though that was not the original goal

necessarily

– The promise of re-use drives businesses to a service orientation

– Standards adoption


Limitations

• It’s a complex world with complex issues and it requires support and

skills to do correctly. To do SOA right, you need the company behind

you, but there are massive payoffs and incredible success stories

• Since SOA became an integration technology, it had to become

sophisticated (I use that term on purpose)

– Security (WS-S*)

– Transactionality (WS-*)

– Multi-protocol

• The timelines associated with an ROI are long, simply because

projects are long and organizations are large

• A pragmatic reason: readability:


Common Components


SOA


Example - The SOA Catalog

• SOA was initially focused on UDDI, WSDL and SOAP.

• The idea was that the UDDI standard would provide a consistent way

to discover services and associated metadata.

• As a sign of things to come, the UDDI standard, while ratified, lost

support. I believe that this was due to:

– Inflexibility

– Human readability


UDDI - Technical and Inhuman(e)


The Repository

• Over time, the UDDI Registry has been replaced by the Repository

• Repositories are more flexible, typically template and workflow driven

• Repositories are focused on the development lifecycle

• Their goal is to guide development activities and provide visibility and

accountability in the SDLC process

• Now we are seeing API developer portals emerge to complement

internal repositories


SOA

SOA, in its focus on machine to machine integration and

standardization, has, in the past, forgotten about the human

in the equation.

This is changing.


API


Why APIs?


The API Portal

• The API Catalog approaches the problem from a completely different

direction based on its origins

– Consumer-facing

– Mobile/Web App consumer

• APIs continue the trend of human to human, rather than machine to

machine, interaction

• The developer is now the customer, rather than a participant

– A lack of enthusiasm for standards has forced a document-centric

approach, which is better for humans anyway

– The need for channel marketing has driven a portal design

– The need for developer engagement has improved utility


The Different Roles

Repository API Portal• Production• SDLC• Security• Inside

• Consumption• Promotion/Support• Provisioning• Outside

Both are required


The Need for Both

Production Consumption


Unified API Platform


The relationship between APIs and SOA


• API initiatives are the lucky ones:

– Business funding

– Green field

– Shifted center of gravity


Common Misconceptions

• APIs and Web Services are distinguished by the technology they use,

JSON vs. SOAP

• APIs have become the external interface to an organization while

Web Services have become components for internal collaborations


What is an API

• Has become a broader term than web service, it is not exclusive to

JSON/HTTP as some may lead us to believe

• Can utilize different data formats such as XML, SOAP, JSON, or plain

text

• Can utilize different transports such as WebSockets, HTTP, TCP,

MLLP, JMS, or MQ

• Does not exclude Web Services, SOAP, XML, JMS


Differentiating through Exposure

• The choice of technology should be dictated by the client:

– Web/JavaScript – JSON/HTTP, WebSockets

– Mobile – JSON/HTTP

– Java A2A – XML over the most relevant protocol

• You may need to expose multiple types depending on the channel


Simplifying the Landscape

• APIs are a superset of Web Services – it is a business differentiation,

not a technical one

– Business, product focus

– Shifted center of gravity

• You need a single platform that is flexible enough to handle multiple:

– Transports and Protocols

– Message types

– Descriptors and Documentation Standards


Sample Topology


What’s wrong with the API platform?


Wire Protocol

• APIs are typically JSON/REST

– Web/Mobile

• Web Services are typically XML/SOAP

– A2A Integration

• Management platforms need to cater to both. Typically, however, they

focus on one to the detriment of the other.


The Need for Both

• Depending on the consumer, APIs may need to be SOAP as well as

JSON/REST

• APIs regularly leverage backend SOAP services within an

organization

• The management platform therefore needs to:

• Understand both APIs and Services

• Mediate between SOAP/XML and

JSON/REST

• Understand the dependencies

between APIs and Services to

facilitate change management, root

cause alaysis etc.


Descriptor

• API developers ideally write detailed documentation, with samples

messages and code to communicate API details.

– Pro : Human readable

– Con : Change management is subjective

• Web Services primarily use WSDL and WS-Policy

– Pro : Change management is explicit

– Con : Difficult to understand


The Need for Both

• Effective change management and version control demands that the

API and Web Service are formally described in some way

– WSDL

– Swagger

– WADL

• The side benefits of this are:

– Document generation

– Code generation


Security

• APIs typically leverage OAuth or HTTP request signing mechanisms

for security

– Transport-based (HTTP)

– Device capable

• SOA leverages WS-S, SAML, WS-Trust, etc

– Message-based

– XML


The Need for Both

• Security mediation between web standards and WS-* standards is

critical

• A deep understanding of the different standards and policies is

required, including:

– OAuth 1.0a/2.0

– Header-based signature mechanisms

– SAML

– WS-Security

– XACML

• Token and identity mediation is critical


Summary

SOA, in its focus on machine to machine integration and

standardization, forgot about the human in the equation.

APIs, in their focus on ease of use, have forgotten about

management and control.

You need both


Successful APIs


There are three key components to making an API effort successful in

the long term.

Design

Implementation

Program Management

All of these require a comprehensive platform

Key Components

35


APIs are tip of the Iceberg!

Accelerate

Drive Monetize

Analyze


What does a Management Platform Provide

BusinessFoundation/FunctionalTier

Service Arch.LifecycleData arch.

Non-FunctionalTier

Security, Mediation, QoS, Analytics

ProtocolTier

Publishing, Oauth, etc.


Business Foundation/Functional Tier

• Service Rationalization, Reuse

• Lifecycle Management

• Change Management

• Impact Analysis


Non-Functional Tier

• Security

– Integration with Enterprise SSO/LDAP

– Message Security/Encryption

– Threat Protection

• Orchestration

• Monitoring

– Rate limiting

– QoS

– SLA

• Analytics


Protocol Tier

• SOAP

• JSON

• etc


The Unified SOA & API Platform

Analytics

Developer Engagement

Gateway Services

Service Integration

Lifecycle Management


API and SOA Resources

• Resource Center

– http://resource.soa.com/

• Webinar Recording

– http://resource.soa.com/resource/webinars

• Follow us on:

www.facebook.com/soasoftware

www.linkedin.com/company/soasoftware

@soasoftwareinc



api and soa: two sides of the same coin?

Technology

change management

web services

web service

api platform

resource centerhttp

rights reserved

webinar recordinghttp

2013 soa software