Modernizing an Existing SOA-based Architecture with APIs

1

Modernizing an Existing SOA-based Architecture with APIs

Robert C. Broeckelmann Jr.

Principal ConsultantRCBJ Consulting, LLC

©2015 Apigee. All Rights Reserved.

Modernizing an Existing SOA-Based Architecture with APIs Robert C. Broeckelmann Jr.Principal ConsultantRCBJ Consulting, LLC

2

About Me• Founder and a Principal Consultant at RCBJ Consulting,

LLC.• RCBJ Consulting, LLC is a small consulting firm

specializing in SOA, API Management, Performance Tuning, and Security started in 2011.

• Masters degree in Computer Science from Washington University in Saint Louis.

• Started working with APIgee Edge Server in 2014.• Worked with WebSphere DataPower since 2010.

3

Disclaimers, Warnings, Health Hazards• What we present here is one of numerous possible ways to use

APIgee technology. Your situation and requirements will probably differ.

• As always, test things in a non-production environment prior to using anything in production.

• We are not responsible for spontaneous combustion of the known universe or any other undesirable outcomes associated with using what is discussed here.

• This presentation describes a large organization's journey from an existing SOA & Integration Platform (including DataPower) to API Management. Unfortunately, the organization will remain nameless.

4©2015 Apigee. All Rights Reserved.

Agenda

5

1. Business & Technology Drivers

2. Current Infrastructure, SOA, and Integration Capabilities

3. Gaps

4. Considerations & Requirements

5. Lessons Learned & End-State Architecture

©2015 Apigee. All Rights Reserved.

What are the Drivers?• Business

– Mobile– B2B Integration (partners, vendors, suppliers)– SaaS Solution Integration (to realize benefits of SaaS solutions in a large

organization)– Facilitate wider adoption & increase business opportunities

• Technology– Direction industry is going– APIs easier to develop with than predecessor standards (SOAP, CORBA, EJB, etc)– Maturing standards

• Security (Authentication & Authorization): OAuth 2.0 [5],OpenID Connect 1.0 [6],JWT 1.0 [7]

• Interface definitions: Swagger 2.0 [8]• JSON Schema: [4] [14]


Existing SOA/Integration Capabilities• Our starting point...• SOA Capabilities

– SOA Governance/Service Life-Cycle Management– Service meta-data Registry/Repository

• Service Versioning/Routing/SecurityPolicy– Security Model– Standard Messaging Models– Enterprise Service standards– Standard error handling, reporting, and logging. Statistics Logging.

• Integration Capabilities– Integrating dozens of on-premise Commercial Off-The-Shelf (COTS) applications/some

third-party systems– SOAP over HTTPS and XML over WebSphere MQ, primarily. Some REST. Some binary

data formats & SAP IDOCs.– Data transformations/Protocol Transformations/Security Integration


Existing SOA/Integration Capabilities(cont.)• Use the IBM Integration Stack

– WebSphere Message Broker/IIB [10]– WebSphere DataPower [9]– WebSphere Services Registry & Repository [11]– WebSphere MQ [12]– WebSphere Transformation Extender(WTX) [13]– Focusing on WebSphere DataPower (lots of information about

other products available on the Internet or the Reference Section)• Relevant Patterns

– Enterprise Service Bus (ESB) [1],[2]– Service Gateway


Enterprise Service Bus


Service Gateway


Current Infrastructure: Gaps• Legacy baggage

– Primarily created by organization, not the technology– Creates complications and obstacles that must be deal with

• Existing integration stack products not built with REST/APIs & JSON in mind.– Added as afterthought

• Missing Developer Portal– One stop, self-service, shop for developers throughout the

development life-cycle– Ties into DevOps plans for the organization


Current Infrastructure: Gaps (cont.)• Cannot perform JSON Schema Validation and request

validation based upon Swagger 2.0 data definitions• Limited support for APIs and Swagger 2.0 in existing

Service Registry• No support for a standards-based API Security Model

– OAuth 2.0, OpenID Connect 1.0, and JWT 1.0• Current infrastructure is all on-premise

– Limited to single part of the country– No Geo-Location Based Routing of API requests.


Why Modernize? Why Use APIs?• APIs have become the industry standard for system

interfaces of all kinds.• Hide complexity; expose existing functionality• Use APIs as the basis for porting systems/functionality

into the cloud• Make it easier for other business units and business

partners to access systems and data, but maintain security

• Next step in evolution of SOA/Integration platforms• Want to have benefits of APIs


Requirements• Want to use

– API-First Design methodology for APIs– Swagger 2.0 as the Interface definition language

• Ties together security model, standard data/messaging models, API standards, and internal SDLC.

• Also, provides a testing mechanism for APIs• Developer Portal that serves as a one-stop, self-service shop for

developer access to– Developer Registration– Application Registration– Subscribe to APIs– API documentation– Security registration (users, groups, authorization policy)– Self Service


Requirements (cont.)• Same Service-Lifecycle used with SOAP Web Services applies to

API Lifecycle– do not want to lose structure and discipline of SOA Governance and Service Life-Cycle

Management– Let's call this API Governance and API Life-Cycle Management

• Continue to realize ROI in the IBM Integration Stack– Includes DataPower

• Supported Use Cases– Single Page responsive Web Applications– B2B Integration– Mobile– System-to-System(SaaS/Third-arty hosted) communication

