For the past 40 years, networking within the corporate world has evolved in sync with IT. This may or may not change in 2006, depending on whether you believe the vision of Cisco Systems or the IT industry.
SONA is fundamentally different from the service-oriented architecture (SOA). It creates a three-layer framework by sandwiching the concept of an interactive services layer between software and networked infrastructure. The architecture concentrates communications intelligence in the network and assumes passive IT software and infrastructure environments.
To complicate the issue, a Cisco service is not an SOA service. An SOA service is defined as reusable software components with well-defined, published, standards-compliant interfaces that perform a specific function on behalf of a computing entity, such as a user or another software component. A SONA service has higher granularity from a software perspective, may or may not be reusable, has no published APIs, is vendor-specific and performs an interactive communication function between applications and infrastructure.
In December, two new SOA initiatives were put in place that will allow application virtualization to occur across a network: Service Component Architecture (SCA), created as a model for constructing and assembling networks of services; and Service Data Objects (SDO), created to define a common access methodology to data. SCA and SDO are multivendor IT industry initiatives that have no Cisco representation and will create further differentiation between SOA and SONA.
At first glance, SOAs and SONA can coexist; one is applicable to software, and the other to networking. Unfortunately, SONA will, in all probability, complicate and inhibit an optimized SOA deployment. If Cisco is intent on moving functions that formerly resided in software into the network and performing compute/server virtualization and management in SONA, then any corporate benefits derived from the implementation of a dual SOA/SONA may be limited.
From a corporate IT perspective, SONA produces more questions than answers. What modeling and development tools exist to blend SOA and SONA services into the business process? How does a corporate business application request a SONA service if it is not an SOA service? How can end-to-end virtualization or workflow-performance optimization occur in a multivendor SOA/SONA environment? Will SONA be compliant with future SCA and SDO industry standards — and what are the industry standards applicable to SONA? Will SONA have a network service bus similar to an SOA’s ESB? An SOA can be deployed using both insourced and outsourced infrastructure; can SONA be deployed in a similar manner?
The questions go on and on. But one final IT/networking industry and corporate IT question needs an answer: is SONA a creation of hubris or bad “marketecture”?
QuickLink 069408
– Dzubeck is president of Communications Network Architects. He can be reached at [email protected].
