Service Oriented Architecture :
1. SOA via WCF – Part 1-
Details on : https://blogs.msdn.microsoft.com/bashmohandes/2007/08/11/soa-via-wcf-part-1/
(copied)
2. WCF and Service-Oriented Architectures :
REST, JSON and WCF Data Services
Both of these services offer contracts: a machine-readable description of the message formats and datatypes used by your service that developers can use to create clients. But all the services in your SOA don't have to provide a contract. If a single team is building both the service and the consumer, as is often the case in AJAX scenarios, a contract isn't necessary -- the team can work out their calling conventions by talking to each other.
In AJAX scenarios, for instance, you have no choice about your calling protocol: It's going to be HTTP, so there's no need for a contract that specifies that. Further, as Web applications move to the new paradigm where the browser is engaged in an ongoing conversation between JavaScript in the client and services on the server, reducing the overhead on each transmission is critical. REST and JSON provide lower-overhead ways to call services and move data around. REST can reduce the request message to just a URL. JSON replaces the flexibility of WSDL-based message formats with a set of industry-wide conventions that require a lot less infrastructure than an XML-based format.
The WCF short answer for building RESTful Web services (with or without a JSON response) is to use WCF Data Services. WCF Data Services establishes its own conventions for RESTful requests, while piggybacking on the Atom standard for defining response messages (adding some micro-formats for what Atom doesn't natively support).
I have some issues with WCF Data Services, primarily that it's very much an entity-based solution. By sending only discrete entities, WCF Data Services reflects an object-oriented (OO) approach that I'm not convinced is appropriate for the distributed nature of a SOA implementation.
Reference : https://visualstudiomagazine.com/Articles/2011/06/01/pcnet_WCF-and-SOA.aspx
3. Introduction to Service Oriented Architecture
Reference : http://www.c-sharpcorner.com/UploadFile/govind77/introduction-to-service-oriented-architecture/
4. Consuming a web service : A real time example
Refence : http://www.c-sharpcorner.com/UploadFile/18fc30/consuming-a-live-weather-forecast-web-service-in-Asp-Net-web/
5. Display daily Weather Forecast using Weather API in ASP.Net
Refence : http://www.aspsnippets.com/Articles/Display-daily-Weather-Forecast-using-Weather-API-in-ASPNet.aspx
Note : For Web API and ASP.net core go to this link :
http://www.c-sharpcorner.com/article/introduction-to-asp-net-core-web-api-and-repository-class-part-one/
1. SOA via WCF – Part 1-
Details on : https://blogs.msdn.microsoft.com/bashmohandes/2007/08/11/soa-via-wcf-part-1/
(copied)
2. WCF and Service-Oriented Architectures :
REST, JSON and WCF Data Services
Both of these services offer contracts: a machine-readable description of the message formats and datatypes used by your service that developers can use to create clients. But all the services in your SOA don't have to provide a contract. If a single team is building both the service and the consumer, as is often the case in AJAX scenarios, a contract isn't necessary -- the team can work out their calling conventions by talking to each other.
In AJAX scenarios, for instance, you have no choice about your calling protocol: It's going to be HTTP, so there's no need for a contract that specifies that. Further, as Web applications move to the new paradigm where the browser is engaged in an ongoing conversation between JavaScript in the client and services on the server, reducing the overhead on each transmission is critical. REST and JSON provide lower-overhead ways to call services and move data around. REST can reduce the request message to just a URL. JSON replaces the flexibility of WSDL-based message formats with a set of industry-wide conventions that require a lot less infrastructure than an XML-based format.
The WCF short answer for building RESTful Web services (with or without a JSON response) is to use WCF Data Services. WCF Data Services establishes its own conventions for RESTful requests, while piggybacking on the Atom standard for defining response messages (adding some micro-formats for what Atom doesn't natively support).
I have some issues with WCF Data Services, primarily that it's very much an entity-based solution. By sending only discrete entities, WCF Data Services reflects an object-oriented (OO) approach that I'm not convinced is appropriate for the distributed nature of a SOA implementation.
Reference : https://visualstudiomagazine.com/Articles/2011/06/01/pcnet_WCF-and-SOA.aspx
3. Introduction to Service Oriented Architecture
Reference : http://www.c-sharpcorner.com/UploadFile/govind77/introduction-to-service-oriented-architecture/
4. Consuming a web service : A real time example
Refence : http://www.c-sharpcorner.com/UploadFile/18fc30/consuming-a-live-weather-forecast-web-service-in-Asp-Net-web/
5. Display daily Weather Forecast using Weather API in ASP.Net
Refence : http://www.aspsnippets.com/Articles/Display-daily-Weather-Forecast-using-Weather-API-in-ASPNet.aspx
Note : For Web API and ASP.net core go to this link :
http://www.c-sharpcorner.com/article/introduction-to-asp-net-core-web-api-and-repository-class-part-one/
Comments
Post a Comment