to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


> opinion > vendor viewpoint

Web services and the forgotten OSI Layer Six

by Sekhar Sarukkai & David Cohen
September 5th, 2003

A large fraction (by some estimates 70%) of IT budgets goes toward ad hoc enhancements and maintenance of currently deployed application logic to support new application-level policies (security, QoS, SLA, logging, monitoring, etc) that, in fact, do not change any of the core business logic.

• print  • comment

Operational policies, such as security and QoS, do not belong in the application layer. Web services technologies enable a clean separation of this layer-six functionality from business logic.

Sekhar Sarrukai is co-founder and vice president of technology for Confluent Software. Dave Cohen is a vice president of the technology architecture group at Merrill Lynch (the views expressed here are those of the author and do not necessarily reflect those of Merrill Lynch).

Glossary terms: SOAP, HTTP, services management, QoS, SOA, lookup tool

Application policy changes are expensive endeavors because:

  1. Modification of application-level policies intricately entangled with business logic necessitates significant development and QA effort even for simple upgrades.
  2. Education and training on new standards and technologies usually requires significant up-front investment.
  3. Ad hoc visibility into policies being implemented makes it very difficult for verifying compliance with any policy guidelines.
The OSI (Open Systems Interconnect) network stack developed some 20 years ago by the International Organization for Standardization (ISO) provides a reference guideline for architecturally separating application policies from application logic, helping avoid the above pitfalls.

The seven-layered OSI stack
In the seven-layer OSI stack, the top three layers are usually bracketed together as "application layers," and the bottom four are bracketed together as "lower layers." Most descriptions of this stack are vague about demarcating the boundaries between the application and presentation layers.

ApplicationApplications written to run over the network
Examples: email, file transfer, order-service, HR, ...
PresentationProtocol and data conversion, transport-independent policies
Examples: encryption, QoS routing, caching, security
SessionSession management, checkpointing, reliable delivery
Examples: HTTP 1.1, SSL, SQL, NFS, RPC
TransportFlow control, error checking, guaranteed delivery
Examples: TCP
NetworkLogical->physical address translation, route and congestion management
Examples: IP, X.25
Data linkPackets-to-bits conversion, data frames
Examples: MAC, LLC
PhysicalTransmits raw bitstream over physical cable

The fundamental premise of a layered architecture requires that applications make use of facilities supported in lower layers in the network stack by delegation. In this model, applications do not change with changing configurations or policies at lower layers. For example, whether the session protocol used by the web server is HTTPS or HTTP, a web application (a JSP or ASP for instance) is not written differently. Instead, the transfer is handled as a session/transport layer binding (layers 4/5) that is set by appropriate web server deployment-time configurations.

Mature standards and products have helped applications abstract out functionality at the session layer and below. However, to date, many layer-six operations that do not belong in the application layer are, in fact, implemented as an integral part of the application code. This intertwined relationship between application logic and application policies have made it very difficult to clarify if layer six is merely a theoretical concept, or if it can be achieved in practice. In this context, web services standards are perhaps the first instance of a technology with the promise to make layer six a reality.

By focusing on leveraging web service standards (particularly related to SOAP headers) as a means for standardized sharing of context, operational policies (such as credential-based authentication, QoS routing, compression, encryption, caching, data validation, and protocol/data normalization) can be implemented and configured as layer-six functionality. Implemented as message interceptors (either in process as SOAP handlers, or as out-of-process SOAP intermediaries) they can seamlessly be introduced in the path of message flows to and from applications, without developer intervention.

These interceptors themselves are the primary creators and consumers of all message context.

Web service support for layer six
A great deal of attention has focused on the virtues of WSDL and SOAP enablement of applications as reusable network components. However, no attention has been given to viewing web services as an enablement technology for enforcing OSI layer-six policies.

Characteristics of web services technologies that enable this clean implementation of layer-six functionality are:

  • Standards are agnostic of the transport (typically layer 5 and below) or messaging model (synchronous, asynchronous, conversational, etc)
  • Standardized separation of message context and message content
  • Pervasive frameworks in place for seamless interception of messages via SOAP handler chains
  • Web service support for OSI layer 6 (click for larger version)
  • Centralized management and monitoring of layer-six policies enabling deployment and change of policies from a central location (via services management products from vendors like Confluent).

In this model, layer-7 applications need not be aware of [the existence of] headers and are only aware of the payload. The entire SOAP envelope is packaged into transport-specific packets by lower layers in the OSI stack.

Vendor offerings
Traditional management suites such as Tivoli and Openview support lower layers of the OSI stack, while Wiley, Mercury Interactive and other vendors support layer-7 application monitoring.

Vendor offerings (click for larger version)

Existing agents, such as Netegrity and Oblix for identity management, can be viewed as layer-six application policy handlers that are integrated into layer-six policy enforcers (either as interceptors or intermediaries) managed by a layer-six policy manager. To date, we believe Confluent Software is the only company that has consciously focused on supporting the forgotten layer 6 of the OSI stack.

IT groups should seriously evaluate web services as a key enabler of layer-six policies. For enterprises looking to deploy distributed applications in the context of a Service Oriented Architecture (SOA), use of centralized layer-six policy management enabling late-binding of client-side and service-side operational policies is a critical requirement. By incorporating this layered approach for policy enforcement, significant development and operational productivity gains can be achieved.

More on this topic


Adding policy to integration
SOA management software can put your business operations on cruise control ...


Confluent white papers
Download page giving access to a more detailed analysis of the topic on which this article is based.

OSI Reference Model illustrated
A diagram illustrating the 7-layer OSI Model, presented by

ISO/IEC 10731:1994
ISO's online catalogue page for purchasing the Open Systems Interconnection Basic Reference Model document


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.