SOA Principles

SOA Principles

Service-oriented architecture ( SOA ) is based on the four fundamental tenets that follow:

1. Explicit Boundaries

Everything needed by the service to provide its functionality should be passed to it when it is invoked. All access to the service should be via its publicly exposed interface; no hidden assumptions must be necessary to invoke the service. “Services are inextricably tied to messaging in that the only way into and out of a service are through messages”. A service invocation should – as a general pattern – not rely on a shared context; instead service invocations should be modeled as stateless. An interface exposed by a service is governed by a contract that describes its functional and non-functional capabilities and characteristics. The invocation of a service is an action that has a business effect, is possibly expensive in terms of resource consumption, and introduces a category of errors different than those of a local method invocation or remote procedure call. A service invocation is not a remote procedure call.

While consuming and providing services certainly should be as easy as possible, it is therefore undesirable to hide too much of the fact that an interaction with a service takes place. The message sent to or received from the service, the service contract, and the service itself should all be first-class constructs within the SOA. This means, for example, that programming models and tools that are used should at least provide an API that exposes these concepts to the service programmer. In summary, a service exposes its functionality through an explicit interface that encapsulates its internals; interaction with a service is an explicit act, relying on the passing of messages between consumer and provider.

2. Shared Contract and Schema, not Class

Starting from a service description (a contract), both a service consumer and a service provider should have everything they need to consume or provide the service. Following the principle of loose coupling, a service provider can not rely on the consumer’s ability to reuse any code that it provides in its own environment; after all, it might be using a different development or runtime environment. This principle puts severe limits on the type of data that can be exchanged in an SOA. Ideally, the data is exchanged as XML documents validatable against one or more schemas, since these are supported in every programming environment one can imagine.

As a consequence, adherence to this principle is not possible in a DCOM-based or RMI-based environments – which basically rules them out as a valid option for SOA.

3. Policy-driven

To interact with a service, two orthogonal requirement sets have to be met:

1.the functionality, syntax and semantics of the provider must fit the consumer’s requirements,
2.the technical capabilities and needs must match.
For example, a service provider may offer exactly the service a consumer needs, but offer it over JMS while the consumer can only use HTTP (e.g. because it is implemented on the .NET platform); a provider might require message-level encryption via the XML Encryption standard, while the consumer can only support transport-level security using SSL. Even in those cases where both partners do have the necessary capabilities, they might need to be “activated” – e.g. a provider might encrypt response messages to different consumers using different algorithms, based on their needs.

To support access to a service from the largest possible number of differently equipped and capable consumers, a policy mechanism has been introduced as part of the SOA tool set. While the functional aspects are described in the service interface, the orthogonal, non-functional capabilities and needs are specified using policies.

4. Autonomous

Related to the explicit boundaries principle, a service is autonomous in that its only relation to the outside world – at least from the SOA perspective – is through its interface. In particular, it must be possible to change a service’s runtime environment, e.g. from a lightweight prototype implementation to a full-blown, application server-based collection of collaborating components, without any effect on its consumers. Services can be changed and deployed, versioned and managed independently of each other. A service provider can not rely on the ability of its consumers to quickly adapt to a new version of the service; some of them might not even be able, or willing, to adapt to a new version of a service interface at all (especially if they are outside the service provider’s sphere of control).

5. Wire formats, not Programming Language APIs

Services are exposed using a specific wire format that needs to be supported. This principle is strongly related to the first two principles, but introduces a new perspective: To ensure the utmost accessibility (and therefore, long-term usability), a service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service. For example, it is a useful test for conformance to this principle to consider whether it is possible to consume or provide a specific service from a mainstream dynamic programming language such as Perl, Python or Ruby. Even though none of these may currently play any role in the current technology landscape, this consideration can serve as a litmus test to assess whether the following criteria are met:

•All message formats are described using an open standard, or a human readable description
•It is possible to create messages adhering to those schemas with reasonable effort without requiring a specific programmer’s library
•The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard
•At least one of the transport (or transfer) protocols used to interact with the service is a (or is accessible via a) standard network protocol

6. Document-oriented

