16. [ServiceContract]
public interface IComplexCalc
{
[OperationContract]
int Add(int a, int b);
[OperationContract]
ComplexNumber ComplexAdd(ComplexNumber a, ComplexNumber b);
}
[DataContract]
public class ComplexNumber
{
[DataMember]
public int Real { get; set; }
[DataMember]
public int Imaginary { get; set; }
}
17. public class ComplexCalc : IComplexCalc {
public int Add(int a, int b) {
return a + b;
}
public ComplexNumber ComplexAdd(ComplexNumber a,
ComplexNumber b)
{
return new ComplexNumber()
{
Real = a.Real + b.Real,
Imaginary = a.Imaginary + b.Imaginary
};
}
}
27. code configuration
ServiceHost myHost = new
ServiceHost(typeof(ComplexCalc)); -> Configuration
myHost.Open();
ServiceHost myHost = new
ServiceHost(typeof(ComplexCalc)); -> Code
myHost.AddServiceEndpoint(typeof(IComplexCalc),
new BasicHttpBinding(),
"http://localhost:8080/complex");
//The hosted service information is written in code
myHost.Open();
45. Service
Bus
Connectivity
Service Relay
Protocol Tunnel Eventing
Rich options for interconnecting apps across
network boundaries
Messaging
Queuing Pub/Sub
Reliable Transfer
Reliable, transaction-aware cloud messaging
infrastructure for business apps.
SOA è acronimo di Service Oriented Architecture ed un pattern , per creare architetture di servizi distribuiti che ci permettono di usufruire di una serie di vantaggi.
SOA ha cambiato il modo di realizzare Business Application , prima di SOA avevamo o semplici architetture client-server o addiriturra applicazioni monolitiche.
SOA sostanzialmente basa i propri pilastri sui i servizi e loro proprietà.
Services are autonomous. Services have explicit boundaries. Services can always be moved to some other location.
The side effect is that there can be no cross dependencies. No “spaghetti code”.
Clients can only be dependent on the contract.
The less dependencies you have, the more productive you are.
Services depend on data. There is no dependency on the technology that creates the data.
You can choose the right technology for you.
Using familiar technologies improves your productivity.
Service autonomy simplifies testing.
The service can be easily isolated from the system for testing.
SOA nasce in risposta a diversi esigenze, viviamo in mondo distribuito ma connesso, un mondo diverso composto da svariate technologie da integrare, da un business agile e aggressivo, dalla riduzione di costi e dalla complessità delle soluzione e del loro mantenimento ma anche di scalabilità , affidabilità e sicurezza.
This a distributed world. Connectivity is cheap, and it is available almost everywhere.
It is a world of diversity. There are many different technologies and frameworks.
What was considered impossible in terms of connectivity few years ago is trivial today. It is a common requirement to provide online information and to be in sync with globally distributed data.
You are having to build applications that are more complex, yet cost less.
Business today is agile. Companies are being sold and merged. New business relations and collaborations are being established every day. All this has an impact on the Information Technology industry. If two companies work together, their IT infrastructure must do the same.
Integration is a complex problem, especially when dealing with information systems.
The volume of data and operations that applications have to support is increasingly growing. Scalability issues are much more relevant today than they used to be only a few years ago.
SOA is an architectural style. Not everything must be designed as a service.
SOA was developed to deal with the challenges imposed by the world of high-scale distributed applications.
SOA has advantages, but like everything, comes with a price.
SOAP is the most popular standard in the web services arena, but other protocols can also be used.
SOAP is the container for data sent between the client and the service, in both directions.
A SOAP message is written into an envelope.
The body contains the data that is defined in the contract
Data is encoded into a SOAP message.
SOAP provides encoding for native types
RESTful services return XML data that is enc
REST is not a standard; it is an architectural style or approach.
The idea of REST is enabling simplicity and interoperability.
Instead of creating one more layer using one more protocol (i.e. SOAP) use an existing protocol (for example, HTTP).
Instead of defining a custom contract let us use HTTP verbs. REST claims that it is possible to express almost anything with the GET, PUT, POST, and DELETE verbs and relevant parameters.
Instead of using custom messages use URIs.
Because the contract is predefined and anyone can parse HTTP, REST is excellent for interoperability.
oded in one of several standardized encodings (for example, Atom-Pub, JSON, Plain Old XML (POX), Atom).
Many web-scale data applications use REST. For example, Windows® Azure™ Storage is based on REST.
.NET provides frameworks for building REST applications (for example, Microsoft ADO.NET Data Services and WCF).
WS-* standards are a group of specifications defining information transfer to and from Web services.
WS-* are XML-based. They define XML elements and attributes (with appropriate namespaces) to be placed inside messages (usually SOAP).
There is a lot of information Web services need to exchange to provide features like transactions, security, and reliable messaging. WS-* standards define where and how the information is to be transferred.
Interoperability depends on WS-*. SOAP and the WS-* standards were designed to support such interoperability
WCF was introduced in .NET framework 3.0. It is the framework for building service oriented applications.
WCF is a unified framework meaning that it supports all communication protocols and messaging patterns. WCF interoperate with older technologies like Microsoft ASP.NET Web Services.
WCF is based on SOA principles, which makes it interoperable by design.
WS-* standards provide exciting opportunities, but they are difficult to implement. WCF provides all the heavy lifting of the standards implementation, so you can easily write powerful services.
WCF supports both SOAP and REST. You have the freedom to chose which approach to use.
WCF provides a simple model of a distributed applications (i.e. the Service Model layer).
A service exposes endpoints. An endpoint is a combination of Address, Binding, and Contract (the ABC’s)
You can always extend the Message Model layer and get full control, which allows you to customize WCF’s behavior.
When writing a service, follow the following process:
Define a contract.
Implement the contract, and then create the service implementation.
Write the configuration (code or config file), and then host the service.
Test the service.
Create a client, and consume the service.
Before writing a service we must define what the service will expose. This is done by defining a contract. The contracts defines the shape of that data the service expects and the messaging pattern to use.
The contract is the only agreement between the client and the service.
A service contract describes the functionality exposed by the service.
A service contract defines the XML document the service expects for invoking each operation.
A service contract is written as a .NET interface decorated with the ServiceContract and OperationContract attributes.
Data contracts define the serialization of complex objects to be transferred.
Defining a Data Contract is simple. Just decorate a class with the DataContract and DataMember attributes.
WCF provides a powerful infrastructure that can convert a simple class into a service
The host is where the service implementation and WCF infrastructure are combined to expose a service.
An active service listens for requests.
By now we have a service implementation, but it is only a class that implement an interface. Something must bring it to life. This is the host..
For simplicity, WCF defines an abstraction for the listening ports called “endpoints”. Thus the host’s main responsibility is to create endpoints for the service. (The host has many other responsibilities.)
When a request arrives, the host sends it to an instance of the service to compute the response.
An endpoint is a combination of Address + Binding + Contract (ABC).
In WCF, messages are exchanged between endpoints. The SOA terminology defines the term “edge” for a service as its boundary. Endpoints are SOA edges.
A service must have some explicit edges. Clients can only access services though edges.
A service can have several endpoints, with different address and technologies.
It is easy to understand using the following real life example:
If you consider a bank as a service, the bank exposes a variety of operations.
We can consume those operations in several endpoints:
The branch office:
The address is the physical address of the branch.
The communication technology we use to communicate with the bank is our car.
The protocol we use is based on our language (English).
The contract is the set of operations we can consume in the branch. (Usually in the branch we can do anything that is allowed for a customer of our kind.)
Telephone:
The address is the telephone number of the bank.
The communication technology we use to communicate with the bank is Telephone (Public Switched Telephone Network (PSTN)).
The protocol we use is based on our language (English).
The contract is the set of operations we can consume in a telephone call. (Usually there are operation we are not allowed to consume when using the telephone.)
Internet
The address is the bank URL.
The communication technology we use to communicate with the bank is Transmission Control Protocol/Internet Protocol (TCP/IP).
The protocol we use is based on HTTP.
The contract is the set of operations we can consume through the Internet site. (Usually there are operations we are not allowed to consume when using the Internet.)
The above dictates that the same service should expose different endpoints.
The “Binding” concept is a key factor in achieving a simple design solution to a problem that was considered complex.
The binding describes all technology related with sending a message from A to B.
Question: What is a message pipeline?
Answer: The process a message go through (when being sent or received) that is built out of building blocks that accept and return a message. The building blocks can be arranged in arbitrary order.
A message passes through a pipeline when sent out of the client, when received at the server, and vice versa.
The message pipeline is described by the binding.
The basic pipeline building blocks are:
Transport: Physical communication between A and B (for example, HTTP, TCP, Microsoft Message Queuing (MSMQ)).
Encoding: Writing the message on the wire (for example, Binary, Text, Message Transmission Optimization Mechanism (MTOM)).
Other protocols, such as security and reliable messaging.
All the definitions and configurations describing the message pipeline are written in one place. This is why the binding simplifies the communication problem.
To move to the next binding element, the current binding element must be satisfied.
To do that protocol pipeline elements can create a negotiation with their matching pipeline element on the other side.
For example before sending a message the security building block must be satisfied.
To satisfy the security block, security messages are sent implementing a security protocol (for example, request for security token and request for security token response). Other messages can pass only after the security protocol is satisfied.
Question: Why do you need to be able to write your own custom binding elements?
Answer: If you want to check for something in each message that arrives to the service (for example a special header that contains a user's security token), then you will prefer to write a binding element and place it in the pipeline so it will be called automatically on every message that arrives. This prevents having to call the same code over and over in each and every operation of the service.
A binding is a combination of binding elements.
There are many predefined binding elements. You can also create new custom binding elements.
To create new binding elements, choose the binding elements and put them in the correct order.
The difference between existing bindings is simply the binding elements INSERT that they are composed from.
There is no need for the developer to define the binding and the composition of channels when programming a service host, because WCF supplies a collection of out of the box bindings which were defined for common scenarios.
There is usually no need to create a custom binding, but INSERT it is possible to do so by simply creating a new arrangement of existing binding elements (easy), or by creating a new binding element (defining a new channel) and putting it inside a new arrangement (more complex).
The number of predefined bindings is growing, as new ones are constantly being released.
Binding choices on the client and on the server must match.
To choose the correct binding for you, review your requirements (security, transaction, interoperability), and identify the most appropriate binding. For example: If there is an interoperability requirement (C# <-> J2EE) then binary encoding cannot be used (the binary encoding is Microsoft proprietary), thus netTcpBinding should not be used.
When a new technology is introduced into WCF, a new set of bindings is created. For example, Windows® Azure™ and the relay bindings.
You configure binding in code. (It is possible to create a complete WCF application without any XML configuration.)
Predefined bindings are exposed as .NET classes.
You configure binding by setting the properties on an instance of a binding object.
In this simple code snippet, the same configuration written in the XML configuration file on the last slide is repeated.
You can create a custom binding by simply creating a new arrangement of existing binding elements.
This XML configuration code snippet demonstrate how to create a custom binding called “MyBinding”, by rearranging existing binding elements.
The binding elements themselves expose a wider configuration capabilities than the binding objects.
Sometimes a particular property needs to be configured, but it is not exposed by the binding. The solution is to create a custom binding, and then configure the binding elements as required.
The binding elements can validate that they are arranged correctly. If the arrangement does not make sense, the validation process will throw an exception.
After having described all the endpoint components, you can now finally define an endpoint.
To define an endpoint, all you need is to set a combination of Address+Binding+Contract. This can be done in code, and in the configuration file as demonstrated above.
Every service can define multiple endpoints.
The name attribute in the service configuration is the name of the service implementation class.
To attach a binding configuration (like the one defined on the last slide), use the bindingConfiguration( attribute in the endpoint configuration element.
<endpoint address=“http://localhost:8080/complex”
binding="basicHttpBinding“ bindingConfiguration=“NoCookies”
contract="calculators.IComplexCalc"/>
The service can define a base address for each addressing scheme. (For example, HTTP or TCP)
The endpoint address is relative to the base address.
<service name=“Calculators.ComplexCalc“>
<host>
<baseAddresses> <add baseAddress="http://localhost:8080"/> </baseAddresses>
</host>
<endpoint address=“complex”
binding="basicHttpBinding“ bindingConfiguration=“NoCookies”
contract="calculators.IComplexCalc"/>
</service>
The client defines an endpoint at the client configuration that matches a service endpoint to which it sends it’s requests.
<client>
<endpoint name="ComplexCalcEP"
address="http://localhost:8080/complex”
binding=“basicHttpBinding" bindingConfiguration="NoCookies“
contract="calculators.IComplexCalc"/>
</client>
A host can be built on top of any Windows process. This means that a thick client (Console, WinForms, or Windows Presentation Foundation (WPF)) can host a WCF service.
Hosting will be discussed in detail in module 3.
The configuration for hosting a service is put under WCF configuration section : <system.serviceModel>
The base class for WCF hosts is ServiceHostBase.(bold?)
In reality, the class used to create a host is ServiceHost.(bold?)
Hosts created in code must be opened explicitly.
Commercial hosts (e.g. IIS, WAS, or AppFabric) are opened automatically.
This code snippet demonstrates a host that is created in code.
The first host uses the configuration file for all endpoints configuration.
The second host defines the endpoint in code.
One of the new features of WCF 4 is configuration defaults for default endpoints, which makes host creation even simpler.
In WCF 4, you can run the following code without a configuration file. A host will be created, and an endpoint will open.
ServiceHost myHost = new ServiceHost(typeof(ComplexCalc), new Uri("http://localhost:8080/Complex") ));
myHost.Open();
WCF will choose the binding automatically, and create the endpoint.
Sending a message from A to B is not all there is to be done. Something must process the message: serialize / deserialize it, create an instance of the service, and call the correct method.
There are several dispatchers that are responsible for the message processing before the service is invoked.
It is possible to intervene with the dispatchers’ processing using behaviors.
The mechanism to configure the dispatchers is called behaviors
There are many predefined behaviors that allow configuration of different aspects in the WCF framework.
Some of the behaviors can be set only in code, while some can be set in both code and configuration.
Some of the aspects configured by behaviors are developer oriented (for example, concurrency, instancing, and serialization).
Some of the aspects configured by behaviors are deployment oriented (X.509 stores, Throttling).
You can group several behaviors together.
You can define several behavior groups.
In this configuration snippet, a group called “limitCalls” is created.
Some of the aspects configured by behaviors are developer-oriented—for example, concurrency, instancing, and serialization.
Some of the aspects configured by behaviors are deployment-oriented—for example, X.509 stores, and throttling.
Deployment-oriented settings cannot be set in code.
The natural location for developer-oriented settings is inside the code.
Behaviors can be attached to a service declaratively by decorating the service implementation class with the behavior attribute.
Behaviors can be attached to a service imperatively using the following code:
var myHost = new ServiceHost(typeof(ComplexCalc));
var metadataBehavior = new ServiceMetadataBehavior( );
metadataBehavior.HttpGetEnabled = true;
myHost.Description.Behaviors.Add(metadataBehavior);
All things OData: http://odata.org, for CRUD Operation on RESTFUL Web Service
The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores
The Windows Azure Service Bus provides a hosted, secure, and widely available infrastructure for widespread communication, large-scale event distribution, naming, and service publishing. The Service Bus provides connectivity options for Windows Communication Foundation (WCF) and other service endpoints – including REST endpoints -- that would otherwise be difficult or impossible to reach
http://msdn.microsoft.com/en-us/library/windowsazure/ee732537.aspx
. Endpoints can be located behind network address translation (NAT) boundaries, or bound to frequently-changing, dynamically-assigned IP addresses, or both can be reached through this technology.
The Service Bus provides both “relayed” and “brokered” messaging capabilities. In the relayed messaging pattern, the relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging. Brokered messaging provides durable, asynchronous messaging components such as Queues, Topics, and Subscriptions, with features that support publish-subscribe and temporal decoupling: senders and receivers do not have to be online at the same time; the messaging infrastructure reliably stores messages until the receiving party is ready to receive them.
The base URI for all endpoints within my “pluralsight” service namespace is http://pluralsight.servicebus.windows.net/. If you browse to this base address, you’ll receive an Atom feed representing your Service Bus registry. They are “trees” because of the hierarchical nature of the namespace (names within name within names).
The way you project Service Bus names onto URI’s is as follows:
[scheme]://[service-namespace].servicebus.windows.net/[name1]/[name2]/...
The Service Bus supports three URI schemes: “sb”, “http”, and “https”. You’ll use “http” and “https” for all HTTP-based endpoints and the “sb” scheme for all other TCP-based endpoints. The service-namespace portion of the host name identifies a unique naming tree within the entire Service Bus namespace, which is completely controlled by the namespace owner.
For example, all names within my “pluralsight” namespace must start with either sb://pluralsight.servicebus.windows.net/ or http(s)://pluralsight.servicebus.windows.net/, depending on the protocol. Everything after the base URI is part of the user-defined namespace. I can create a very large number of names within my namespace through name hierarchies. For example, suppose we have an office in Boston, Salt Lake City, and Los Angeles, and each one needs to publish endpoints. We could assign each office a unique name and give the office control over defining names within its hierarchy:
sb://pluralsight.servicebus.windows.net/boston/
sb://pluralsight.servicebus.windows.net/saltlakecity/
sb://pluralsight.servicebus.windows.net/losangeles/
Then suppose each of the offices needs to expose an endpoint for a (location specific) training registration service. They could accomplish that by adding “training” to the end of their URI’s:
sb://pluralsight.servicebus.windows.net/boston/training
sb://pluralsight.servicebus.windows.net/saltlakecity/training
sb://pluralsight.servicebus.windows.net/losangeles/training
And if the Boston office, as the headquarters, needs to expose a payment processing service, it can simply create another endpoint name using “payment” within its namespace:
sb://pluralsight.servicebus.windows.net/boston/training/payment
These different service endpoints don’t have to be hosted on the same server, on the same network or even in the same geography. It’s the job of the Service Bus, and specifically the relay service, to determine where the endpoints are physically located at resolution time.
The Service Bus does not provide an API for directly interacting with the naming system. Instead, you access the naming system through the service registry functionality.
Service Bus Port Settings
http://msdn.microsoft.com/en-us/library/windowsazure/ee732535.aspx
One way one sender one receiver..
Service Bus provides a binding called netEventRelayBinding. This binding enables a publish/subscribe communication pattern over WCF, which is not available from any of the built-in WCF bindings. The netEventRelayBinding binding allows multiple applications to subscribe to messages sent to an endpoint. Any messages sent to that endpoint are received by all applications.
The Service Bus implements the netEventRelayBinding by allowing multiple listeners to register themselves at a URI specified by the first sender. Each service host that has an endpoint listening on that same URI implicitly becomes a subscriber. When a client sends a message to that URI, the message is delivered to all service endpoints currently subscribed. In this scenario, the back-end system plays the role of the WCF client and broadcasts (publishes) a message to all subscriber
