Service-Oriented Architecture (SOA)

Service-oriented architecture (SOA) is a flexible set of design principles used during the
phases of systems development and integration in computing. A system based on a SOA
will package functionality as a suite of interoperable services that can be used within
multiple separate systems from several business domains.

SOA also generally provides a way for consumers of services, such as web-based
applications, to be aware of available SOA-based services. For example, several disparate
departments within a company may develop and deploy SOA services in different
implementation languages; their respective clients will benefit from a well understood,
well defined interface to access them. XML is commonly used for interfacing with SOA
services, though this is not required.

SOA P RINCIPLES

 Standardized Service Contract – Services adhere to a communications agreement,

as defined collectively by one or more service-description documents.
 Service Loose Coupling – Services maintain a relationship that minimizes
dependencies and only requires that they maintain an awareness of each other.
 Service Abstraction – Beyond descriptions in the service contract, services hide
logic from the outside world.
 Service Reusability – Logic is divided into services with the intention of promoting
reuse.
 Service Autonomy – Services have control over the logic they encapsulate.
 Service Statelessness - Services minimize resource consumption by deferring the
management of state information when necessary
 Service Discoverability – Services are supplemented with communicative Meta
data by which they can be effectively discovered and interpreted.
 Service Composability – Services are effective composition participants,
regardless of the size and complexity of the composition.

Some authors also include the following principles:

 Service Optimization – All else equal, high-quality services are generally

preferable to low-quality ones.
 Service Relevance – Functionality is presented at a granularity recognized by the
user as a meaningful service.
 Service Encapsulation – Many services are consolidated for use under the SOA.
Often such services were not planned to be under SOA.
 Service Location Transparency – It refers the ability of a service consumer to
invoke a service regardless of its actual location in the network; this also
recognizes the discoverability property (one of the core principle of SOA) and that
the right of a consumer to access the service. Often, the idea of service
virtualization, where the consumer simply calls a logical service while a suitable
SOA-enabling runtime infrastructure component, commonly a service bus, maps
this logical service call to a physical service, also relates to location transparency.
 Windows communication foundation

WCF is programming model that enables developer to build service solutions that are
reliable and secure, and even transacted. It simplified development of connected
application

WCF A RCHITECTURE

At the heart of WCF is a layered architecture that supports a lot of the distributed
application development style.
WCF Contracts

Contracts in WCF provide interoperability they need to communicate with the client. It is through
contracts that client and service agrees as to the types of operation and structure they will use
during the period they are communicating back and forth.

WCF defines four types of contracts

1. Service Contract: Defines the methods of a service, i.e. what operations are available on the
endpoint to the client
2. Data Contract: Defines data types used by the available service methods, i.e. defines which
data types are passed to and from the service. WCF defines implicit contracts for build-in
types such as int and string, but we can easily define explicit opt-in data contracts for
custom types.
3. Message Contract: A message contract provides additional control over the data contract in
that it controls the SOAP message sent and received by the service. In other words, it lets us
customized type formatting of parameters in SOAP message.
4. Fault Contract: Defines which errors are raised by the service and how the service handles
and propagates errors to its client.

Service Runtime

The service runtime layer is the layer that specifies and managed the behaviours of the service that
occur during service operation or service runtime (thus “Service Runtime Behaviours”).

Following are the list of various behaviours managed by the service runtime layer

Throttling Behaviour: it determines number of processed messages

Error Behaviour: it specifies what action will be taken if any error occurs during service
runtime.
Metadata Behaviour: it determines whether or not metadata is exposed to the outside
world.
Instance Behaviour: it determines how many instance of the service will be available to
process messages.
Message Inception: it gives the service the ability to inspect all or parts of a message
Transaction Behaviour: it enables transacted operation. i.e. If a process fails during the
service runtime, it has the ability to rollback the truncation.
Dispatch Behaviour: when a message is processed by the WCF infrastructure, the Dispatch
service behaviour determines how the message is to be handled and processed.
Concurrency Behaviour: it determines how each service or each instance of the service
handles Threading. This behaviour helps control how many threads can access a given
instance of a service
Parameter filtering: when a message is act upon by the service, certain action can be taken
based on what is in the message herders. Parameter filtering filers the message headers and
execute persists action based on the filer of the message headers.
Messaging

The messaging layer defines what formats and data exchange patterns can be used during service
communication.
There are multiple aspects of communication with any given service and there are many
communication patterns. Messages can follow synchronous request-reply or asynchronous fired-
and-forgot pattern, messages can be bidirectional, and message can be delivered immediately or
queued. To simplify these choices and make them manageable WCF groups together sets of
communication aspects in Bindings.

WCF defines six frequently used bindings

Basic Binding:
offered by the BasicHttpBinding class, it designs to expose WCF service as a legacy ASMX
web service so that old client can work with new services.
TCP Binding:
offered by the NetTcpBindingclass, it uses TCP for cross machine communication in the
intranet. It support variety of features including reliability, transaction and security and is
optimized for WCF-to-WCF communication
IPC Binding:
offered by NetNamePipeBinding class, it uses name pipe as transport for same machine
communication. It’s most secure binding since it cannot accept calls from outside the
machine.
Web Service (WS) Binding:
Offered by WSHttpBinding class, the WS binding uses HTTP or HTTPS for transport and offer
a variety of features such as, reliability, transaction and security over the internet.
MSMQ Binding:
Offered by NetMsmqBinding class, it uses MSMQ for transport and offers supports for
disconnected queued calls.
WS dual Binding:
Offered by the WSDualHttpBinding class, this is similar WS Binding except it also supports
bidirectional duplex communication form the service to the client.

Formatters and Encoding

Each of the frequently used bindings uses a different transport schema and encoding as listed

Name Transport Encoding Interoperable

BasicHttpBinding HTTP/HTTPS Text, MTOM Yes
NetTcpBinding TCP Binary No
NetNamePipeBinding TCP Binary No
WSHttpBinding HTTP/HTTPS Text, MOTM Yes
NetMsmqBinding MSMQ Binary No
Activation and Hosting

The Activation and Hosting layer provides different options in which a service can be started as well
as can be hosted. Service can be hosted within the context of other application or they can be self-
hosted.
SERVICE CONTRACT IN WCF

Defines what operation service can perform

Usually an Interface
- avoid Classes (therefore a class can implement multiple contracts i.e. interfaces)

Declared by using ServiceContract attribute

[ServiceContract]
Public interface IService1
{

[OperationContract]
String GetData (int value);

// TODO: Add your service operations here

}

Operations declared using OperationContract attribute

SERVICECONTRACT ATTRIBUTE

 Classes/Interface
- independent of visibility
- opt-in Model

 Maps CLR interface to WCF contract

 Should define namespace ,by default the namespace will be tempuri.org

[ServiceContract(Namespace="MyServiceContract")]

 Name can be different to interface name

[ServiceContract(Name="IMyContract")]
Public interface IService1

OPERATIONCONTRACT ATTRIBUTE

 Methods only
- No properties/indexes/events
- Independent of visibility
- opt-in Model
 Default operation name is the method name
 Can provide different name all names have to be unique
[OperationContract (Name="GetStringData")]
String GetData (int value);

OPERATOR OVERLOADING
 Cannot overload operations in WCF
 Can manually enables overloading
- use Name property in OperationContract
- need to rework in Client Proxy