To interact with services, data is passed as documents. A document is an explicitly modeled, hierarchical container for data. Self-descriptiveness is one important aspect of document-orientation. Ideally, a document will be modeled after real-world documents, such as purchase orders, invoices, or account statements. Documents should be designed so that they are useful on the context of a problem domain, which may suggest their use with one or more services.

Similarly to a real-world paper document, a document exchanged with a service will include redundant information. For example, a customer ID might be included along with the customer’s address information (although the customer ID would be enough). This redundancy is explicitly accepted since it serves to isolate the service interface from the underlying data model of both service consumer and service provider. Whena document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. While not an absolute required, it can usually be assumed that XML will be used as the document format/syntax.

Messages flowing between participants in an SOA connect disparate systems that evolve independently of each other. The loose coupling principle mandates that the dependence on common knowledge ought to be as small as possible. When messages are sent in a Distributed Objects or RPC infrastructure, client and server can rely on a set of proxy classes (stubs and skeletons) generated from the same interface description document. If this is not the case, communication ceases on the assumption that the contract does not support interaction between those two parties. For this reason, RPC-style infrastructures require synchronized evolution of client and server program code.

This is illustrated by the following comparison. Consider the following message:

2006-03-1347113and compare it to:

2006-03-13 4711 3While it is obvious that the second alternative is human-readable while the first one is not, it is also notable that in the second case, a participant that accesses the information via a technology such as XPath will be much better isolated against smaller, non-breaking changes than one that relies on the fixed syntax. Conversely, using a self-descriptive message format such as XML while still using RPC patterns, such as stub and skeleton generation, serves only to increase XML’s reputation as the most effective way to waste bandwidth. If one uses XML, the benefits should be exploited, too. (See this paper for an excellent discussion of why many current Web services stacks fail this test.)

7. Loosely coupled

Most SOA proponents will agree that loose coupling is an important concept. Unfortunately, there are many different opinions about the characteristics that make a system “loosely coupled”. There are multiple dimensions in which a system can be loosely or tightly coupled, and depending on the requirements and context, it may be loosely coupled in some of them and tightly coupled in others. Dimensions include:

