What we know about SOA and ESBs

posted in: Architecture, Design | 0

Our use of Symfony is motivated by code re-use and a “Service Oriented Architecture” (SOA) vision.

Symfony plays the role of a “Web Services Framework”  because it offers the infrastructure to :

  • handle HTTP request and response flow
  • configurable routing to jobs, tasks, or functions
  • respond with well formed HTTP response messages

Doctrine ships with Symfony and integrates with it to provide connection to a few DataBase servers. Doctrine is also an Object Relational Mapper (ORM) and supports a “code first” approach to application development. It also manages DB Migrations to complete its offering.

Symfony as a “Web Services Framework” needs PHP to run, and PHP needs some kind of “Web Server” to send an receive HTTP messages.

Symfony also offers a modular architecture in the form of “Bundles”. This is good for code re-use at a community level which we prefer to the custom code approach.

When we see “Bundles” as “Services” Symfony becomes a “Service Oriented Architecture” based “Web Services Framework”.

What is really interesting is the dual level at which this is possible in Symfony. Not only is it possible for “Bundles” to be HTTP services, but it is possible for them to be internal Services to other Bundles. Thus Symfony supports the SOA idea both internally and externally.

When we implement a service using Symfony, it offers HTTP, PHP and Console APIs.

The HTTP interfaces we design are ReST level 2 and offer JSON, XML and HTML output.

Our choice is to develop Javascript Applications (AngularJS) which connect to Web Services created in Symfony and managed as SOA in the the bigger scheme of deployment.

That “bigger scheme” is where the complexity can easily overcome the novice architect.

If you think about the enterprise requirements the “solution” will most likely include a sustainable echo system with a

Platform for:

  • Big Data: Big data integration, quality, manipulation, governance and administration
  • Enterprise Integration: Build, connect, mediate, and control services and business processes
  • Universal BPM: Data, application and process integration and management
  • Data Management: Data integration, profiling, cleansing, matching and monitoring
  • Data Services: Build, integrate, mediate data, messages and application services
  • MDM: Master and service-enable any domain applying data governance policies

ESBs normally perform “Enterprise Integration” and “Data Services” tasks quite well.

So why not use an ESB from the start?

“Misuse of ESBs leads to overly complex architectures that can be more difficult to remedy than a straightforward Web services-based architecture that omits the ESB in early versions of an enterprise application…” read this


Leave a Reply