• Want to leverage organization's existing programming skill sets: Java & Javascript


Requirements (cont.)• SAML 2.0/WS-Trust 1.3/WS-Security 1.0 Security Model used with

SOAP Web Services serves as a model for OAuth 2.0/OpenID Connect 1.0/JWT 1.0 security model for APIs.– Standards-based approach to security(makes interoperability between N

vendors much easier)• PCI Compliance could be a requirement in the future• Cloud-based solution

– Extend on-premise Integration Stack capabilities into the cloud– Going forward, many SaaS(or cloud-hosted) API Providers and API

consumers versus on-premise deployments– Do not want to be limited to a single cloud provider– All the other benefits of cloud-based infrastructure


This Brings Us To API Management• What is API Management?

– The process of publishing, promoting, and overseeing APIs in a secure, scalable environment– Ensures that developers and partners are productive– Manages, secures, and mediates your API traffic– Allows an organization to grow their API program to meet increasing demands– API Management is about monitizing APIs– API Management is about Technology, Business, Organization, and Integration.– Need to know more? Go to the sessions:)

• Three components– Management Portal– Developer Portal– Runtime Gateway(API Gateway)

• Why is this necessary?– Desire to modernize.– Begin using APIs as described previously– Easier to on-board new projects, business partners, vendors, suppliers, developers


Lessons Learned• Used DataPower on-premise for ESB Gateway and DMZ Gateway; used

APIgee Edge Server in the cloud. Allowed ROI of the original IBM Integration stack deployment to continue to be realized.

• Avoid Cloud-based API Gateway run-time dependencies (IAM, logging—Splunk, API meta-data repository, etc) that tie back to your data center—potentially creating a single point of failure.

• Using SaaS Middleware solutions allows organizations to focus on mission-critical, business-oriented problems.

• There will be a mix of SOAP & REST/APIs for the foreseeable future.• API/REST related specs (Swagger 2.0, OAuth/OpenID Connect/JWT) are

evolving, but still young compared to WS-* specs.• Existing organization of infrastructure and middleware administrators,

developers, and SOA Governance group were able to adapt to manage and utilize APIs


End-State Architecture


Thank you


Appendix


What is DataPower?

History DataPower Corporation started in 1999 in Cambridge, Massachusetts by a group of MIT

alumni. Bought by IBM in 2005.

Description Purpose-built hardware. Network router with middleware firmware XML parsing hardware & crypto acceleration hardware(hardware appliances) Numerous supported integration scenarios Focus on SOAP & XML Acts as a Service Gateway.

Can act as an ESB on its own (not marketed this way anymore). Commonly used as a DMZ Servicee Gateway or ESB Gateway (front door to ESB)


What is DataPower? (cont.) Supported protocols(HTTP, HTTPS, MQ client, WebSphere JMS, SFTP, FTPS, FTP, TCP,

NFS, TIBCO, ICAP, SQL, SSL/TLS, others) Not all protocols supported by every model

Supported data formats(XML—reason for its existence, JSON, arbitrary binary formats—WTX or DataGlue, various industry specs—XB62-B2B Appliance, COBOL CopyBook, flat files, others) Not all data formats supported by every model

Supported languages(XSLT with Extension Functions & Elements—always supported, Gateway Script—Javascript engine since 7.0, JSONiq since v5.x)

DataPower has several form factors Virtual Edition Physical Appliances

XA35—Original XML Processing appliance (not sold for a while now) XI50/XI52—ESB appliance(full integration capabilities) XS40/XG45—Security Gateway appliances XB60/XB62—B2B Appliance XC10—Caching Appliance


Other DataPower Use Cases(encountered in industry)--a Side Note

DataPower deployed in front of a mainframe converting XML/SOAP to COBOL Copybook data structures and placing messages onto WebSphere MQ Queues. Not really an Edge Server target use case.

Security Gateway(offload SSL/TLS, WS-Security, WS-SecurityPolicy, WS-Trust, authentication, authorization, etc) Edge Server could do this.

DataPower in front of SOAP Service Provider(s) to perform efficient schema validation Edge Server could do this, but unlikely Edge Server could do it as efficiently as DataPower

DataPower as part of the IBM API Management product. Direct competitor to Edge Server in this use case. Edge Server could obviously satisfy this

use case.


Reference

1. http://www-07.ibm.com/events/au/soainaction/download/Demystifying_ESB_patterns.pdf

2. http://www.ibm.com/developerworks/websphere/library/techarticles/0712_grund/0712_grund.html

3. https://tools.ietf.org/html/draft-zyp-json-schema-03

4. http://json-schema.org/latest/json-schema-core.html

5. https://tools.ietf.org/html/rfc6749

6. http://openid.net/specs/openid-connect-core-1_0.html

7. https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32

8. http://swagger.io/specification/

9. http://www-01.ibm.com/support/knowledgecenter/SS9H2Y/welcome

10. http://www-01.ibm.com/software/integration/ibm-integration-bus/library/message-broker/

11. http://www-01.ibm.com/software/integration/wsrr/library/

12. http://www-01.ibm.com/software/integration/wmq/library/

13. http://www-01.ibm.com/software/integration/wdatastagetx/library/

14. http://tools.ietf.org/html/draft-zyp-json-schema-04


Software

Modernizing an Existing SOA-based Architecture with APIs