Using SOA to Extend Beyond Your Four Walls, Part 2

(This is Part 2 of Matt’s series. To read part one, click here.) If SOA is intended to build a distributed application environment whose data sources are far from the end user with processing somewhere in between, then the next logical step is extending that processing onto a cloud resource.  In fact, the Ocean Observatory Initiative is already leveraging current commercial cloud providers within their distributed framework.  SOA and MOM (message oriented middleware) are two of the key paradigms used in the design of the OOI Cyber Infrastructure.  While this architecture incorporates cloud resources as a component of the overall distributed application, similar approaches can be used to migrate resources from local systems to a cloud provider. Let's start with a 'proper' SOA environment: decoupled processing and data sources using a pubsub messaging bus.  For sake of argument, it's an orchestrated environment, utilizing a centralized control hub.  Resources are tight and as always, the mission expands while the budget shrinks.  Faced with FDCCI activities, resources are about to get tighter.  But the CIO and risk managers have a new tool: cloud resources from a community platform cloud provider.  The security model is attractive, the platform tools are standards based Java tools like JBoss, the provider is another agency with the appropriate people and understanding of C&A, and the green light is lit for use.  The only question: how to do we get there? Migration from local resources to cloud resources can be onerous.  Replicating functionality on infrastructure outside your control can be problematic.  Redesigning monolithic applications to scale appropriately in an elastic service environment can prove overwhelming.  However, since we've already broken hard links between our applications with a proper SOA environment, we've got a leg up on the migration.  Parity and standards allow us to create a roadmap for shifting functionality into the cloud while maintaining the orchestrated and distributed environment we've already built. The promise of the cloud is two-fold, the first we've already seen here: offloading the management of the platform, from data center power and cooling through to the application server.  Selecting a cloud service that meets the goals of the Enterprise Architecture and the standards and practices of the development shop can provide you with a highly scalable and management free application deployment environment.  You could easily replace 'cloud' with a Service Oriented Infrastructure and have a SOI to match your SOA. The second promise of the cloud is scalable and fault tolerance.  This moves away from the implementation and back to architecture.  If you look back to earlier posts, I've talked about cloud being in the Technology domain of the EA.  SOA has its place in the Application domain.  But the important distinction is that cloud is pre-packaged hardware and infrastructure, SOA is a development and integration design principle.  Moving to a SOA paradigm will not only enable ad hoc interfaces to meet new requirements, but also allow for increased flexibility to meet scalability and availability needs and opportunities.