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.

	express delivery
	• 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 Sponsored links: your text link here

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.

Application	Applications written to run over the network Examples: email, file transfer, order-service, HR, ...
Presentation	Protocol and data conversion, transport-independent policies Examples: encryption, QoS routing, caching, security
Session	Session management, checkpointing, reliable delivery Examples: HTTP 1.1, SSL, SQL, NFS, RPC
Transport	Flow control, error checking, guaranteed delivery Examples: TCP
Network	Logical->physical address translation, route and congestion management Examples: IP, X.25
Data link	Packets-to-bits conversion, data frames Examples: MAC, LLC
Physical	Transmits 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

• 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.

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.

Recommendation

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