Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 107 posts at DZone. You can read more from them at their website. View Full User Profile

SOA Perspective and API Echo

  • submit to reddit

The SOA perspective is reverberating into an API echo. During past SOA craze days  (2003-2008), proponents pitched SOA’s lofty benefits from both business and technical perspectives.  The benefits are real, yet sometimes very difficult to obtain. Surprisingly, today’s API proponents target similar benefits, but with an execution twist.

SOA business perspective and API Economy echo

SOA can be a strategy to align IT assets with business capabilities, business resources, and business processes.  SOA’s strong focus on sharing and re-use can optimize IT asset utilization.  Most intriguingly, SOA was promised to re-invent business-to-business interactions, enable better partner relationships, and support process networks[1].  External services were seen as a mechanism to extend an enterprise’s economic reach by reducing interaction costs, incorporating external business capabilities, enabling business specialization, and creating higher-value solutions that extend business processes across a partner network.

The current API economy buzz co-opts the SOA business value proposition, injects lessons learns, and rides popular industry trends (i.e. REST, Internet of Everything, mobile, Cloud services).

SOA technical perspective and API specialization

From a technical perspective, a SOA must exhibit three key design principles; service orientation, clean separation of concerns, and loose coupling.  Service orientation is gauged by service reusability, granularity, and architecture simplification.  Clean separation of concerns is gauged by testing separation of business logic from infrastructure, interface from implementation, and interface from capability.  Loose coupling is gauged by measuring interoperability, transaction control, and mediated interactions.

On the surface, RESTful APIs are simply a specialized version of web services, and provide similar technical benefits.  Both REST API design and SOA service design intend to expose discrete functionality via a well-defined interface.  The API endpoint and the service endpoint both serve as a core design unit, and teams deliver technical solutions by accessing, aggregating, composing, and orchestrating endpoint interactions.  Successful and scalable API and service-based solutions both require Internet messaging infrastructure, service level management, and security.  API management infrastructure extends traditional SOA infrastructure.


Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)