7/23/2019 Enterprise integration Reference card http://slidepdf.com/reader/full/enterprise-integration-reference-card 1/31 DZONE’S 2015 GUIDE TO ENTERPRISE INTEGRATION ZONE.COM/GUIDES DZONE’S 2015 GUIDE TO ENTERPRISE INTEGRA THE DZONE GUIDE TO 2015 EDITION ENTERPRISE INTEGRATION BROUGHT TO YOU IN PARTNERSHIP WITH
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
01 MORE DECOMPOSITION FEWER ldquoMICROSERVICESrdquo
Last yearrsquos DZone Enterprise Integra983156ion survey showedalmost 40 of respondents using microservicesmdash
unsurprising due to their success in web trendsetters likeNet852070lix not to men983156ion the hype surrounding the concept
This year however we found a decrease in respondentswho say they use microservices architectures Only 27claim to use microservices while another 18 say they
plan on using microservices in the future (983156ime un983156il
implementa983156ion has a mean of 8 months with a medianand mode of 6 months) S983156ill the majority of respondentsmdashwhether they use microservices or notmdashdecompose at least
one of their applica983156ion services which may indicate atrend of decomposing services as needed rather than usingmicroservices for microservicesrsquo sake
02 REST MAY NOT BE SO RESTFUL
Another shi1048678t from our survey results from last yearinvolved REST usage In the 2014 Enterprise Integra983156ionsurvey 74 of respondents claimed to use REST APIs
wherever possible This year we decided to dig a little deeperinto how developers used REST 60 of respondents say
they use REST whenever they can with another 7 sayingthey use REST consistently excep983156ing specific situa983156ions
(eg legacy code or SOAP requirements) 6 have plans tomove towards full REST in the future (es983156ima983156ing about ayear on average) and 25 have no REST policy in place at
all S983156ill even those who claim to use REST donrsquot necessarilyu983156ilize itrsquos full poten983156ial When asking respondents how
they used REST in their web apps based on the RichardsonMaturity Model (RMM) respondents overall es983156imated usingREST at its highest level (HATEOAS) only 6 of the 983156ime
Even respondents who say they use REST whenever theycan only use HATEOAS 7 of the 983156ime with most of their
03 XML WIDELY USED JSON WIDELY LOVEDWhen we asked about data serializa983156ion and interchange
formats we werenrsquot surprised to find that the two mostpopular were XML and JSONmdashmost respondents had never
even used other formats we asked about such as YAML andBSON 97 of respondents use XML in some way but only
KeyResearchFindings
02 REST USAGE AT EACH MATURITY MODEL LEVEL01 SERVICE DECOMPOSITION VS MICROSERVICES USAGE
Close to 600 developers responded to
DZonersquos 2015 Enterprise Integration survey
The respondentsrsquo demographics are as follows
bull The most common roles were developersengineers
(38) and developer team leads (36)
bull 47 of respondents work at organizations with
500 or more employees 37 work at organizations
employing between 20 and 499 and 10 work at
organizations with fewer than 20 employees or are
self-employed
bull Most respondents work within organizations that are
headquartered in Europe (40) or the US (35)
bull 45 of respondents have over 15 years experience
as an IT professional 26 have 10 ndash 14 years
17 have 6 ndash 9 years and 12 have 5 yearsexperience or less
bull 89 of respondents work in organizations that use
Java Other popular languageslanguage ecosystems
used within respondentsrsquo organizations are
JavaScript (58) NET (40) and Python (24)
59 USES MICROSERVICES
DOESNrsquoT USE MICROSERVICES33
53
28
45
BUSINESS LOGIC
MESSAGING
PRESENTATION
DATA ACCESS
23
48
29
ANY DECOMPOSITION
83
51 RMM0 RMM1 RMM2 RMM3
WE USE REST WHENEVER WE CAN EXCEPThellip
WE USE REST WHENEVER WE CAN
WE HAVE NO REST POLICY OR PREFERENCE
WE AVOID REST DELI BERATELY
WE DO NOT ALWAYS USE RE ST
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 531DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
24 say they enjoy using it JSON on the other hand isused by 96 of respondents and over half (52) actually
enjoy using it Interes983156ingly the formats that respondentshavenrsquot used have a large e983142fect on how RESTful their webservices are Only about 1 of respondentsrsquo web services
are considered HATEOAS of respondents who have neverused JSON For respondents who have never used XML an
average of 13 of their web services make it to level 3 of theRichardson Maturity Model Respondents who enjoy JSON
are the least likely to use plain RPC
04 LARGER ORGANIZATIONS U TILIZE MORE INTEGRATION
ARCHITECTURE PATTERNS
We asked our respondents this year to iden983156ify thetypes of integra983156ion architecture patterns they u983156ilize
The point-to-point style was the most popular with 69using that pattern in some way 58 use message buses52 service buses and only 24 use the hub-and-spoke
model We found that the number of di983142ferent integra983156ionarchitecture patterns used depended on the size of the
respondentrsquos organiza983156ions On average respondents use
about two di983142ferent integra983156ion patterns for di983142ferentneeds Respondents working in organiza983156ions with lessthan 100 employees all fell below this average whilerespondents at larger organiza983156ions meet (or far exceed)
this average with respondents at the largest organiza983156ionsusing an average of 231 integra983156ion architecture patterns
05 USAGE OF INTEGRATION TOOLS SCATTERED
As far as integra983156ion tools go there are many to choosefrom based on integra983156ion needs and the usage of these
tools is spread widely In the realm of frameworks suitesand ESBs Spring Integra983156ion is the most popular with 35
usage among respondents Apache Camel is ahead of thecurve too with 28 usage A variety of other tools herehave some popularity such as Mule ESB (13) and JBoss
Fuse (12) but among 8 other tools usage ranged from just
5 ndash 10 32 of respondents are not currently using anyintegra983156ion frameworks suites or ESBs
06 DIFFICULTIES ARE BECOMING LESS DIFFICULTThere are plenty of di983142ficul983156ies that can emerge when
integra983156ing The most common di983142ficulty respondentshave is di983142 ferent standards interpreta983156ions between
integra983156ion systems with 36 of respondents havingissues with that in their integra983156ions Other commonissues are propaga983156ing changes to integrated systems
(34) managing asynchronous communica983156ions (24)and needing to enrich data (13) S983156ill of all di983142ficul983156ies
we asked about almost all have a significant drop fromlast yearmdashdi983142 ficul983156ies propaga983156ing changes and di983142 ferent
standards interpreta983156ions dropped over 20 The onlyincrease from last year to this year involves cloud to on-premise integra983156ions with 12 of respondents dealing
with that di983142ficulty vs last yearrsquos 9
04 AVG NUMBER OF ENTERPRISE APPLICATION ARCHITECTURES
VS COMPANY SIZE
06 ORGANIZATIONAL INTEGRATIONS DIFFICULTIES 2014-201505 DOES YOUR ORGANIZATION USE ANY OF THE FOLLOWING
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
01 MORE DECOMPOSITION FEWER ldquoMICROSERVICESrdquo
Last yearrsquos DZone Enterprise Integra983156ion survey showedalmost 40 of respondents using microservicesmdash
unsurprising due to their success in web trendsetters likeNet852070lix not to men983156ion the hype surrounding the concept
This year however we found a decrease in respondentswho say they use microservices architectures Only 27claim to use microservices while another 18 say they
plan on using microservices in the future (983156ime un983156il
implementa983156ion has a mean of 8 months with a medianand mode of 6 months) S983156ill the majority of respondentsmdashwhether they use microservices or notmdashdecompose at least
one of their applica983156ion services which may indicate atrend of decomposing services as needed rather than usingmicroservices for microservicesrsquo sake
02 REST MAY NOT BE SO RESTFUL
Another shi1048678t from our survey results from last yearinvolved REST usage In the 2014 Enterprise Integra983156ionsurvey 74 of respondents claimed to use REST APIs
wherever possible This year we decided to dig a little deeperinto how developers used REST 60 of respondents say
they use REST whenever they can with another 7 sayingthey use REST consistently excep983156ing specific situa983156ions
(eg legacy code or SOAP requirements) 6 have plans tomove towards full REST in the future (es983156ima983156ing about ayear on average) and 25 have no REST policy in place at
all S983156ill even those who claim to use REST donrsquot necessarilyu983156ilize itrsquos full poten983156ial When asking respondents how
they used REST in their web apps based on the RichardsonMaturity Model (RMM) respondents overall es983156imated usingREST at its highest level (HATEOAS) only 6 of the 983156ime
Even respondents who say they use REST whenever theycan only use HATEOAS 7 of the 983156ime with most of their
03 XML WIDELY USED JSON WIDELY LOVEDWhen we asked about data serializa983156ion and interchange
formats we werenrsquot surprised to find that the two mostpopular were XML and JSONmdashmost respondents had never
even used other formats we asked about such as YAML andBSON 97 of respondents use XML in some way but only
KeyResearchFindings
02 REST USAGE AT EACH MATURITY MODEL LEVEL01 SERVICE DECOMPOSITION VS MICROSERVICES USAGE
Close to 600 developers responded to
DZonersquos 2015 Enterprise Integration survey
The respondentsrsquo demographics are as follows
bull The most common roles were developersengineers
(38) and developer team leads (36)
bull 47 of respondents work at organizations with
500 or more employees 37 work at organizations
employing between 20 and 499 and 10 work at
organizations with fewer than 20 employees or are
self-employed
bull Most respondents work within organizations that are
headquartered in Europe (40) or the US (35)
bull 45 of respondents have over 15 years experience
as an IT professional 26 have 10 ndash 14 years
17 have 6 ndash 9 years and 12 have 5 yearsexperience or less
bull 89 of respondents work in organizations that use
Java Other popular languageslanguage ecosystems
used within respondentsrsquo organizations are
JavaScript (58) NET (40) and Python (24)
59 USES MICROSERVICES
DOESNrsquoT USE MICROSERVICES33
53
28
45
BUSINESS LOGIC
MESSAGING
PRESENTATION
DATA ACCESS
23
48
29
ANY DECOMPOSITION
83
51 RMM0 RMM1 RMM2 RMM3
WE USE REST WHENEVER WE CAN EXCEPThellip
WE USE REST WHENEVER WE CAN
WE HAVE NO REST POLICY OR PREFERENCE
WE AVOID REST DELI BERATELY
WE DO NOT ALWAYS USE RE ST
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 531DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
24 say they enjoy using it JSON on the other hand isused by 96 of respondents and over half (52) actually
enjoy using it Interes983156ingly the formats that respondentshavenrsquot used have a large e983142fect on how RESTful their webservices are Only about 1 of respondentsrsquo web services
are considered HATEOAS of respondents who have neverused JSON For respondents who have never used XML an
average of 13 of their web services make it to level 3 of theRichardson Maturity Model Respondents who enjoy JSON
are the least likely to use plain RPC
04 LARGER ORGANIZATIONS U TILIZE MORE INTEGRATION
ARCHITECTURE PATTERNS
We asked our respondents this year to iden983156ify thetypes of integra983156ion architecture patterns they u983156ilize
The point-to-point style was the most popular with 69using that pattern in some way 58 use message buses52 service buses and only 24 use the hub-and-spoke
model We found that the number of di983142ferent integra983156ionarchitecture patterns used depended on the size of the
respondentrsquos organiza983156ions On average respondents use
about two di983142ferent integra983156ion patterns for di983142ferentneeds Respondents working in organiza983156ions with lessthan 100 employees all fell below this average whilerespondents at larger organiza983156ions meet (or far exceed)
this average with respondents at the largest organiza983156ionsusing an average of 231 integra983156ion architecture patterns
05 USAGE OF INTEGRATION TOOLS SCATTERED
As far as integra983156ion tools go there are many to choosefrom based on integra983156ion needs and the usage of these
tools is spread widely In the realm of frameworks suitesand ESBs Spring Integra983156ion is the most popular with 35
usage among respondents Apache Camel is ahead of thecurve too with 28 usage A variety of other tools herehave some popularity such as Mule ESB (13) and JBoss
Fuse (12) but among 8 other tools usage ranged from just
5 ndash 10 32 of respondents are not currently using anyintegra983156ion frameworks suites or ESBs
06 DIFFICULTIES ARE BECOMING LESS DIFFICULTThere are plenty of di983142ficul983156ies that can emerge when
integra983156ing The most common di983142ficulty respondentshave is di983142 ferent standards interpreta983156ions between
integra983156ion systems with 36 of respondents havingissues with that in their integra983156ions Other commonissues are propaga983156ing changes to integrated systems
(34) managing asynchronous communica983156ions (24)and needing to enrich data (13) S983156ill of all di983142ficul983156ies
we asked about almost all have a significant drop fromlast yearmdashdi983142 ficul983156ies propaga983156ing changes and di983142 ferent
standards interpreta983156ions dropped over 20 The onlyincrease from last year to this year involves cloud to on-premise integra983156ions with 12 of respondents dealing
with that di983142ficulty vs last yearrsquos 9
04 AVG NUMBER OF ENTERPRISE APPLICATION ARCHITECTURES
VS COMPANY SIZE
06 ORGANIZATIONAL INTEGRATIONS DIFFICULTIES 2014-201505 DOES YOUR ORGANIZATION USE ANY OF THE FOLLOWING
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
01 MORE DECOMPOSITION FEWER ldquoMICROSERVICESrdquo
Last yearrsquos DZone Enterprise Integra983156ion survey showedalmost 40 of respondents using microservicesmdash
unsurprising due to their success in web trendsetters likeNet852070lix not to men983156ion the hype surrounding the concept
This year however we found a decrease in respondentswho say they use microservices architectures Only 27claim to use microservices while another 18 say they
plan on using microservices in the future (983156ime un983156il
implementa983156ion has a mean of 8 months with a medianand mode of 6 months) S983156ill the majority of respondentsmdashwhether they use microservices or notmdashdecompose at least
one of their applica983156ion services which may indicate atrend of decomposing services as needed rather than usingmicroservices for microservicesrsquo sake
02 REST MAY NOT BE SO RESTFUL
Another shi1048678t from our survey results from last yearinvolved REST usage In the 2014 Enterprise Integra983156ionsurvey 74 of respondents claimed to use REST APIs
wherever possible This year we decided to dig a little deeperinto how developers used REST 60 of respondents say
they use REST whenever they can with another 7 sayingthey use REST consistently excep983156ing specific situa983156ions
(eg legacy code or SOAP requirements) 6 have plans tomove towards full REST in the future (es983156ima983156ing about ayear on average) and 25 have no REST policy in place at
all S983156ill even those who claim to use REST donrsquot necessarilyu983156ilize itrsquos full poten983156ial When asking respondents how
they used REST in their web apps based on the RichardsonMaturity Model (RMM) respondents overall es983156imated usingREST at its highest level (HATEOAS) only 6 of the 983156ime
Even respondents who say they use REST whenever theycan only use HATEOAS 7 of the 983156ime with most of their
03 XML WIDELY USED JSON WIDELY LOVEDWhen we asked about data serializa983156ion and interchange
formats we werenrsquot surprised to find that the two mostpopular were XML and JSONmdashmost respondents had never
even used other formats we asked about such as YAML andBSON 97 of respondents use XML in some way but only
KeyResearchFindings
02 REST USAGE AT EACH MATURITY MODEL LEVEL01 SERVICE DECOMPOSITION VS MICROSERVICES USAGE
Close to 600 developers responded to
DZonersquos 2015 Enterprise Integration survey
The respondentsrsquo demographics are as follows
bull The most common roles were developersengineers
(38) and developer team leads (36)
bull 47 of respondents work at organizations with
500 or more employees 37 work at organizations
employing between 20 and 499 and 10 work at
organizations with fewer than 20 employees or are
self-employed
bull Most respondents work within organizations that are
headquartered in Europe (40) or the US (35)
bull 45 of respondents have over 15 years experience
as an IT professional 26 have 10 ndash 14 years
17 have 6 ndash 9 years and 12 have 5 yearsexperience or less
bull 89 of respondents work in organizations that use
Java Other popular languageslanguage ecosystems
used within respondentsrsquo organizations are
JavaScript (58) NET (40) and Python (24)
59 USES MICROSERVICES
DOESNrsquoT USE MICROSERVICES33
53
28
45
BUSINESS LOGIC
MESSAGING
PRESENTATION
DATA ACCESS
23
48
29
ANY DECOMPOSITION
83
51 RMM0 RMM1 RMM2 RMM3
WE USE REST WHENEVER WE CAN EXCEPThellip
WE USE REST WHENEVER WE CAN
WE HAVE NO REST POLICY OR PREFERENCE
WE AVOID REST DELI BERATELY
WE DO NOT ALWAYS USE RE ST
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 531DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
24 say they enjoy using it JSON on the other hand isused by 96 of respondents and over half (52) actually
enjoy using it Interes983156ingly the formats that respondentshavenrsquot used have a large e983142fect on how RESTful their webservices are Only about 1 of respondentsrsquo web services
are considered HATEOAS of respondents who have neverused JSON For respondents who have never used XML an
average of 13 of their web services make it to level 3 of theRichardson Maturity Model Respondents who enjoy JSON
are the least likely to use plain RPC
04 LARGER ORGANIZATIONS U TILIZE MORE INTEGRATION
ARCHITECTURE PATTERNS
We asked our respondents this year to iden983156ify thetypes of integra983156ion architecture patterns they u983156ilize
The point-to-point style was the most popular with 69using that pattern in some way 58 use message buses52 service buses and only 24 use the hub-and-spoke
model We found that the number of di983142ferent integra983156ionarchitecture patterns used depended on the size of the
respondentrsquos organiza983156ions On average respondents use
about two di983142ferent integra983156ion patterns for di983142ferentneeds Respondents working in organiza983156ions with lessthan 100 employees all fell below this average whilerespondents at larger organiza983156ions meet (or far exceed)
this average with respondents at the largest organiza983156ionsusing an average of 231 integra983156ion architecture patterns
05 USAGE OF INTEGRATION TOOLS SCATTERED
As far as integra983156ion tools go there are many to choosefrom based on integra983156ion needs and the usage of these
tools is spread widely In the realm of frameworks suitesand ESBs Spring Integra983156ion is the most popular with 35
usage among respondents Apache Camel is ahead of thecurve too with 28 usage A variety of other tools herehave some popularity such as Mule ESB (13) and JBoss
Fuse (12) but among 8 other tools usage ranged from just
5 ndash 10 32 of respondents are not currently using anyintegra983156ion frameworks suites or ESBs
06 DIFFICULTIES ARE BECOMING LESS DIFFICULTThere are plenty of di983142ficul983156ies that can emerge when
integra983156ing The most common di983142ficulty respondentshave is di983142 ferent standards interpreta983156ions between
integra983156ion systems with 36 of respondents havingissues with that in their integra983156ions Other commonissues are propaga983156ing changes to integrated systems
(34) managing asynchronous communica983156ions (24)and needing to enrich data (13) S983156ill of all di983142ficul983156ies
we asked about almost all have a significant drop fromlast yearmdashdi983142 ficul983156ies propaga983156ing changes and di983142 ferent
standards interpreta983156ions dropped over 20 The onlyincrease from last year to this year involves cloud to on-premise integra983156ions with 12 of respondents dealing
with that di983142ficulty vs last yearrsquos 9
04 AVG NUMBER OF ENTERPRISE APPLICATION ARCHITECTURES
VS COMPANY SIZE
06 ORGANIZATIONAL INTEGRATIONS DIFFICULTIES 2014-201505 DOES YOUR ORGANIZATION USE ANY OF THE FOLLOWING
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
01 MORE DECOMPOSITION FEWER ldquoMICROSERVICESrdquo
Last yearrsquos DZone Enterprise Integra983156ion survey showedalmost 40 of respondents using microservicesmdash
unsurprising due to their success in web trendsetters likeNet852070lix not to men983156ion the hype surrounding the concept
This year however we found a decrease in respondentswho say they use microservices architectures Only 27claim to use microservices while another 18 say they
plan on using microservices in the future (983156ime un983156il
implementa983156ion has a mean of 8 months with a medianand mode of 6 months) S983156ill the majority of respondentsmdashwhether they use microservices or notmdashdecompose at least
one of their applica983156ion services which may indicate atrend of decomposing services as needed rather than usingmicroservices for microservicesrsquo sake
02 REST MAY NOT BE SO RESTFUL
Another shi1048678t from our survey results from last yearinvolved REST usage In the 2014 Enterprise Integra983156ionsurvey 74 of respondents claimed to use REST APIs
wherever possible This year we decided to dig a little deeperinto how developers used REST 60 of respondents say
they use REST whenever they can with another 7 sayingthey use REST consistently excep983156ing specific situa983156ions
(eg legacy code or SOAP requirements) 6 have plans tomove towards full REST in the future (es983156ima983156ing about ayear on average) and 25 have no REST policy in place at
all S983156ill even those who claim to use REST donrsquot necessarilyu983156ilize itrsquos full poten983156ial When asking respondents how
they used REST in their web apps based on the RichardsonMaturity Model (RMM) respondents overall es983156imated usingREST at its highest level (HATEOAS) only 6 of the 983156ime
Even respondents who say they use REST whenever theycan only use HATEOAS 7 of the 983156ime with most of their
03 XML WIDELY USED JSON WIDELY LOVEDWhen we asked about data serializa983156ion and interchange
formats we werenrsquot surprised to find that the two mostpopular were XML and JSONmdashmost respondents had never
even used other formats we asked about such as YAML andBSON 97 of respondents use XML in some way but only
KeyResearchFindings
02 REST USAGE AT EACH MATURITY MODEL LEVEL01 SERVICE DECOMPOSITION VS MICROSERVICES USAGE
Close to 600 developers responded to
DZonersquos 2015 Enterprise Integration survey
The respondentsrsquo demographics are as follows
bull The most common roles were developersengineers
(38) and developer team leads (36)
bull 47 of respondents work at organizations with
500 or more employees 37 work at organizations
employing between 20 and 499 and 10 work at
organizations with fewer than 20 employees or are
self-employed
bull Most respondents work within organizations that are
headquartered in Europe (40) or the US (35)
bull 45 of respondents have over 15 years experience
as an IT professional 26 have 10 ndash 14 years
17 have 6 ndash 9 years and 12 have 5 yearsexperience or less
bull 89 of respondents work in organizations that use
Java Other popular languageslanguage ecosystems
used within respondentsrsquo organizations are
JavaScript (58) NET (40) and Python (24)
59 USES MICROSERVICES
DOESNrsquoT USE MICROSERVICES33
53
28
45
BUSINESS LOGIC
MESSAGING
PRESENTATION
DATA ACCESS
23
48
29
ANY DECOMPOSITION
83
51 RMM0 RMM1 RMM2 RMM3
WE USE REST WHENEVER WE CAN EXCEPThellip
WE USE REST WHENEVER WE CAN
WE HAVE NO REST POLICY OR PREFERENCE
WE AVOID REST DELI BERATELY
WE DO NOT ALWAYS USE RE ST
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 531DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
24 say they enjoy using it JSON on the other hand isused by 96 of respondents and over half (52) actually
enjoy using it Interes983156ingly the formats that respondentshavenrsquot used have a large e983142fect on how RESTful their webservices are Only about 1 of respondentsrsquo web services
are considered HATEOAS of respondents who have neverused JSON For respondents who have never used XML an
average of 13 of their web services make it to level 3 of theRichardson Maturity Model Respondents who enjoy JSON
are the least likely to use plain RPC
04 LARGER ORGANIZATIONS U TILIZE MORE INTEGRATION
ARCHITECTURE PATTERNS
We asked our respondents this year to iden983156ify thetypes of integra983156ion architecture patterns they u983156ilize
The point-to-point style was the most popular with 69using that pattern in some way 58 use message buses52 service buses and only 24 use the hub-and-spoke
model We found that the number of di983142ferent integra983156ionarchitecture patterns used depended on the size of the
respondentrsquos organiza983156ions On average respondents use
about two di983142ferent integra983156ion patterns for di983142ferentneeds Respondents working in organiza983156ions with lessthan 100 employees all fell below this average whilerespondents at larger organiza983156ions meet (or far exceed)
this average with respondents at the largest organiza983156ionsusing an average of 231 integra983156ion architecture patterns
05 USAGE OF INTEGRATION TOOLS SCATTERED
As far as integra983156ion tools go there are many to choosefrom based on integra983156ion needs and the usage of these
tools is spread widely In the realm of frameworks suitesand ESBs Spring Integra983156ion is the most popular with 35
usage among respondents Apache Camel is ahead of thecurve too with 28 usage A variety of other tools herehave some popularity such as Mule ESB (13) and JBoss
Fuse (12) but among 8 other tools usage ranged from just
5 ndash 10 32 of respondents are not currently using anyintegra983156ion frameworks suites or ESBs
06 DIFFICULTIES ARE BECOMING LESS DIFFICULTThere are plenty of di983142ficul983156ies that can emerge when
integra983156ing The most common di983142ficulty respondentshave is di983142 ferent standards interpreta983156ions between
integra983156ion systems with 36 of respondents havingissues with that in their integra983156ions Other commonissues are propaga983156ing changes to integrated systems
(34) managing asynchronous communica983156ions (24)and needing to enrich data (13) S983156ill of all di983142ficul983156ies
we asked about almost all have a significant drop fromlast yearmdashdi983142 ficul983156ies propaga983156ing changes and di983142 ferent
standards interpreta983156ions dropped over 20 The onlyincrease from last year to this year involves cloud to on-premise integra983156ions with 12 of respondents dealing
with that di983142ficulty vs last yearrsquos 9
04 AVG NUMBER OF ENTERPRISE APPLICATION ARCHITECTURES
VS COMPANY SIZE
06 ORGANIZATIONAL INTEGRATIONS DIFFICULTIES 2014-201505 DOES YOUR ORGANIZATION USE ANY OF THE FOLLOWING
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 531DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
24 say they enjoy using it JSON on the other hand isused by 96 of respondents and over half (52) actually
enjoy using it Interes983156ingly the formats that respondentshavenrsquot used have a large e983142fect on how RESTful their webservices are Only about 1 of respondentsrsquo web services
are considered HATEOAS of respondents who have neverused JSON For respondents who have never used XML an
average of 13 of their web services make it to level 3 of theRichardson Maturity Model Respondents who enjoy JSON
are the least likely to use plain RPC
04 LARGER ORGANIZATIONS U TILIZE MORE INTEGRATION
ARCHITECTURE PATTERNS
We asked our respondents this year to iden983156ify thetypes of integra983156ion architecture patterns they u983156ilize
The point-to-point style was the most popular with 69using that pattern in some way 58 use message buses52 service buses and only 24 use the hub-and-spoke
model We found that the number of di983142ferent integra983156ionarchitecture patterns used depended on the size of the
respondentrsquos organiza983156ions On average respondents use
about two di983142ferent integra983156ion patterns for di983142ferentneeds Respondents working in organiza983156ions with lessthan 100 employees all fell below this average whilerespondents at larger organiza983156ions meet (or far exceed)
this average with respondents at the largest organiza983156ionsusing an average of 231 integra983156ion architecture patterns
05 USAGE OF INTEGRATION TOOLS SCATTERED
As far as integra983156ion tools go there are many to choosefrom based on integra983156ion needs and the usage of these
tools is spread widely In the realm of frameworks suitesand ESBs Spring Integra983156ion is the most popular with 35
usage among respondents Apache Camel is ahead of thecurve too with 28 usage A variety of other tools herehave some popularity such as Mule ESB (13) and JBoss
Fuse (12) but among 8 other tools usage ranged from just
5 ndash 10 32 of respondents are not currently using anyintegra983156ion frameworks suites or ESBs
06 DIFFICULTIES ARE BECOMING LESS DIFFICULTThere are plenty of di983142ficul983156ies that can emerge when
integra983156ing The most common di983142ficulty respondentshave is di983142 ferent standards interpreta983156ions between
integra983156ion systems with 36 of respondents havingissues with that in their integra983156ions Other commonissues are propaga983156ing changes to integrated systems
(34) managing asynchronous communica983156ions (24)and needing to enrich data (13) S983156ill of all di983142ficul983156ies
we asked about almost all have a significant drop fromlast yearmdashdi983142 ficul983156ies propaga983156ing changes and di983142 ferent
standards interpreta983156ions dropped over 20 The onlyincrease from last year to this year involves cloud to on-premise integra983156ions with 12 of respondents dealing
with that di983142ficulty vs last yearrsquos 9
04 AVG NUMBER OF ENTERPRISE APPLICATION ARCHITECTURES
VS COMPANY SIZE
06 ORGANIZATIONAL INTEGRATIONS DIFFICULTIES 2014-201505 DOES YOUR ORGANIZATION USE ANY OF THE FOLLOWING
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Take control of your APIs3scales API management platform offers a unique layered architecture
that lets you implement traffic control where you need it and configure
access control rate limits and developer tools from a single cloud-based
interface Delivery components that carry API traffic can live anywhere
and traffic doesnrsquot flow through the 3scale layer
Asynchronous communication between delivery components allows local
nodes to cache credentials and usage data without a round-trip call to
3scale each time resulting in a highly robust and scalable deployment
Follow 3 quick steps to send your first test traffic
with 3scale using your own API or the example
one provided Well congratulate you by sending
some awesome swag your way
Try 3scale get swag
Get started at 3scalenetdzone rsaquo
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 731DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
SCALABILITY AND UPTIME
Whatever tra983142fic control architecture you choose itshouldnrsquot be a bottleneck or a single point of failure Itshould be 852070lexible enough to work with your preferred
infrastructure with a deployment method (such as a proxyor CDN) that fits your specific use case and needs Knowthe details on scalability and reliabilitymdashhow quickly can
you increase capacity during a tra983142fic spike Caching faulttolerance and load balancing will help ensure minimaldown983156ime for API users
ACCESS CONTROL AND SECURITY
Authen983156ica983156ion is essen983156ial but by itself provides insu983142ficientprotec983156ion for your API You should be able to managecreden983156ials establish di983142ferent levels of access for di983142ferent
types of users and control how client applica983156ions arepermitted to interact with your API
DEVELOPER EXPERIENCE TOOLS
To improve adop983156ion and keep developers engaged yoursquollneed to provide tools that simplify the onboarding processExample code documenta983156ion quick-start guides and other
reference materials all make it easier for developers to getstarted and help to enable success Make it easy for newusers to get a foot in the door by providing a centralized
developer portal and interac983156ive documenta983156ion
INSIGHTFUL ANALYTICS
You need insight into API performance Which applica983156ions
generate the most tra983142fic Which APIs are most popularand which APIs or endpoints are used the least You should
have visibility into usage trends and ongoing monitoring fokey metrics Automated alerts should be configured to 852070lagany unusual behavior or unexpected changes which could
indicate a major issue
WRITTEN BY STEVEN WILLMOTT
C E O A N D C O - F O U N D E R A T 3S C A L E
983092 Things Every
API Deserves
SPONSORED OPINION
YOUR API CAN BE AN INCREDIBLY
VALUABLE ASSETmdashTREAT IT LIKE ONE
3scalersquos unique hybrid architecture creates 852070lexibility performance and scale not
achievable or cost-e983142fec983156ive with other solu983156ions
BLOG 3scalenetblog WEBSITE 3scalenetTWITTER 3scale
983091scale API Management Platform by 983091scale
CASE STUDY
In order to transi983156ion from a crowd-sourced idea to the most-used
dataset of startup informa983156ion the Crunchbase team needed to build
an API that func983156ioned as a strategic business asset in line with overallgrowth strategy The team sought an API management solu983156ion that
would both reduce opera983156ional costs and provide a 852070lexible founda983156ion
for growth ease of implementa983156ion and management were also key
considera983156ions A1048678ter a straightforward implementa983156ion of 3scale
Crunchbase saw a drama983156ic improvement in performance Developer
signups and API usage skyrocketed and implemen983156ing 3scale led to
decreased maintenance 983156ime allowing Crunchbasersquos engineering team
to spend more 983156ime working on improvements to the API itself
STRENGTHS
bull Flexible deployment op983156ions including an API gateway CDN
or on-premise
bull Single interface for control and visibility
bull Scalable high-performance architecture
bull Built-in developer portal CMS and interac983156ive
documenta983156ion
bull Highly customizable security and access control features
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
THE WORLD OF IT AS WE KNOW IT TODAY IS CHANGING
DRASTICALLY JUST A COUPLE OF YEARS AGO DEVELOPERS
spent months or even years developing infrastructuresand working on the integra983156ion of various applica983156ionsHuge projects with mul983156iple par983156icipants were required toimplement desired features With the advent of DevOpsvarious Platform-as-a-Service (PaaS) environments containers
and microservices many complex requirements can bemet within a much shorter 983156ime The Internet of Things(IoT) is also expected to change established applica983156ions andinfrastructures As a result of these converging trends theway in which system integra983156ion will work is set to undergo afundamental change in the coming years
System integra983156ion has come a long way from point-to-pointconnec983156ions between individual systems towards the firstintegra983156ion solu983156ions that helped in standardizing thoseconnec983156ions And in the advent of a much more business-centered designmdashand the broader shi1048678 t into more service-oriented organiza983156ionsmdashthe Enterprise Service Bus (ESB)evolved from a pattern to a variety of products They all
promised to deliver reusability and exchangeability by standingup as a centralized and managed infrastructure component
As a direct result applica983156ions had to be slicedmdashand evenpartly rebuiltmdashto support exchangeable services Service-oriented architectures (SOAs) were the new paradigm behindthis Unfortunately the interface technology of choice tendedto be Web services (WS) Web services transport data betweensystems by encoding the data into XML and transmit983156ing it viathe Simple Object Access Protocol (SOAP) and they introduceda significant amount of addi983156ional code and descriptors intomost projects With the extra code and configura983156ion cameextra complexity on various levels Government of service
versions and cross-service security as well as documenta983156ionand requirement engineering had to be tweaked to focus onservices instead of features All of this had to be managed
OUTER ARCHITECTURE GAINS MORE IMPORTANCE
With the next technology evolu983156ionmdashMicroservicesmdashtheneed to manage even more poten983156ially-polyglot and distributed
services became overwhelming
Looking back we can see that integra983156ion complexity movedfrom the inner architecture of applica983156ions towards the outerarchitecture of the complete system The outer architecturerefers to the platform capabili983156ies you need to help all thosesimple little microservices work together
And it isnrsquot enough just bringing the technology aspectstogether The outer architecture also has to supportdevelopment teams and the So1048678tware Development Lifecycle(SDLC) to deliver on the promises of 852070lexible and scalabledevelopment and deployment
Looking at the architecture diagram above it becomes veryobvious that the most important parts of your applica983156ion arenow outside of your services Instead of solely focusing on
QUICK VIEW
01Instead of selecting a single ESB or
integration product you now need to find a
solid combination of necessary components
02
Through a modern cloud platformindividual services can easily be deployed
scaled and exposed as needed
03Microservices will lead to distributed and
segregated data volumes that require new
approaches like streaming data solutions
to manage
04The segment architecture approach is still
too new to give recommendations For a
while it will still be your responsibility to
understand the capabilities you need bydoing your own research
The Future
of Integration With
MicroservicesBY MARKUS EISELE
CLIENTS LOAD BALANCER
SERVICE AA CACHE
LOAD BALANCER
A P I G A T E W A Y
S E C U R I T Y DB
SERVICE
REGISTRY
SERVICE BB CACHE DB
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 931DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
integra983156ion 852070low and logic the correct approach to run yourservices becomes even more important than it ever was
PICKING A BASELINE - XPAAS
Instead of selec983156ing a single ESB or integra983156ion product younow need to find a solid combina983156ion of all of the needed partsWhile the acronym iPaaS (integra983156ion platform as a service)started to emerge a couple of years ago you will end up witheven more than one xPaaS (everything as a service) serviceThe best star983156ing point for the outer architecture is an aPaaS
(applica983156ion platform as a service) platform or frameworkwhich has the poten983156ial to integrate seamlessly with therelevant parts of the underlying PaaS There are many op983156ionsavailable Classical enterprises might s983156ill s983156ick with a Java EEbased aPaaS while others will quickly move on to somethingmore lightweight But the platform language is no longer thecri983156ical aspect here more important is how the aPaaS hooksinto the centralized cross-cut983156ing and opera983156ional capabili983156ies
OPERATIONAL CAPABILITIES
While aPaaS and iPaaS both refer to complete product stacksmostly they have one thing in common the base PaaS o983142feringon which they rely on A modern cloud platform knows a lotmore about the applica983156ions it runs than the ones years agoWith the help of deployment templates and descriptors theindividual services can easily be deployed scaled and exposedas needed And even the service orchestra983156ion is encapsulatedAll of this works because other emerging technologies likecontainers and container orchestra983156ion (eg Kubernetes) isbuilt into the core of todayrsquos PaaS What very quickly startedto be a commodity under the hood is enhanced by somevendors with opera983156ional consolesmdashand enhanced by a veryfew vendors with addi983156ional developer tooling Developersupport especially mostly ends with what DevOps teams andcon983156inuous delivery best prac983156ices demand
DEVELOPER SUPPORT
But there is a lot more e983142fort needed to develop highly-distributed systems While complex IDE plug-ins from ESB983156imes were able to tweak the centralized service repositoryloosely-coupled microservices do need more run983156imeinforma983156ion to build an applica983156ion Instead of centrally wiringservices together we now want to look up service endpointsat run983156ime Registra983156ion versioning and addi983156ional meta-informa983156ion like SLAs also need to be resolvable by everyservice from the centralized registry Dispatching requests toone of the available instances will be done by the underlyingPaaS A developer will have to provide most of the relevantinforma983156ion at 983156ime of development and the services will auto-register themselves while the platform uses their individual
informa983156ion to distribute the workload most e983142ficiently Toolingto browse service documenta983156ion or look up exis983156ing serviceswill also be a very cri983156ical feature When a microservice-basedapplica983156ion is finally in produc983156ion it is 983156ime to have the abilityto follow the distributed request-852070low throughout the systemBeing able to track down errors and assist with debugging is acomplex task which the outer architecture of our integra983156ionsolu983156ions also needs to support
THE CHANGING FACE OF DATA INTEGRATION
The lastmdashbut no less importantmdashpart of new integra983156ionarchitectures will be the next level of data-integra983156ion
approaches With every microservice being responsible for
its own database the classical ETL (Extract Transform Load)
data-warehousing and data federa983156ion systems will quicklyreach an unmaintainable state New approaches to master
data management will be required to handle these kind of
distributed and segregated data volumes Among the possible
solu983156ions on the horizon are Big Data or stream data solu983156ionswhich take data-changing events and allow opera983156ions on a
copy of the data But virtualized data-models will also help
for repor983156ing or warehousing requirements More complex
solu983156ions might also allow the exposure of data services which
themselves can be consumed by businessmicroservices
READY FOR PRIME TIME
Vendors have already started to ldquomicroservice-wash rdquo their
tools and platforms to get your atten983156ion And the segment
architecture approach is s983156ill too new to give recommenda983156ions
For a while it will s983156ill be your responsibility to understand
the capabili983156ies you need by doing your own research Some
promising candidates are evolving out of the open-source
think tank at this very moment First and foremost projects
like OpenShi1048678t Origin WildFly Swarm Fabric8 and APIMan
will help you put together most of the puzzle pieces in your
microservices-based architecture
Microservices and containers will change the way webuild maintain operate and integrate applica983156ions When
architectured with discipline and a careful selec983156ion of the
outer architecture they will help applica983156ions become more
portable and more adap983156ive In the end better applica983156ion or
service integra983156ion will be very di983142ferent to todayrsquos approaches
it will become a number-one key requirement for distributed
microservices applica983156ions
MARKUS EISELE is a Developer Advocate at Red Hat and focuses
on JBoss Middleware He is a Java Champion and former ACE
Director as well as a prolific blogger community leader and book
author He has worked with Java EE servers for 14 years
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
Launch new apps and integrations faster
than ever with CA Live API Creator
Quickly build APs from diverse data sources applications and
business logic using a point-and-click approach
NoSQLII
-(
Securty
Discover how gt
cacomCreateAPis
SQL
External APis
Busness Logc
ctechnologie
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1131DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRASPONSORED OPINION
Bring your apps to market faster with CA API Management at the center of yourdigital strategy
BLOG blogscacomcategoryapi-management WEBSITE cacomapiTWITTER CaAPI
CA API Management by CA Technologies
CASE STUDY
IceMobilersquos mission is to add emo983156ion to transac983156ional loyalty in the foodretail market By combining data and technology to deliver personalizedmobile experiences it boosts revenue and increases customer loyalty for
retailers worldwideWith retailersrsquo legacy IT systems put983156ing sales at risk IceMobile neededto accelerate and simplify integra983156ion between IceMobilersquos Bright LoyaltyPlatform and retailersrsquo back o983142fice systems
APIs require only limited changes to the food retailersrsquo back o983142fice systemsCA API Management simplifies connec983156ions with mul983156iple interna983156ional foodretailers while ensuring IceMobile meets retail security standards
By simplifying integra983156ion IceMobile has cut implementa983156ion 983156imes from 14to eight weeks while minimizing impact on retailersrsquo busy IT departmentsThe ability to integrate with any technology safeguards growth
STRENGTHS
bull Create APIs and Integrate Everything - Bring together thedata you need to power next-genera983156ion cloud mobile and IoTapplica983156ions with broad integra983156ion capabili983156ies
bull Secure the Open Enterprise - Use a secure analyst-acclaimedplatform for integra983156ing across apps devices and businesses
bull Accelerate Mobile and IoT Development - Empower developerswith tools to streamline the development process improveproduc983156ivity and reduce 983156ime-to-market
bull Unlock the Value of Data- Build API-based ecosystems to extendyour brand develop new digital products and services or createnew revenue channels by mone983156izing your data
CATEGORY
API Management andIntegra983156ion
NEW RELEASES
Quarterly
OPEN SOURCE
No
NOTABLE CUSTOMERS
These CA API Management customers are speaking about theirsuccesses at CA World 2015 Nov 16-20 in Las Vegas Nike VisaPepsiCo Samsung General Motors FedEx The Walt DisneyCompany US Bank
The applica983156ion economy is driven by an always-connectedmobile applica983156ion-based world To meet the demand of
consumers today an enterprise architecture needs to becapable of suppor983156ing a diverse set of endpointsmdashinternal
applica983156ions legacy systems external partners customersmobile devices IoT devices etc The architecture also shouldbe able to scale on an on-demand basis to support inbound
and outbound tra983142fic with volumes exceeding possiblymillions of transac983156ions
So when an enterprise architect (EA) modernizes their
architecture their dilemma is whether to rip out and replaceall that has been built or to extend the exis983156ing architectureto seamlessly move into a digital enterprise The answer lies
with new design architectures such as API management
A NOESB ARCHITECTURE
Enterprise Service Bus (ESB) or Service-Oriented Architecture(SOA) models were designed a couple of decades ago for
internal integra983156ion needs For new digital ini983156ia983156ives aroundmobile IoT and the cloud ESBs fall short and so the exis983156inglegacy integra983156ion models need to be upgraded using API
management as a solu983156ion
APIS POWERING NEW ARCHITECTURES
With an API-enabled solu983156ion you can
bull Expose and manage select APIs external ly to customers
and partners
bull Adopt the right security models to secure your APIs
bull Govern APIs and manage change control for minimalimpact on consumers
bull Bring the needed scalability to match the speed of theInternet and high growth of mobile applica983156ions
bull Improve IT agility in order to rapidly respond to changesrequested by business
Read An Enterprise Architectrsquos Guide to API Integra983156ion for ESB
and SOA to know how API management can enable modernconnec983156ivity o983142fer sophis983156icated security control boostdeveloper produc983156ivity and prepare the EA to take on new
business models with ease
WRITTEN BY DINESH CHANDRASEKHAR
DIRECTOR API MANAGEMENT PRODUCT MARKETING CA TECHNOLOGIES
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
Alice is driving through Bob is at the food window
This level of the RMM represents the transmission of data through remote procedure calls
without utilizing other benefits of web transmissionmdashessentially using HTTP as nothing morethan a way to send messages back and forth Below Alice POSTs her intention to spend money
and Bob POSTs what she can spend money on once the money has been POSTed there is no
way to distinguish Alicersquos specific order RESTful respondents on average estimate 24 of
their web services are conducted over plain RPC
SCE NAR IO
Alice is buying food Bob is behind the counter
RESTfulness is a concept that is often thrown around to refer to communications between integrated systems But REST in itself is a nebulous idea and what some may conside
REST others may think of as a mere transfer of data over (usually) HTTP The Richardson Maturity Model created by Leonard Richardson tries to demystify the idea of RESTfulne
by breaking down communications into stages of REST maturity Level 0 attempts to incorporate REST into communications by simply using HTTP as a system of data
transportation without taking advantage of its benefits level 3 describes the ideal REST style This infographic shows real-world examples of ldquoRESTfulrdquo communications Thestatistics included refer only to the 60 of our survey respondents that claimed ldquoWe use REST whenever we canrdquo in an attempt to examine how RESTful REST practitioners really a
HOW RESTFUL ARE YOU
Level 1 of the RMM routes requests to specific resources for specific functions separatingactions and objects Here changes can be made on an object-by-object basis As opposed to the
last scenario in level 1 Alice receives an order number to the resource she requested 24 of
RESTful respondentsrsquo web services are estimated to use level 1 interactions
SCE NAR IO
SCE NAR IO SCE NAR IO
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $2 for a sodardquo
BOB ldquoYour order has been received (200 OK)rdquo in case of anerror ldquoThere was an error processing your orderrdquo
Alice ldquoI would like to POST money hererdquo
BOB ldquoYou can POST $2 for a soda You can POST $3 for friesrdquo
ALICE ldquoPOST $3 for friesrdquo
Bob ldquoOrder 555 has been received (200 OK)
Order coming uprdquo
Alice is entering and talking to Bob the bartender Alice is sitting at a table waiter Bob approaches
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
coupling and cultureorganiza983156ional structure are all prerequisites
to building an adap983156ive organiza983156ion even in the face of constantlychanging business and technological landscapes Integra983156ion is a
distributed-systems problem so letrsquos focus on some of the building
blocks of successful distributed systems
DOMAIN MODELING
As developers we are intrigued (or downright giddy) with
technology With new technology unfolding every day itrsquos not hard
to understand why However for most systems the technology
is not the complicated part the domain is Most developers Irsquove
spoken with arenrsquot interested in becoming domain experts to
facilitate building better so1048678tware Itrsquos not exactly a highly sought-
a1048678ter skill either (search most job boardshellip do you see domain
QUICK VIEW
01Integrating systems is hard and now
we have to deal with SaaS mobile Big
Data and other integration obstacles
02Copying what others are doing because
they appear successful is not going to
lead to a successful result
03Focus on core distributed-systems
principles integration is still a
distributed-systems problem
04Tackling domain complexity API
evolution unreliable networks and
organizational structures are key
Integration
Is Still ADistributed-
Systems ProblemBY CHRISTIAN POSTA
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 1831DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
knowledge or domain modeling high up on the list of requisites)
But domain modeling is a powerful and underused technique that
is a vital prerequisite to building integra983156ions and applica983156ions
We use models in our daily lives to simplify otherwise complex
environments For example we use the GPS on our phones for
naviga983156ing a city but the map on our phones is a model geared
toward accomplishing that goal Using GPS and maps on our
phones may not be a helpful model for naviga983156ing a battlefield
Understanding the nuances of the domain and where to elucidate
ambigui983156ies is key to itera983156ing on your understanding of what
the so1048678tware should do and how to model it in your code Eachdiscussion with a domain expert should be re852070lected in the code
so that they evolve together Once yoursquore able to uncover the right
model for the purpose of the so1048678tware yoursquore ready to explore the
right boundaries
BOUNDARIES
We deal with a lot of systems when we set out to build integra983156ions
o1048678ten983156imes with systems that were never designed to talk to each
other Those boundaries are fairly straightforward But there are
nuances in a domain that can cause ripple e983142fects if not accounted
for and designed explicitly with boundaries For example when I go
to place an order on Amazoncom or Walmartcom I can add things
to my shopping cart and checkout I will be prompted for payment
informa983156ion and delivery informa983156ion and submit my order Sowe could capture this as an ldquoOrderrdquo in the domain and carry on
However therersquos an obvious di983142ference between how I place orders
with these websites and say how a large corpora983156ion would place
orders Company A could place an order for 10000 widgets from one
of these online retailers but they probably wonrsquot do it through the
website the way I do theyrsquoll most likely submit a purchase order The
process for placing an order for them is quite di983142ferent You can even
throw in customer status (Gold Silver Bronze etc) as classifica983156ions
that may impact how an order is placed and received in the system
If these concepts are not modeled directly you can end up with a
ldquocanonical modelrdquo which becomes the source of constant con852070lict
when changes are needed (or understandings of the model becomes
clearer) Once yoursquove established seams or boundaries around your
models you must think about how to expose them to collabora983156ing
agents In other words you must think about your integra983156ion
rela983156ionships and how those are expressed
APIS AND MODULARITY
Modularity isnrsquot a new concept S983156ill it seems di983142ficult enough to get
right that people bend (or blend) architectures and seams so they
donrsquot have to deal with modularity outright Oh you have an order system over there Go ahead and share these implementa983156ions of Orderobjects No Stop sharing domain code thinking it will save you 983156ime
(or whatever your jus983156ifica983156ion is) and focus instead on designing
modules that hide their implementa983156ion details and expose only
certain concepts over APIs or contracts We want modules to be
independent insofar as they can change their implementa983156ion
details without a983142fec983156ing other modules Thatrsquos the goal But it
seems we get too preoccupied with defining the right API up front
and focusing on WSDL-like contracts Just like domain models and
boundaries APIs also evolve (like they must) you wonrsquot ever arrive
at the right API ldquoup frontrdquo
RUNTIME COUPLING
When we think of coupling we tend to think of technological
coupling Letrsquos not use Java RMI because thatrsquos a specific platform Letrsquosuse XML or JSON instead Or letrsquos not inherit from dependency injec983156ioncontainers because that 983156 ies us to the dependency injec983156 ion framework(just in case we want to change that in the future) These are all noble
goals but in my experience we get overly focused on design-983156ime
or technology-specific coupling and forget about much bigger
coupling phenomena For example the fallacies of distributed
compu983156ing s983156ill hold here The network is not a reliable transport
Our service collaborators may NOT receive our requests They may
not even be available When you start to think ldquoen983156ity servicesrdquo
ldquoac983156ivity servicesrdquo ldquoorchestra983156ion servicesrdquo and have large chains
of synchronous calls between servicesmdashturtles all the way downmdash
you can start to see how this may break down By designing proper
models boundaries and APIs we are aiming toward autonomously
deployed and managed systems But if you have large chains
of synchronous calls like this yoursquove most likely got some badrun983156ime coupling making changes to a service necessitates
changes to other services you collaborate with (in a ripple e983142fect)
and if services are not available you run the risk of outages etc
Asynchronous publish-subscribe style architectures can alleviate
some of this coupling
CONWAYrsquoS LAW In 1968 Melvin Conway wrote ldquoorganiza983156ions which design
systems are constrained to produce designs which are copies
of the communica983156ion structures of these organiza983156ionsrdquo and
he couldnrsquot be more correct Large organiza983156ions have been
designed from the top down for one thing e983142ficiency Following
reduc983156ionist ldquoscien983156ificrdquo management theories since the early
1900s our companies have been focused on reducing variability
and op983156imizing each part of the organiza983156ion Which is why not
surprisingly in IT organiza983156ions we have ldquoDBAsrdquo and ldquoUI expertsrdquoand ldquoQA teamsrdquo Each team focuses on its area of specializa983156ion
with scru983156iny and op983156imiza983156ion Then following Conwayrsquos Law
we have three-983156ier applica983156ionsmdashor ldquolayersrdquomdashthat correspond
with each of those teams the UI layer the Business Logic layer the
Database Layer and so on Then we throw things over the fence to
Ops and QA etc Although this may be the hardest thing to evolve
the organiza983156ional structure and the culture of its employees has
the most profound implica983156ion on how we build our distributed
systems If we want to be an adap983156ive connected company we need
to explore what that means to our organiza983156ional management
philosophies and structures Then as a corollary we have a
much better chance at building truly autonomous decoupled
systems that can scale individually adapt to failures and adverse
condi983156ions and change to meet market challenges
Without these fundamentals at the forefront we run the risk
of rabidly adop983156ing the latest and greatest fads and choking
our businesses in the area they need to be most adap983156ive IT
and technology
CHRISTIAN POSTA (christianposta) is a Principal Middleware
SpecialistArchitect at Red Hat and well known for being a frequent blogger
speaker open-source enthusiast and committer on Apache ActiveMQ and
Apache Camel and others Christian has spent a great deal of time working with
large companies creating and deploying large scale distributed architecturesmdash
many of which are now called Microservices based He enjoys mentoring training and
leading teams to be successful with distributed systems concepts microservices DevOps
and cloud-native application design
ldquoWill microservices help merdquoThe answer to the question
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
SmartBear helps you to deliver enterprise-ready APIs with the worldrsquos best SOAPREST design tes983156ingvirtualiza983156ion and performance monitoring solu983156ions in a single platform Ready API
BLOG blogsmartbearcom WEB SITE smartbearcomTWITTER ready_api
Ready API by SmartBear
CASE STUDY
Healthcare Data Solu983156ions (part of IMS Health) aggregates large datasets from healthcare providers using APIs to e983142fec983156ively deliver thisdata The 983156ime required for the so1048678tware QA team to test mul983156iple data
sets set up tes983156ing ar983156ifacts and diagnose root causes of issues impededits ability to release so1048678tware updates ldquoAt one point we had to delaythe release of a project for a whole fiscal quarter which had significantripple e983142fects on other priori983156ies It some983156imes took us two or three daysjust to set up our tes983156ing processesrdquo
Since deploying SoapUI NG Pro HDS has gained the ability to data-drive automated API testsmdashreducing the set-up of their ini983156ial tes983156ingprocesses by 80
With SoapUI NG Pro HDS sees ldquo improvements that put us onto the pathof even better tes983156ing coverage We knew capabili983156ies such as these wouldsignificantly streamline our API tes983156ing processesrdquo
STRENGTHS
bull Comprehensive capabili983156ies for tes983156ing SOAP and REST APIs in
SoapUI NG Pro
bull API mocking and lightweight service virtualiza983156ion through
ServiceV Pro
bull Easy-to-employ API load tes983156ing for on-premise and cloud-
based services
bull API-specific security scans to check for common vulnerabili983156ies
bull Integra983156ion to API Management Issue Tracking Version
Control amp descrip983156ion formats
CATEGORY
API Lifecycle and
Quality Tools
NEW RELEASES
Quarterly
OPEN SOURCE
Commercial and
Open Source
NOTABLE CUSTOMERS
bull Intel
bull Microso1048678t
bull GE
bull Disney
bull Cisco
bull Bank of America
bull Johnson amp Johnson
bull American Airlines
For a decade mainstream API development has been in a torrid
transi983156ionary period over how API technologies connect the
world SOAP and RESTmdashtwo dominant API design paradigmsmdash
are at odds both technically and strategically
The decade-long con852070 lict between modern minimalist patterns
employed by RESTful APIs and older SOAP-style enterprise
service-oriented architecture presents two important challenges
for businesses looking to employ faster methodologies on
integra983156ion projects
1 Transla983156ion between XML-heavy SOAP web services and
JSON-centric REST APIs
2 Professional skills and tooling di983142ferences between SOAP
and REST development prac983156ices
Enterprises delivering reliable integra983156ions face serious
challenges in the mixed landscape of API technologies both
people and tools must align to your API strategy
HOW LONG WILL SOAP STILL BE AROUND
Modern web and mobile markets are pushing people to learn new
skills and employ new tools Since 2011 many businesses have
been making the switch internally and externally from SOAP an
SOA to API strategies that assume more modern RESTful pattern
This switch comes at a cost lack of standards around security
iden983156ity and interoperability hinder rapid migra983156ion but
REST has been catching up quickly as seen in open-source
specifica983156ions like Swagger JSON-Schema JSON-LD JSON APIand other solu983156ions
BOTTOM LINE ENTERPRISES MUST STILL SUPPORT A MIXED
INTEGRATION LANDSCAPE
Things we build have a tendency to s983156ick around as is the case
with SOAP in enterprises REST-style APIs are now the preferred
approach when building new systems intended to replace legacy
integra983156ions but enterprise API professionals need to be adept at
both SOAP and REST carrying with them tools that also traverse
mul983156iple architectural styles quickly and 852070 lawlessly
People are the driving force behind great technology Get983156ing you
team dynamics right is as important to shipping accurate safeand reliable APIs as get983156ing your toolchain streamlined both wor
hand in hand The better your enterprise is at people and tools th
better your APIs will be
WRITTEN BY PAUL BRUCE
A P I P R O D U C T M A N A G E R S M A R T B E A R
Navigating SOAP to
REST Migrations
Like a Pro
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2031DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
MORE AND MORE COMPANIES ARE DESCRIBING THEIR
SUCCESS STORIES REGARDING THE SWITCH TO A SERVICE-
oriented architecture As w ith any technological upswing therersquos
a clear and palpable hype factor involved (Big Datatrade or The
Cloudtrade anyone) but obviously itrsquos not just 852070lu983142f
While microservices and SOA have seen a staggering rate of
adop983156ion in recent years the mindset of developers o1048678ten seems
to be stuck in the past I think this is at least in part because
we seek a mental model we can reason about Itrsquos why we build
abstrac983156ions in the first place In a sense I would argue therersquos
a comparison to be made between the explosion of OOP in the
early 90rsquos and todayrsquos SOA trend A1048678ter all SOA is as much about
people scale as it is about workload scale so it makes sense from
an organiza983156ional perspec983156ive
THE PERILS OF GOOD ABSTRACTIONS
While systems are becoming more and more distributed
abstrac983156ions are attemp983156ing to make t hem less and less complex
Mesosphere is a perfect example of this attemp983156ing to provide
the ldquodatacenter opera983156ing systemrdquo Apache Mesos allows you
to ldquoprogram against your datacenter like itrsquos a single pool of
resourcesrdquo Itrsquos an appealing proposi983156ion to say the least PaaS-
like Google App Engine and Heroku o983142fer similar abstrac983156ionsmdash
write your code without thinking about scale The problem is you
absolutely have to think about scale or yoursquore bound to run into
problems down the road And while these abstrac983156ions are nice
they can be dangerous just the same Welcome to the perils of
good abstrac983156ions
I like to talk about App Engine because I have firsthand
experience with it Itrsquos an easy se ll for startups It handles
spinning up instances when you need them turning t hem
down when you donrsquot Itrsquos your app server database caching
job scheduler and task queue all in one and it does it at scale
Therersquos vendor lock-in sure yet it means no ops no sysadmins
no overhead Push to deploy But itrsquos a leaky abstrac983156ion It has
to be App Engine scales because itrsquos distributed but it allowsmdash
no encouragesmdashyou to write your system as a monolith Thedatastore memcache and task queue accesses are masked as
RPCs This is great for our developer mental model but it will bite
you if yoursquore not careful
RPC is consistently at odds with distributed systems I would
go so far as to say itrsquos an an983156i-pattern in many cases RPC
encourages wri983156ing synchronous code but distributed systems
are inherently asynchronous The network is not reliable The
network is not fast The network is not your friend Developers
who either donrsquot understand this or donrsquot realize whatrsquos
happening when they make an RPC will wr ite code as if they
were calling a func983156ion It will sure as hell look like just calling
a func983156ion When we think synchronously we end up with
systems that are slow fault intolerant and generally not scalable
To be quite honest however this is perfectly acceptable for 90
of startups as they are get983156ing o983142 f the ground because they donrsquot
have workloads at meaningful scale
Therersquos certainly some irony here One of the selling points of App
Engine is its ability to scale to large amounts of tra983142fic yet the vast
majority of startups would be perfectly suited to scaling up rather
than out perhaps with some failover in place for good measure
Stack Over852070low is the poster child of scale-up architecture In
truth your architecture should be a func983156ion of your access
patterns not the other way around (and App Engine is very much
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
The greatest value of enterprise integra983156ion is being seen in
two areas 1) legacy data able to be accessed to solve business
problems and 2) using data to improve the customer and employee
experience Giving employees access to legacy data fosters
innova983156ion and empowers employees to solve business problems
themselves Unlocking data can transform a business (eg Airbnb
and Uber) Integra983156ion of previously siloed data enables people to
make more intelligent decisions
At the same 983156ime data can be used to improve the customer
experience By giving employees a 360-degree view of the customer
companies are able to make proac983156ive recommenda983156ions making
customersrsquo lives simpler and easier Social listening enables
customer-facing employees to address customer concerns in a
983156imely manner either in person or virtually via mobile devices
The skills that make someone good at enterprise integra983156ion are
broad reaching It starts with knowing the problem yoursquore trying
to solve and then being able to iden983156ify the op983156imal technical
solu983156ion Superior performers also understand patterns scenarios
web protocols frameworks and architectures Problem-solvingskills are beneficial as is understanding the fundamental pain
points the technology addresses It also helps to have familiarity
with the systems you are integra983156ing (eg CRM ERP etc) The most
successful have the skill to see the ldquobutter852070 ly e983142fectrdquomdashif I change
this herersquos how it will a983142fect my client and their customers
The most frequently used programming language con983156inues to be
Java followed closely by JavaScript Other languages platforms
opera983156ing systems or frameworks that were men983156ioned included
Android C C++ iOS Nodejs NET and Scala
The con852070luence of APIs the cloud mobile and the Internet of
Things (IoT) are driving the evolu983156ion of enterprise integra983156ion
Unlike distributed compu983156ing mobile and cloud have standards
for interconnec983156ion The shi1048678t to mobile and API platform services
have centralized the work that needs to be done APIs and
integra983156ion are cri983156ical for IoT to achieve its projected growth levels
Everything is able to talk to everything else in the cloud thanks
much to RESTful design The cloud has removed the need for much
hardware infrastructure and funding APIs have made everything
faster reduced costs and increased speed to market The data
center can now reside solely in the cloudmdashthough the pendulum
may be swinging as some companies prefer hybrid solu983156ions wherethey have an on-premise appliance with on-demand ldquoburstrdquo needs
met in the cloud With all of the devices connec983156ions and APIs
wersquore seeing a renaissance around messaging however this 983156ime
itrsquos data rather than voice
Obstacles to success of enterprise integra983156ion projects at client sites
seem to revolve around unrealis983156ic expecta983156ions and the failure by
vendors to do proper due diligence before proposing a solu983156ion Itrsquos
cri983156ical for the vendor to understand the business problem they are
solving and the poten983156ial for that problemmdashand solu983156ionmdashto scale
over 983156ime Understanding the business problem will help the vendor
iden983156ify the op983156imal solu983156ion versus a more complex solu983156ion than
is necessary Understanding the poten983156ial for scalability will ensure
the vendor provides a solu983156ion that can scale to meet the clientrsquos
needs over 983156ime without latency becoming an issue
Some vendors are chasing the money over promising what they
can deliver or providing more complex expensive solu983156ions than
are necessary Hype can get in the way and create unrealis983156ic
expecta983156ions for clients People have a tendency to focus on the
short cycle 983156imes of Agile without considering the long-termimplica983156ions of their decisions or the extensibility of the platform
The primary concern around enterprise integra983156ion is explosive
complexity and extensibility We must be conscien983156ious of the
data wersquore collec983156ing and sending and ensure we are addressing
a business purpose in doing so Other concerns are companies
that are building closed versus open solu983156ions as well as on-going
concerns with security as more and more devices are brought to
market Failure to adhere to proven patterns and architectures will
lead to short-cuts which lead to security 852070laws Lastly moving the
enterprise to the cloud is not as easy as it soundsmdashis it really in the
businessrsquos best interest to move their en983156ire enterprise into the cloud
or is a hybrid solu983156ion more appropriate based on business needs
The future of enterprise integra983156ion appears to be centered around
APIs and the ease of accessibility they promise in the cloudmdash
whether itrsquos robustness or steady accessibility We are beginning
to see the internet of APIs This is driven by IoT and mobile with
mobile leading the charge right now and IoT on its heels To ensure
successful growth we need to look for opportuni983156ies to standardize
platforms that can scale and maintain security Doing so will result
in an improved employee and customer experience
The key advice for developers is to keep enterprise integra983156ion
as simple as possible Donrsquot try to ldquoboil the oceanrdquo Focus on the
business objec983156ive know the business problem know the business
process and make it as easy as possible for the business to
understand and use Know t he user needs for the problem yoursquore
solvingmdashthe needs of engineering are very di983142ferent from those
of finance or marke983156ing Know what middleware is available
before you start wri983156ing code Lastly with regards to mobile know
the value of two bytes This will add up to a lot of savingsmdashof
bandwidth and moneymdashover the next few years
The execu983156ives we spoke with are working on their own products
or serving clients Wersquore interested in hearing from developers and
other IT professionals to see if these insights o983142fer real value Is it
helpful to see what other companies are working on from a senior
industry-level perspec983156ive Do their insights resonate with what
yoursquore experiencing at your firm
We welcome your feedback at researchdzonecom
04
05
06
07
09
10
11
08
TOM SMITH is a Research Analyst at DZone who excels at gathering
insights from analyticsmdashboth quantitative and qualitativemdashto drive
business results His passion is sharing information of value to help
people succeed In his spare time you can fnd him either eating at
Chipotle or working out at the gym
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
API MANAGEMENT PLATFORM Middleware
used to oversee the process of publishing promo983156ing
and configuring APIs in a secure scalable environment
platforms usually include tools for automa983156ion
documenta983156ion versioning and monitoring
APPLICATION PROGRAMMING INTERFACE
(API) A so1048678tware interface that allows users to
configure and interact with other programs usually
by calling from a list of func983156ions
BUSINESS PROCESS MANAGEMENT (BPM)
A work852070low management strategy used to monitor
business performance indicators such as revenue
ROI overhead and opera983156ional costs
DOMAIN-DRIVEN DESIGN (DDD) A so1048678tware
design philosophy that bases the core logic and
architecture of so1048678tware systems on the model of the
domain (eg banking health care)
ENTERPRISE APPLICATION INTEGRATION
(EAI) A label for the tools methods and services
used to integrate so1048678tware applica983156ions and
hardware systems across an enterprise
ENTERPRISE INTEGRATION (EI) A field that
focuses on interoperable communica983156ion between
systems and services in an enterprise architecture it
includes topics such as electronic data interchange
integra983156ion patterns web services governance and
distributed compu983156ing
ENTERPRISE INTEGRATION PATTERNS
(EIP) A growing series of reusable architectural
designs for so1048678tware integra983156ion Frameworks such as
Apache Camel and Spring Integra983156ion are designed
around these patterns which are largely outlined on
EnterpriseIntegra983156ionPatternscom
ENTERPRISE JAVABEANS (EJB) A server-side
component architecture for modular construc983156ion
of distributed enterprise applica983156ions one of several
APIs for Java Enterprise Edi983156ion
ENTERPRISE SERVICE BUS (ESB) A u983156ility
that combines a messaging system with middleware
to provide comprehensive communica983156ion services
for so1048678tware applica983156ions
EVENT-DRIVEN ARCHITECTURE (EDA) A
so1048678tware architecture pattern that orchestrates
behavior around the produc983156ion detec983156ion and
consump983156ion of events
EXTRACT TRANSFORM AND LOAD (ETL) A
process for integra983156ing large data batches through
HYPERMEDIA AS THE ENGINE OF
APPLICATION STATE (HATEOAS) A principle
of REST applica983156ion architecture where clients
interact with a network applica983156ion en983156irely through
hypermedia provided by applica983156ion servers
INTEGRATION PLATFORM-AS-A-SERVICE
(IPAAS) A set of cloud-based so1048678tware tools that
govern the interac983156ions between cloud and on-
premises applica983156ions processes services and data
INTERFACE DEFINITION LANGUAGE
(IDL) A specifica983156ion language used to describe
a so1048678tware componentrsquos interface in a language-
agnos983156ic way enabling communica983156ion between
so1048678tware components that are written in di983142ferent
programming languages
JAVA MANAGEMENT EXTENSIONS (JMX)
A Java technology that provides lightweight
management extensions to Java-based applica983156ions
and interfaces
JAVA MESSAGE SERVICE (JMS) An API that
func983156ions as message-oriented middleware designed
for the exchange of asynchronous messages between
di983142ferent Java-based clients
JAVASCRIPT OBJECT NOTATION (JSON) An
open standard data exchange format based on
a JavaScript syntax subset that is text-based and
lightweight
MESSAGE BROKER A centralized messaging
program that translates and routes message This is
the basis of the hub and spoke messaging topology
MESSAGE-DRIVEN PROCESSING Acomputer model where clients send a service
request to a program that acts as a request broker for
handling messages from many clients and servers
MESSAGE EXCHANGE PATTERN (MEP) The
type of messages required by a communica983156ion
protocol the two major MEPs are request-response
(HTTP) and one-way (UDP)
MESSAGE GATEWAY An applica983156ion
component that contains messaging-specific code
and separates it from the rest of the applica983156ion
MESSAGING-ORIENTED MIDDLEWARE
(MOM) A layer of so1048678tware or hardware thatsends and receives messages between distributed
systems
MESSAGE QUEUE A so1048678tware component used
for communica983156ion between processesthreads
that harnesses asynchronous communica983156ion
protocols
MICROSERVICES ARCHITECTURE A system
or applica983156ion consis983156ing of small lightweight services
MIDDLEWARE A so1048678tware layer between the
applica983156ion and opera983156ing system that provides
uniform high-level interfaces to manage
services between distributed systems this
includes integra983156ion middleware which refers to
middleware used specifically for integra983156ion
OAUTH A common open standard for
authoriza983156ion
OPEN SOURCE GATEWAY INTERFACE
(OSGI) A Java framework for developing and
deploying modular programs and libraries
REMOTE PROCEDURE CALL (RPC) An inter-
process communica983156ion that causes a subrou983156ine
or procedure in another address space to execute
without needing to write any explicit code for that
interac983156ion
REPRESENTATIONAL STATE TRANSFER
(REST) A distributed stateless architecture that
uses web protocols and involves clientserverinterac983156ions built around a transfer of resources
RESTFUL API An API that is said to meet the
principles of REST
SECURITY ASSERTION MARKUP
LANGUAGE (SAML) An XML-based
language protocol for handling authen983156ica983156ion
and authoriza983156ion in a network or for web
development
SERVICE COMPONENT ARCHITECTURE
(SCA) A group of specifica983156ions intended for the
development of applica983156ions based on service-
oriented architecture
SIMPLE OBJECT ACCESS PROTOCOL
(SOAP) A protocol for implemen983156ing web
services that feature guidelines for communica983156ing
between web programs
SERVICE-ORIENTED ARCHITECTURE (SOA)
An architecture style that uses discrete so1048678tware
services (each with one clearly defined business
task) with well-defined loosely-coupled interfaces
that are orchestrated to work as a complete system
by sharing func983156ionality
WEB SERVICE A func983156ion that can be accessed
over the web in a standardized way using APIs
that are accessed via HTTP and executed on a
remote system
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) An XML-based language that describes
the func983156ionality of a web service and is necessary
for communica983156ion with distributed systems
WEB SERVICES DESCRIPTION LANGUAGE
(WSDL) A XML b d l h d ib
glossary
7232019 Enterprise integration Reference card
httpslidepdfcomreaderfullenterprise-integration-reference-card 2631DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRATION
ZONECOMGUIDES DZONErsquoS 2015 GUIDE TO ENTERPRISE INTEGRA
1
4
2
5
3
6
1
4
2
5
3
1
4
2
5
3
K E Y CHA RA CTE RIS T ICS OF M ICROS E RV ICE S
OPERATIONAL REQUIREMENTS FOR MICROSERVICES
MICROSERVICES QUICK REFERENCEldquoMicroservicesrdquo has emerged as a term to describe the components of applications that are decomposed or initially built with
single-purpose loosely-coupled services managed by cross-functional teams The idea of microservices has evolved from recent
trends focused on increasing the speed and efficiency of developing and managing software solutions including Agile methods
DevOps culture PaaS application containers and the widespread adoption of Continuous Integration and Continuous Delivery
This reference serves as a quick reminder of the essential principles and benefits of microservices Thanks to Arun Guptaauthor of DZonersquos Getting Started With Microservices Refcard for his help assembling this reference
DOMAIN-DRIVEN DESIGNFunctional decomposition can be easily achieved
using Eric Evansrsquo DDD approach and his concept
of Bounded Contexts
SERVICE REPLICATIONEach service needs to replicate typically
using cloning or partitioning There should be
a standard mechanism by which services can
easily scale based on metadata A PaaS cansimplify this functionality
INDEPENDENT DU RS (DEPLOY
UPDATE REPLACE SCALE)Each service can be independently deployed
updated replaced and scaled
RESILIENCYSoftware failure will occur so itrsquos important for
services to automatically take corrective action
to ensure user experience is not impacted
The Circuit Breaker pattern allows you to build
resilient software
EXPLICITLY PUBLISHED INTERFACEA producer service publishes an interface that is
used by a consumer service
SERVICE MONITORINGService monitoring and logging allow stakeholder
to take proactive action if for example a service
is consuming unexpected resources There are
open source tools that can aggregate logs fromdifferent microservices provide a consistent
visualization over them and make that data
available to business users
SINGLE RESPONSIBILITYPRINCIPLEEach service is responsible for a single part of
the functionality and does it well
SERVICE DISCOVERYIn a microservice world multiple services are typically
distributed in a PaaS environment Immutable
infrastructure is provided by containers or immutable
VM images Services may scale up and down basedon certain pre-defined metrics and the exact address
of a service may not be known until the service is
deployed and ready to be used The dynamic nature
of a servicersquos endpoint address is handled by service
registration and discovery tools
LIGHTWEIGHT COMMUNICATIONREST over HTTP STOMP over WebSocket and
other similar lightweight protocols are used for
communication between services
DEVOPSContinuous Integration and Continuous Deployment
(CICD) are very important in order for microservices-
based applications to succeed These practices are
required so that errors are identified early and so little
to no coordination is required between different teams
building different microservices
INDEPENDENT SCALINGEach microservice can scale independently
via sharding andor cloning with more CPU
or memory
POTENTIAL HETEROGENEITY ANDPOLYGLOTISMDevelopers are free to pick the language and
stack that are best suited for their service
EASY MAINTENANCEEach microservice is restricted to one function
feature making the code more readable and
compact improving load times
INDEPENDENT UPGRADESEach service can be deployed independent
of other services Developers can easily make
changes to services without having to coordinate
with other teams
IMPROVED COMMUNICATIONACROSS TEAMSA microservice is typically built by a full-stack tea
All members related to a domain work together
in a single team which significantly improves
collaboration and communication efficiency
FAILURE AND RESOURCE ISOLATIONA failing service whether itrsquos caused by a memory
leak or an unclosed database connection will
not affect the rest of the application or cause it to