I am relatively new to WCF. I am developing Web application.
I am trying to understanding "Why WCF" and read many articles .
But in many places it has been mentioned "to developed service oriented architecture ,to asynchronously send data" without any detailed explanation / any basic example.
Can somebody please let me know one simple example in layman's term ,"Why WCF" so that I can appreciate its existence.
I have had conversations with many people but none of them were able to answer this basic question.
I am also aware that ,many hundreds of applications have gone live before WCF was there...
Suppose, you do have a task to make a procedure of recieving of the coordinate point (lat,lon) and and returning the picture of the surrounding area. Or to make a language translator from voise input to text output. These jobs could uses several servers with a lot of data and could makes some huge mathimatic calculations. But you procedure should me quick, platform independend, secured, protocol-independent, consumed by different technologies (Web, Mobile, Applications). And at the same time it should be easy to consume by the end users, which do know nothing about you. As the main aim of ASP to handle web requests and generate the html responses, so the aim of WCF is to supply the end user with some useful functionality, developed by another user, remotly.
The developer creates a service (WCF) where he specifies its adress, binding and contract. Knowing these parameters other developers can consume this service. They can consume it by ASP, SilverLight, WPF, WinForms or any other technology (even none-microsoft), using SOAP protocol.
From Wikipedia:
The Windows Communication Foundation (or WCF) is an application
programming interface (API) in the .NET Framework for building
connected, service-oriented applications.
WCF is meant for designing and deploying distributed applications
under service-oriented architecture (SOA) implementation. **
Architechture
** WCF is designed using service oriented architecture principles to support distributed computing where services have remote consumers.
Clients can consume multiple services; services can be consumed by
multiple clients. Services are loosely coupled to each other. Services
typically have a WSDL interface (Web Services Description Language)
that any WCF client can use to consume the service, regardless of
which platform the service is hosted on. WCF implements many advanced
Web services (WS) standards such as WS-Addressing,
WS-ReliableMessaging and WS-Security. With the release of .NET
Framework 4.0, WCF also provides RSS Syndication Services,
WS-Discovery, routing and better support for REST services. Endpoint A
WCF client connects to a WCF service via an Endpoint. Each service
exposes its contract via one or more endpoints. An endpoint has an
address (which is a URL specifying where the endpoint can be accessed)
and binding properties that specify how the data will be transferred.
http://en.wikipedia.org/wiki/Windows_Communication_Foundation
Useful resources:
http://msdn.microsoft.com/sv-se/library/dd943056%28en-us%29.aspx
http://www.wcftutorial.net/
http://blah.winsmarts.com/2008-4-Writing_the_WCF_Hello_World_App.aspx
http://blah.winsmarts.com/2008-4-Writing_your_first_WCF_client.aspx
Related
I create my API rest with Django, but I don't understand how convert an API to micro services, I don't understand the real difference between these.
I see an API like a micro service, but I don't know convert an entire API in micro service, I need create micro web servers?
Please, I can't understand a micro services, and I need understand this.
A microservice exposes it's interface, what it can do, by means of an API. The API is the list of all endpoints that a microservice respond when it receives a command/query. The microservice contains the API and other internal+hidden things that it uses to respond to client's requests.
An API is all that the clients see when they look at the microservice, although the microservice is bigger than that. A microservice hides its internal structure, it's technology stack, it's database type (sql, nosql - it could be anything); a microservice could move from sql to nosql, from python to php, but keep it's API unchanged.
API - It a way of exposing functionality over web. Imagine you have developed some functionality in .Net but not you are developing some software in a different language. Would you develop the same functionality again? No. So, just expose it via web service.Web services are not tied to any one operating system or programming language. For example, an application developed in Java can communicate with the one developed in C#, Android, etc., and vice versa.
Microservice - They are used to break a complex software into small pieces of individually deployable, testable, loosely coupled sub-modules. Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.
API Vs Microservice - Now that we have broken our complex software into loosely couple sub-modules. These sub-modules communicate with each other via an API. Therefore, Microservices and an API solve different problems but works together!
More Details:
The Difference between Web Services and Micro Services
RESTful API vs Microservice
a microservice is an autonomous RESTful service. It means, there is just one service on each server. In Spring Boot when you bootstrap your RESTful service, it will get an instance of tomcat(it's embedded tomcat) and run your service on it. So, if you have more than one service on a server, it is not a microservice, because these services are not autonomous.
What is the relationship between WCF and REST&SOAP? Is WCF based on one of those technologies (REST or SOAP) or it is a separate technology?
WCF is a messaging framework for building distributed systems. Distributed systems is mostly just another word for web services.
What this means is that you can write methods in C# (or any of the .NET languages) and then apply a bunch of configurations to the code that make your code accessible to others and turn your code into a web service.
Those "bunch of configurations" are WCF. WCF allows you to expose your methods to other computers or applications using REST if you set up the WCF configurations around your C# code to expose it as a RESTful service. Or, you can easily take the same C# methods and make them available via the SOAP protocol.
If you have a method called "GetData()", you can set up the WCF configuration to make that method available in a service that is hosted in IIS. When someone calls that service, they can send an HTTP GET request to http://www.yourdomain.com/SomeService/GetData, and the GetData method will receive the message and send back a response. When you make a GET request over HTTP, you're using the REST. REST is pretty much tied to HTTP as the transport protocol. REST also has no standard message format. Whatever you want to send in your HTTP message, and however you want to send it is OK. You can send XML, or JSON, or just plain text. You can use POST, or GET or PUT or any of the HTTP verbs as well.
With SOAP, your messages can be sent to the service using any transport protocol -- you aren't tied to HTTP. SOAP messages are designed to be transport neutral. They are encoded in XML and the XML always has a head and a body node inside of an envelope node. There are lots of web standards around SOAP -- standards for putting security, sessions and other features into the header of the message, for example. Also, with SOAP, you get a WSDL, which I won't go into explaining here, but it makes it a LOT easier for clients to program against. Most programming languages have a method of taking a WSDL and converting it into strongly-typed methods and objects so that your service is easy to call.
REST is very popular on the internet and is as scalable as the internet (i.e. VERY scalable). SOAP is very popular in business-to-business applications.
WCF isn't automatically REST or SOAP, but you can make it that way. What you need here is a tutorial:
WCF
http://www.codeproject.com/Articles/406096/A-beginners-tutorial-for-understanding-Windows
REST
http://rest.elkstein.org/
Here's some other interesting stuff:
WCF - REST / SOAP
https://msdn.microsoft.com/en-us/library/hh323708(v=vs.100).aspx
WCF and REST
https://msdn.microsoft.com/en-us/library/ee391967.aspx
Or you can do a google/bing/metacrawler/altavista search on your own.....
From MSDN
The WCF programming model provides various capabilities, such as SOAP
services, web HTTP services, data services, rich internet application
(RIA) services, and workflow services. SOAP services support
interoperability between systems that are built with Java, other
platforms, and those that use messaging standards that are supported
by Microsoft®. SOAP services also support transports such as HTTP,
TCP, named pipes, and MSMQ. Web HTTP services and data services both
support REST. Web HTTP services enable you to control the service
location, request and response, formats, and protocols. Data services
enable you to expose data models, and data-driven logic as services.
WCF also includes two programming models: The service model and the
channel model. The service model provides a framework for defining
data contracts, service contracts and service behaviors. The channel
model supports specifying formats, transports, and protocols.
Both SOAP and REST services can provide functionality to web
applications, and both can be used to exchange information in the
web's distributed environment. Each one has its own advantages, and
limitations.
Although, this question has got several good answers, just putting in my 2-cents, in an attempt for newbies to WCF vs SOAP vs REST-full services, to make it a bit easier for them to understand.
We get confusions, whether WCF supports both REST and SOAP ? And, normally, we just see generic definitions about SOAP and REST. So , we need something from Microsoft to make us feel the truth : ) So here's a screenshot from Microsoft MSDN :
So, yes, WCF supports both .
In context with OP:
SOAP services: in WCF programming model support interoperability between systems that are built with Java, other
platforms, and those that use messaging standards that are supported
by Microsoft®. These also support transports such as HTTP,
TCP, named pipes, and MSMQ.
Web HTTP services : in WCF programming model supports REST. [Source: MSDN]
What is service-oriented architecture?
SOA is way to develop service oriented applications and WCF is technology which can be used to develop service oriented applications. BUT SOA defines strict rules (known as SOA tenets) for applications. If you don't follow these rules you are building services but these services do not conform to SOA.
WCF allows you to develop plenty of types of services. You can develop interoperable SOAP services which conform to SOA or which doesn't. You can develop pure .NET services with non interoperable features and you can develop REST services.
Moreover in SOA service can have different meaning than in WCF. In WCF service is collection of functionality exposed on endpoints. In SOA the service can be whole application (set of WCF like services) - difference between small and big SOA.
SOA tenets are:
Boundaries are explicit - service doesn't share anything with other services (even database tables and data can't be shared)
Services are autonomous - each service is independent, can be separately deployed and versioned
Services share schema and contract, not class - services are described in WSDL, transported data are described in XSD, orchestrations (aggregation) are described in BPEL
Services compatibility is based upon policy - WSDL contains WS-Policies to describe configuration needed for interoperability
As you see especially first two tenets can be easily violated when building WCF service.
SOA is a way to design a complete solution, it is a set of commonly accepted practices for communication, state management, compatibility, etc. In software architecture specifically, SOA is a set of services (not necessarily Web Services) that are built independently to support a range of client applications. The modular design helps maintenance, business collaboration.
SOA also provides some guidelines for development:
Constraints over backward compatibility
Metadata exposure
Discoverability of services
On the other hand, WCF is just a supporting technology that helps you build the services in .NET.
You can create a SOA without WCF, just as creating a bunch of WCF services does not make your architecture a service oriented one.
Service Oriented Architecture is a software architectural concept where one or more services interact with each other. Here, service means unit of work to accomplish a purpose. For an example, selling online ticket for railways is a service, online hotel booking is a service, procuring online payment is a service etc. Now, let's consider a hotel company sells its rooms online from its own website. In this case the website is using a local service. The same hotel can also sell rooms through a third party travel portal. In the second case the third party travel portal is using a remote service or web service. Selling hotel bookings online through a travel portal is an example of a Service Oriented Architecture. In service oriented architecture two or more parties interact with each other using web services. Among them few are web service providers and few are web service consumers. A software component can be built by following Service Oriented Architecture by using web services.
WCF is a technology to build a service.
WCF is a technology which makes building services easier, and it works on all transports not only HTTP so it is more generic than Web Services which works only on Http.
SOA is just a method through which we can interact between different technologies like in .NET and JAVA using Web Services.
For this you have to be a knowledge in few things shown as follow.
XML
WSDL
UDDI
SOAP
after knowing these things you can easily apply this SOA
I am learning WCF,one of the benefits of WCF is that you can use WCF even the client and service are not in the same network.Can anyone explain why?
Why using normal asp.net services, .NET remoting or Windows enterprise service client and service have to be in the same network?
Another question is that does the client needs to have a service contract interface and data contract? I assume not ,but how the client understand the type returned from the WCF services?
Edit: Reflecting More comments
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
The books i used:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
http://www.amazon.com/Essential-Windows-Communication-Foundation-WCF/dp/0321440064/ref=pd_bxgy_b_img_c
http://www.amazon.com/Inside-Windows-Communication-Foundation-Developer/dp/0735623066/ref=sr_1_1?ie=UTF8&s=books&qid=1252111759&sr=1-1
Another question on SO with a set of resources is "WCF for the Totally Clueless"
I don't know where you read that a benefit of WCF is that it allows the client and server to be on different networks. They can already be on different networks using .NET Remoting or DCOM (Enterprise Services).
The client does need to know the service contract and any other contracts required in order to use the service. This can be provided through WSDL or the Metadata Exchange Protocol (mex). If using .NET on both sides, then it is possible to share the contract assemblies, but this introduces a coupling between client and service.
Previous Microsoft technologies were designed for some specific needs in particular environment. For example ASMX Web Services were designed to send and receive messages using SOAP over Http only. .NET Remoting specific to Microsoft environment, no interoperability. But WCF is designed to send and receive messages using any format (SOAP as default) over any transport protocol i.e. HTTP, TCP, NamedPipes, MSMQ etc.
And your second question "but how the client understand the type returned from the WCF services?"
Its through proxy, client interacts with proxy which contains all the types etc.
You can find a good concepts and questions here for understanding WCF core concepts.
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here