SOA is about reducing Platform Dependencies

As enterprises move from intra-SOA to inter-SOA deployments, these deployments will likely be over a network of some kind.  Many of the fundamental principles of Service-Oriented Architecture (SOA) are based on the idea of abstracting business services away from the actual platforms on which they will be deployed. This allows for the re-use and the composition of additional business services in a more agile fashion and reduces dependencies on underlying platforms. Also these business services can be co-located or, in theory, can be located anywhere in a zero latency network. While zero latency isn’t yet achievable, network latency is likely to continue to drop as network bandwidth continues to grow over time.

Will the Network become Transparent in SOA Deployments?

If a zero latency network was achievable, business services could be orchestrated and choreographed without any thought to the distance; wouldn’t the network essentially become transparent? What value-add would the SOA Network provide in this kind of scenario? From an architecture point of view this would be a best case scenario since this would be one less dependency in a SOA deployment. However we know better that once we expose business services beyond the enterprise the nature of SOA deployments become more complex and critical.

Richness of Messages means more Opportunity to better Manage SOA Deployments

The richness of SOAP messages associated with Web Services and SOA continues to grow as standards continue to grow. More information about the management of messages and associated services results in more metadata being transmitted across the network. Network appliances originally designed to accelerate XML, along with their associated software, are now being re-positioned as security, governance, and network management solutions. Once single function devices, SOA appliances are now capable of intercepting SOAP messages and interpreting policies associated with business services. It is also now possible to centrally manage these distributed devices from a network message management, security, and governance perspective.

Network Vendor and Service Provider’s Dilemma

As a vendor providing hardware, software, or network services; how can I transparently implement and provide value-add management of these SOA Networks at the same time? This is where the dilemma comes in: to be able to allow the SOA Architect to build Service-Oriented Environments and deploy SOA over a network with as little ease as possible but yet provide as much value add management of these SOAs at the same time.

The very thing that we tried to accomplish with SOA – abstraction away from specific platforms, has now moved to network.
Are we now creating dependencies on specific network hardware and software in SOA deployments? Did we move the problem somewhere else?

SOA Appliances and Networking Software will continue to grow.

As SOA moves beyond the enterprise SOA Networks will continue to grow in importance. As this happens we must move to continue to allow for the flexibility and choice of network platforms. Cisco has already started to position their Service-Oriented Network Architecture (SONA) as the Network Architecture of choice. Where are the other networking vendors?

_______________________________________________

>> Back to Main Page

Gary E. Smith
SOA Network Architect