Modernizing an Existing SOA-based Architecture with APIs - Robert C. Broeckelmann Jr., Principal Consultant, RCBJ Consulting, LLC at I Love APIs 2015

1. 1
Modernizing an Existing SOA-based Architecture
with APIs
Robert C. Broeckelmann
Jr.
Principal Consultant
RCBJ Consulting, LLC

2. ©2015 Apigee. All Rights Reserved.
Modernizing an Existing SOA-
Based Architecture with APIs
Robert C. Broeckelmann Jr.
Principal Consultant
RCBJ Consulting, LLC
2

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

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

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

6. 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]
6©2015 Apigee. All Rights Reserved.

7. 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
7©2015 Apigee. All Rights Reserved.

8. 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
8©2015 Apigee. All Rights Reserved.

9. Enterprise Service Bus
9©2015 Apigee. All Rights Reserved.

10. Service Gateway
10©2015 Apigee. All Rights Reserved.

11. 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
11©2015 Apigee. All Rights Reserved.

12. 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.
12©2015 Apigee. All Rights Reserved.

13. 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
13©2015 Apigee. All Rights Reserved.

14. 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
14©2015 Apigee. All Rights Reserved.

15. 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
15©2015 Apigee. All Rights Reserved.

16. 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
16©2015 Apigee. All Rights Reserved.

17. 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
17©2015 Apigee. All Rights Reserved.

18. 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
18©2015 Apigee. All Rights Reserved.

19. End-State Architecture
19©2015 Apigee. All Rights Reserved.

20. Thank you
20©2015 Apigee. All Rights Reserved.

21. Appendix
21©2015 Apigee. All Rights Reserved.

22. 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)
22©2015 Apigee. All Rights Reserved.

23. 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
23©2015 Apigee. All Rights Reserved.

24. 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.
24©2015 Apigee. All Rights Reserved.

25. 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
25©2015 Apigee. All Rights Reserved.