•Time: When participants are loosely coupled in time, they don’t have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them, although the approach taken for this is irrelevant. When one participant sends a message to the other one, it does not rely on an immediate answer message to continue processing (neither logically, nor physically).
•Location: If participants query for the address of participants they intend to communicate with, the location can change without having to re-program, reconfigure or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses.
•Type: In an analogy to the concept of static vs. dynamic and weak vs. strong typing in programming languages, a participant can either rely on all or only on parts of a document structure to perform its work.
•Version: Participants can depend on a specific version of a service interface, or be resilient to change (to a certain degree). The more exact the version match has to be, the less loosely coupled the participants (in this dimension). A good principle to follow is Postel’s Law: Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept (and possibly even tolerant of errors), while service consumers should do their best to conform to exact grammars and document types. This increases the overall system’s stability and flexibility.
•Cardinality: There may be a 1:1-relationship between service consumers and service providers, especially in cases where a request/response interaction takes place or an explicit message queue is used. In other cases, a service consumer (which in this case is more reasonably called a “message sender” or “event source” may neither know nor care about the number of recipients of a message.
•Lookup: A participant that intends to invoke a service can either rely on a (physical or logical) name of a service provider to communicate with, or it can perform a lookup operation first, using a description of a set of capabilities instead. This implies a registry and/or repository that is able to match the consumer’s needs to a providers capabilities (either directly or indirectly).
•Interface: Participants may require adherence to a service-specific interface or they may support a generic interface. If a generic interface is used, all participants consuming this generic interface can interact with all participants providing it. While this may seem awkward at first sight, the principle of a single generic (uniform) interface is at the core of the WWW’s architecture.
It is not always feasible nor even desirable to create a system that is loosely coupled in all of the dimensions mentioned above. For different types of services, different trade-offs need to be made. More discussion about dimensions of loose coupling can be found in Carlos Perez’s excellent writings, e.g. here or here.

8. Standards-compliant

A key principle to be followed in an SOA approach is the reliance on standards instead of proprietary APIs and formats. Standards exists for technical aspects such as data formats, metadata, transport and transfer protocols, as well as for business-level artifacts such as document types (e.g. in UBL).

While this may seem absolutely obvious to many, some argue that a proprietary solution, such as those provided by some EAI or messaging vendors, follows SOA principles. This principle highlights the importance of standards – the more, the better. Of course it’s arguable what relevance a specific has as there are so many to choose from. The most important aspect of any standard is its acceptance (which basically translates to “Microsoft needs to be on the author list” in case of Web services).

9. Vendor independent

No architectural principle should rely on any particular vendor’s product. To transform an abstract concept into a concrete, running system, it’s unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. This implies reliance on both interoperability and portability standards as much as reasonably possible. As a result, a service provider or service consumer can be built using any technology that supports the appropriate standards, not restricted by any vendor roadmap.

10. Metadata-driven

All of the metadata artifacts within the overall SOA need to be stored in a way that enables them to be discovered, retrieved and interpreted at both design and run time. Artifacts include descriptions of service interfaces, participants, endpoint and binding information, organizational units and responsibility, document types/schemas, consumer/provider relationships etc. As much as possible, usage of these artifacts should be automated by either code generation or interpretation and become part of the service and participant life cycle.

This concludes my list of principles. Even if you don’t agree with all of them – and frankly, I don’t expect you to, at least not with all of them -, I hope you can use them to fuel some discussion!

Passing Client Certificate for authentication to Web Service in ASP.NET Method

Passing Client Certificate for authentication to Web Service in ASP.NET Method

To pass Client Certificate for authentication to Web Service in ASP.NET Method , we need to use Web Service Enhancements 2.0 or 3.0 .

Below code shows passing client certificate using WSE 2.0 :

WSE 2.0 method
// Get certificates under Personal in Local Machine Store
X509CertificateStore store =
// Get Certificate Collection with below Subject
X509CertificateCollection col =
X509Certificate cert = null;
cert = col[0];
// Add Certificate to Web Service to pass it

Below code shows passing client certificate using WSE 3.0 :
WSE 3.0 method

X509Storestore = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindByIssuerName, certHash, false);
if (certs.Count == 1)
{X509Certificate2 cert =

// Add Certificate to Web Service to pass it

WSE 3.0 is used to find client certificates in Local Machine and Personal store where as WSE 2.0 is used to find client certificates in Local Machine store but it cannot find certificates in Personal store.


Webservice Questions : Difference between web services & remoting?

Difference between web services & remoting?

1) Protocol :

 Webservice can be accessed over HTTP protocol . Remoting can be accessed over any protocol (including TCP, HTTP, SMTP etc)

2) Interoperability :

Webservices support interoperability across platforms, and are ideal for heterogeneous environments. Remoting requires the client be built using .NET, enforcing homogenous environment.

3) Ease of programming :

Webservice is easy to create and deploy . Remoting is complex to create

4) State Management :

Webservices are stateless . Remoting support for both stateful and stateless environments through Singleton and SingleCall objects

Service-Oriented Architecture ( SOA )

Service-Oriented Architecture ( SOA )


In today’s technology-driven world with globalization, rapid business changes and with ever growing challenges posed by integration between globally distributed systems , there is a strong need to ‘loosely couple software systems’ to enable everyone to use them without dealing with issues concerning the platform and the language the systems are written in.

‘Service-Oriented Architecture’ makes this possible by integrating services provided by service-providers, with a system at the consumer-end that needs to avail those services. SOA is not simply a set of services. SOA is the policies, frameworks, and practices under which the correct services are provided.

SOA and Web Services – An Analysis

A common misconception about SOA is that using web-services technology makes whatever you are using SOA. The core reason for that is the poor naming choice for methods that are exposed through http which were named web-services. For example one of the popular books on SOA “Service oriented Technologies: a Field guide to integrating XML and Web-Services” by Thomas Earl gives the impression that SOA equals WS* (even though that buried in the book, there’s an explanation hat WS* is not the only possible technology for SOA). There are many other sources that give the same impression.

