The basic concept of service orientation describes methods to expose and consume discrete operations or services that can be combined with a larger architecture for an enterprise application. Some of the additional service-oriented elements you must provide are security, routing, eventing and other core mechanisms that are critical to enterprise application building.

Four core tenets of service orientation to consider with regard to industry standards-based implementations are:

Service boundaries are explicit. Services are discrete units of operation. They perform one task and that task alone. Each service should be able to stand alone with no external dependencies on other services. This is what is meant by "loose coupling."

Services are autonomous. Services are not to be confused with application workflow or business process. Those might incorporate multiple services, but a service operates independently from other services. Standards like BPEL4WS are being developed to orchestrate processes that consist of services. Products such as Microsoft Connected Services Framework also provide collaboration that may leverage many services to form a collaboration context. But each service should still be built with reuse in mind and, therefore, be autonomous. The real value of autonomy is realized when the same services can be combined to form multiple business collaborations, which enables rapid service-oriented architecture (SOA) application development.

Services share schema and contract, not class. This is a key message for industry standards. Many standards resemble object technologies in that they mandate an "object's" time to live or describe when applications should delete, cancel, or act in a certain way. Services, however, behave differently. They share only a schema and contract. This means that, after the schema instance is sent, the service implementation or internals determine what to do with the data before sending back what is wanted for each contract. Service consumers and providers act independently of the internal implementations.

Service compatibility is determined based on policy. This grossly overlooked standard enforcement mechanism is something that most standards have not tried to tackle at this time, even though so many wrangle with the concept of version compatibility, security considerations, and message granularity, incorporating quasi-policy structures into their standard, essentially creating non-standard policy enforcement. Instead, all of these elements can be shared by way of WS-Policy statements.

These four guiding principles are important when you consider mechanisms for messaging standards into a service-oriented implementation.

It is possible to build industry standards into your SOA, but to do so you must consider several architectural elements:

• Mechanisms to construct the message payload
• Interoperability levels found in standards
• Policies to handle version compatibility and data granularity
• User Simple Object Access Protocol (SOAP) headers to embed standards-based processing elements

As service orientation and related standards mature, Microsoft updates its Web service stacks accordingly. Microsoft also participates in Standards Development and Establishment. WSE is the Microsoft implementation of Web Service Standards until the release of Indigo.