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!

What are the 3 things that a WCF Services end point must have?

What are the 3 things that a WCF Services end point must have?

ABC are 3 things that WCFServices end point must have.

  • “A” stands for Address: Where is the service?
  • “B” stands for Binding: How do I talk to the service?
  • “C” stands for Contract: What can the service do for me
  • Address – Address specifies where is the service

    Binding – Binding specifies how to communicate with service

    Contract – Contract specifies what functionalities or operations are exposed by service

    WCF Proxy Creation ways

    WCF Proxy Creation ways

    There are different ways of creating WCF proxy :

    1. Adding service reference to a WCF service using Visual Studio

    2. Use SvcUtil.exe utility to create proxy

    3. Implementing ClientBase<T> Class

    Adding service reference to a WCF service using Visual Studio

    Right click on project in IDE , you will see three Add options as shown in the figure below :

    Click on Add Service Reference option , you’ll see the dialog box that is shown in Figure  :

    Once you’ve clicked OK in the dialog box, the add-in spawns SvcUtil.exe, generating the necessary proxy class and the required configuration file (or modifying it) and adding the necessary references to the project.

    This is the way to create sync WCF service proxy
    To create WCF service proxy in async way please follow below steps before clicking on OK :
    Click on Advanced Button

    Click on Generate Asynchronous operation checkbox and then click on OK button

    Using SVCUtil.exe
    To generate manually, choose the CMD window by selecting Start | All Programs | Microsoft Windows SDK | CMD.The output files SVCUtil generates are the client proxy source code file and the application configuration file.
    Command for producing both proxy class and configuration file
    svcutil /config:app.config /out:”CalculatorService.cs” /language:csharp /n:*,SimpleClientWithProxy.CalculatorService “http://localhost/MathService/?CalculatorService.svc&#8221;
    By default , svcutil generates only synchronous method signatures in proxy . 
    Use option /async to generate both synchronous and asynchronous method signatures in proxy
    Implementing ClientBase<T> Class
     Of all the methods , implementing ClientBase is best one because we need not create proxy class every time we make changes in service implementation.
    public partial class SampleServiceClient : System.ServiceModel.ClientBase<ISampleService>, ISampleService
        public SampleServiceClient()
        public SampleServiceClient(string endpointConfigurationName) :
        public SampleServiceClient(string endpointConfigurationName, string remoteAddress) :
                base(endpointConfigurationName, remoteAddress)
        public SampleServiceClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) :
                base(endpointConfigurationName, remoteAddress)
        public SampleServiceClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) :
                base(binding, remoteAddress)
        public string SampleMethod(string msg)
            return base.Channel.SampleMethod(msg);

    Serialization and Encoding in WCF

    Serialization and Encoding in WCF

    An important part of communication between WCF Applications is Serialization . Serialization and deserialization are processes involved in converting objects to stream of data and then retrieving objects .


    WCF provides new serialization engine called DataContractSerializer which performs serialization and deserialization .During serialization , DataContractSerializer converts data into XML Stream by using objects of XmlWriter class .During deserialization , DataContractSerializer reads XML Stream and retrieves data by using objects of XmlReader class.DataContractSerializer is the default and is always used unless specified otherwise.


    DataContractSerializer does not support sharing of CLR type information so WCF introduced NetDataContractSerializer to address this issue. NetDataContractSerializer includes CLR type information in the serialized XML


    WCF also supports the XmlSerializer class. The XmlSerializer class is not unique to WCF. The XmlSerializer class does not support data contract types.
    When using Svcutil.exe or the Add Service Reference feature in Visual Studio to generate client code for a third-party service, or to access a third-party schema, an appropriate serializer is automatically selected for you. If the schema is not compatible with the DataContractSerializer, the XmlSerializer is selected.

    When to manually Switching to the XmlSerializer

    1. When migrating an application from ASP.NET Web services to WCF, you may want to reuse existing, XmlSerializer-compatible types instead of creating new data contract types.

    2. Web Services Description Language (WSDL) document is not available, for example, when creating a service with types that have to comply to a certain standardized, published schema that is not compatible with the DataContractSerializer.

    3. When creating services that follow the legacy SOAP Encoding standard.

    public class EmployeeService
    public void AddEmployee(Employee emp)
    // Code not shown.


    //Employee is not a data contract class,
    //but is an XmlSerializer-compatible class instead.
    public class Employee
    public int employeeCode;
    public string employeeName;
    public string employeeSalary;
    public Manager manager;
    //Notice that the Manager class must also be XmlSerializer-compatible.

    WCF Contract Attributes

    Service Contract Attributes

    Service Contract Attributes are used to modify the service contract. Following are various Service Contract attributes that can be specified at service contract level :

    1. Name – controls the name of contract in the WSDL element.
    2. Namespace – controls the namespace of the contract in the WSDL element
    3. ConfigurationName – specifies the name of the service element in the configuration file to use.
    4. SessionMode – specifies whether the contract requires a binding that supports sessions.
    5. CallbackContract – specifies the return or call back contract in a two-way (duplex) conversation.
    6. HasProtectionLevel and ProtectionLevel – indicates whether all messages supporting the contract have a explicit ProtectionLevel value, and if so, what that level is.

    Operation Contract Attributes

    Operation Contract Attributes are used to modify the operation contract. Following are various Operation Contract attributes that can be specified at operation contract level :

    1. Action – specifies the action that uniquely identifies this operation. dispatches request messages to methods based on their action.
    2. AsyncPattern – indicates that the operation is implemented or can be called asynchronously using a Begin/End method pair.
    3. HasProtectionLevel – indicates whether the ProtectionLevel property has been explicitly set.
    4. IsOneWay – indicates that the operation only consists of a single input message. The operation has no associated output message.
    5. IsInitiating – specifies whether this operation can be the initial operation in a session.
    6. IsTerminating – specifies whether attempts to terminate the current session after the operation completes.
    7. ProtectionLevel – specifies the message-level security that an operation requires at run time.
    8. ReplyAction – specifies the action of the reply message for the operation.

    Data Contract Attribute

    Following are the Data Contracts attributes :
    Name – The default name of a data contract for a given type is the name of that type. To override the default, set the Name property of the DataContractAttribute to an alternative name.
    Namespace – By default, any given CLR namespace (in the format Clr.Namespace) is mapped to the namespace To override the data contract namespace for each type, set the Namespace property of the DataContractAttribute.

    WCF Transactions

    WCF Transactions

    Transactions consists of set of activities in which all activities succeeds or fails.
    Transactions follows ACID properties .

    1. Atomicity ( A ) – means all transactions are either committed or rolled back to previous state

    2. Consistency ( C ) – means changes made by transactions causes transformation from one state to other

    3. Isolation ( I ) – prevents one transaction to see uncommitted changes belonging to other concurrent transaction

    4. Durability ( D ) – means updates are persistent even in case of failure

    To add transaction support to a WCF service, you will take the following actions:

    1. Add transaction support to the service contract. This is required.

    2. Add transaction support to the code that implements the service contract. This is required.

    3. Configure transactions in the implementation code. This is optional.

    4. Enable transactions on the binding. This is required.

    Step 1

    Create a Service Contract with two Operation Contract

    We will create a service contract with two operations .

    Employee SaveEmployeeData(Employee empData);
    void SaveEmployeeSalary(Employee empData , EmployeeSalary empSalary );
    SaveEmployeeData to save Employee Details like ID , Name and Role.
    SaveEmployeeSalary to save Employee Details like ID and Salary.
    Step 2

    Add Transaction Support to the Operation Contract

    To add transaction support to operation contract , we have to use TransactionFlow attribute .
    The TransactionFlow attribute specifies whether the operation supports transactions. There are three possible values for this attribute:

    1. NotAllowed : The operation cannot participate in a transaction. This is the default value for this attribute.
    2. Allowed : The operation will participate in a transaction if the client creates one.
    3. Mandatory : In order to call this operation, the client must create a transaction.  

    When the operation has TransactionFlowOption.NotAllowed attribute , the client cannot propagate its transaction to the service. Even if transaction flow is enabled at the binding and the client has a transaction, transaction will not propagate to the service. TransactionFlowOption.NotAllowed is the default TransactionFlowOption value of the TransactionFlow attribute.

    TransactionFlowOption.Allowed means the client may or may not have a transaction to propagate to the service. Trying to call a service without a transaction does not throw an exception on the client. With Allowed flow, the client’s transaction always propagates to the service. Once again, the service may or may not use the client’s transaction.

    TransactionFlowOption.Mandatory means the client must have a transaction to propagate to the service. Trying to call a service without a transaction throws an exception on the client. With mandatory flow, the client’s transaction always propagates to the service. Once again, the service may or may not use the client’s transaction.
    Employee SaveEmployeeData(Employee empData);

    void SaveEmployeeSalary(Employee empData , EmployeeSalary empSalary );

    Step 3

    Add TransactionScopeRequired Attribute to the Implementation

    TransactionScopeRequired Attribute can be set to true or false. To enable transaction set  TransactionScopeRequired attribute to true.

    [OperationBehavior(TransactionScopeRequired = true)]
    public Employee SaveEmployeeData(Employee empData)
    SqlConnection objConnection = new SqlConnection(strConnection);
    SqlCommand objCommand = new SqlCommand(“INSERT INTO Employee values (‘” + empData.EmpID + “‘,'” + empData.EmpName + “‘,'” + empData.EmpRole + “‘)”, objConnection);
    return empData;

    [OperationBehavior(TransactionScopeRequired = true)]
    public void SaveEmployeeSalary(Employee empData , EmployeeSalary empSalary )
    SqlConnection objConnection = new SqlConnection(strConnection);
    SqlCommand objCommand = new SqlCommand(“INSERT INTO EmployeeSalary values (‘” + empData.EmpID + “‘,'” + empSalary.EmpSalary + “‘,'” + empSalary.EmpCurrency + “‘)”, objConnection);


    Step 4

    Enable Transaction Flow using WCF Service Configuration File

    We also need to enable transactions for wsHttpBinding by setting the transactionFlow attribute to true.

    <binding name=”TransactionalBind” transactionFlow=”true”/>

    The transaction enabled binding we need to attach with the end point through which our WCF service is exposed.

    <endpoint address=”” binding=”wsHttpBinding”
    bindingConfiguration=”TransactionalBind” contract=”WcfService1.IService1″>

    Step 5

    Call the two Operations in One Transaction

    Below is Client code to call these operations :
    using (TransactionScope ts = new TransactionScope(TransactionScopeOption.RequiresNew))
    ServiceReference1.Service1Client obj = new ServiceReference1.Service1Client();
    obj.SaveEmployeeSalary(empData , empSalary);
    catch (Exception ex)

    WCF Tutorial

    WCF – Windows Communication Foundation

    WCF – Windows Communication Foundation


    .NET Framework 3.0 introduces four important features :
    • Windows Communication Foundation ( WCF )
    • Windows Presentation Foundation ( WPF )
    • Windows Workflow Foundation ( WWF )
    • Windows Card Space

    WCF provides combined features of Web Services , Remoting , MSMQ and COM+ . It is used for building and deploying network distributed services.

    WCF provides few important features. So lets discuss few difference and features which make it better than Webservices

    Difference between Web Services and WCF

    1. Hosting

    Web Service can be hosted in IIS whereas WCF can be hosted in IIS , WAS and self hosting

    2. Programming

    Web Service Class requires [WebService] attribute whereas WCF requires [ServiceContract] attribute
    Web Service method requires [WebMethod] attribute whereas WCF methods requires [OperationContract] attribute

    3. Serialization

    Web Service uses System.Xml.Serialization for serialization whereas WCF uses System.Runtime.Serialization for serialization.

    4. Protocols

    Web Service supports Security protocol whereas WCF supports Security , Reliable Messaging and Transaction protocols

    5. Encoding

    Web Service uses XML 1.0 , MTOM , DIME and Custom encoding whereas WCF uses XML 1.0 , MTOM , Binary and Custom encoding.

    6. Transport

    Web Service uses HTTP and TCP as transport protocols whereas WCF uses HTTP, TCP, Named Pipe , MSMQ and P2P as transport protocols.

    WCF Endpoints

    WCF Endpoints 
    WCF Service can expose number of endpoints. Client communicates  with WCF Service using these endpoints. Endpoints consists of three parts :
    Address – Address specifies where is the service
    Binding – Binding specifies how to communicate with service
    Contract – Contract specifies what functionalities or operations are exposed by service
    Hence Endpoint is ABC ( A=Address , B=Binding, C=Contract )