Nevertheless, Just a bunch of web-services (JBOWS as Joe McKinderik named them) does not an SOA make – in fact thatisn’t really different from Remote Procedure Calls (RPC) using any other technology be that CORBA, DCOM or anything else. The way I see it saying that SOA is using web-services is just plainly wrong and not away to define SOA.

One could argue that web services was the first step on the road to SOA. Is that statement true?
Yes and No.
No, in that you can have an SOA solution without using ASP.NET web services.
Yes, in that it is a great beginning to something much larger.

It is possible to have a web service that follows no SOA principles and a web service that exhibits wonderful SOA traits.

For example, a good web service is almost self-describing, providing useful information. I want to hit a web service that gives me stock quotes, or lets me buy or sell stocks, or tells me how my portfolio is doing.

In the case of the book publisher, I want a web service that tells me information about my order. These are web services that exhibit SOA traits.

Service Oriented architecture:

At the enterprise architecture level, it is always about the business. This is not a bad thing, on the contrary, the enterprise architecture perspective should be focused on the business needs in order to make sure IT serves the business and not vice versa.

The emphasis from the business perspective is on “service orientation”.

Consider for example the SOA definition from Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology – Eric A. Marks, Michael Bell :

“SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network.

“Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.”

In a nutshell, they can be summarized as follows:

“from the business point of view SOA is about analyzing the business to identify business areas and business processes. Followed by defining services to represent these “areas” .

Services expose their capabilities through message interfaces. The services can then be choreographed or orchestrated to realize the business processes.

While the on the business side of the fence the emphasis is on” Service Orientation” or SO – on the technical front the emphasis is on the A of SOA – Architecture.

True, there isn’t a single unified definition for SOA; however, just like the many definitions of software architecture, there are several characteristics that are more common and frequent than others.
Looking at definitions of SOA such as the ones from Wikipedia, O’reily’s, JavaWorld , Windley, Microsoft etc. you can see that

SOA is commonly thought of as an architecture or an architecture style that builds on loosely coupled, interoperable and composable components or software agents called services.

Services have well-defined interfaces based standard protocols (usually web-services but most definitions mention that it is not the only possible implementation) as well as QoS attributes (or policies) on how these interfaces can be used by Service Consumers.

The W3C defines Service-Oriented Architecture as “A set of components which can be invoked and whose interface descriptions can be discovered and published”

The goal of SOA is to increase the alignment between business and IT and
achieve business agility – the ability to respond to changes quickly and efficiency.

Service: The central pillar of SOA is the service. Merriam Webster defines service as “a facility supplying some public demand”.

Contract: The collection of all the messages supported by the Service is collectively known as the service’s contract.

End Point: The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.

 Message: The unit of communication in SOA is the message. Messages can come in different forms and shapes, for instance, http GET messages (part of the REST style) ,SOAP messages, JMS messages and even SMTP messages are all valid message forms.

The differentiator between a message and other forms of communication such as plain RPC, is that messages have both a header and a body. The header is usually more generic and can be understood by infrastructure and framework components without understanding, and consequently coupling to, every message type.

The existence of the header allows to handle security better.

 Policy: One important differentiator between Object Orientation or Component Orientation and SOA is the existence of policy. If an interface or contract in SOA lingo, separates specification from implementation. Policy separates dynamic specification from static/semantic specification. Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic. The Policy specify dynamic properties like security (encryption, authentication, Id etc.) , auditing, SLA etc.

Service-Oriented Architecture Principles:

Streams of information have been flowing from Microsoft in the forms of articles and white papers regarding its commitment to SOA, and in all of this information one of the big areas constantly stressed are the principles behind service orientation:

Explicit boundaries: Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the environment or development language of the other service.

Services communicate by sending messages across their boundary

All Communication occurs through messages

Autonomous services: This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.

You can change a service without affecting client as long as clients can continue sending and receiving the same messages.

Policy-based compatibility: Policies also allow you to move a service from one environment to another without changing the behavior of the service.

Services can define the circumstances under which clients can communicate with them.

Shared schemas and contracts: ” The contract contains information regarding the structure of the message. Services do not pass classes and types; they pass schemas and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on.

Contacts describe the messages services can send and receive.

Schemas define how the client and service construct the messages they exchange