I am working on an asp.net application (.net 4 framework) design and was wanting to know what are the pros and cons and best practices for using webservices vs WCF techology? This application will eventually be used by outside clients to consume data.
When would you use WebServices and when would you use WCF?
Is one more scalable than the other?
I would use WCF because it can do everything webservices (asmx) does; while giving you the flexibility to extend much further.
You can setup a simple WCF Service just as easily as an ASMX service through Visual Studio. So if you're "Fresh" on both technologies, I'd spend time learning WCF.
Depending on your specific use-case, you might might also look into WCF Data Services (.NET4) and Entity Framework. It basically gives you a nice API that you can use to consume your database over http/https. The beauty of WCF Data Services, is that you end up writing very little code to get at your data, and you can focus on consuming it.
WCF Getting Started -- http://msdn.microsoft.com/en-us/library/ms734712.aspx
WCF Data Services -- http://msdn.microsoft.com/en-us/data/ee720180.aspx
Webservice?
Webservice use SOAP (Simple Object Access protocol) and it is used to
connect the web application using different type of technologies, and
possible to connect the application that have hosted in different type
of servers.
Disadvantage of Webservice
Webservice use only HTTP Protocol. It provides only singlex
communication, not half duplex and full duplex communication. They
work in an stateless fasion over HTTP and are hosted inside a web
server like IIS
Advantages of WCF Service
WCF Service support HTTP, TCP, IPC, and even Message Queues for
communication. We can consume Web Services using server side scripts
(ASP.NET), JavaScript Object Notations (JSON), and even REST
(Representational State Transfer). It can be configured to have
singlex, request-response, or even full duplex communication. These
can be hosted in many ways inside IIS, inside a Windows service, or
even self hosted.
Half duplex
Half-duplex data transmission means that data can be transmitted in
both directions on a signal carrier, but not at the same time.
half-duplex transmission implies a bidirectional line (one that can
carry data in both directions).
They work in an stateless fashion over HTTP and are hosted inside a web server like IIS
Full duplex
Full-duplex data transmission means that data can be transmitted in
both directions on a signal carrier at the same time. Full-duplex
transmission necessarily implies a bidirectional line (one that can
move data in both directions).
Related
I had a web service which has been using NServiceBus message handling between controller and domain logic. For a new functionality, I have to implement signalR webRT communication between clients and server. But there are some performance problems. I thought that, the problems occur from my design defect but I couldn't detect reason of the problem, yet.
Before SignalR integration, my web service was responsing in 20-30ms. But when a signalR client (only one client is enough) is connected to my web service, the responce time becomes to around 10000ms. When I remove NServiceBus implementation between my controller and domainlogic (directly operate my logic in controller and return) the responce time again down to reasonable value (around 20-30ms).
My web service is a .net core project. And I'm using long-pool threading mechanism for signalR.
I study SOA and webservices for a science paper. My state of knowledge is, that every SOA architcture needs a service broker.
Webservices are concrete implementations of a SOA, so do they have a service broker after? For example I create a webservice in asp.net which returns "hallo world" By Creating it, do I create a service broker too?
Don't let fool you by answers which are copy paste from Wikipedia :-)
Webservices are concrete implementations of a SOA
This assumption/statement is wrong. At least there is no direct relationship between SOA and webservices. SOA is an architectural paradigm where a webservice is a concrete technology (stack) based on WSDL and its result, the SOAP-protocol. Nothing more. Webservices may help to establish loosely coupled service landscape, which the SOA paradigm expects. But you could also build up a SOA landscape with other technology stacks (self-written hacks, RMI, even based on REST for instance).
Repository
The thing is: When you start building up your SOA-landscape, you (or others) will code services (i.e. webservices) where your service will have a technical contract (WSDL, WADL, ..) as a base for the implementation. Your clients will ask for it and you want it to store somewhere. This somewhere is usually a service repository. You could develop your own one, use the UDDI-standard or just buy one of products by the big vendors (IBM, TIBCO, Oracle etc).
Broker
A message broker within the SOA context is some piece of software, which supports the decoupling of the connected partner systems. Commonly it's called ESB (enterprise service bus). Also one of the goals of the SOA paradigm is, that the services can be used by anyone (reusability). Therefore you don't want to connect your services by P2P-connections (aka spaghetti architecture) - just imagine that one of the service participants changes it's hardware/IP: this would be a nightmare for all the connected partner systems. That's why the ESB was invented which acts between the service consumer and the service provider.
Typically, these ESB-products support a lot of technologies or -stacks/APIs like HTTP, JMS, REST etc.
Source: I work with a self-claimed SOA landscape and thousands of different (web-)services for a big company for a long time now.
A Web service is a set of related application functions that can be programmatically invoked over the Internet. Businesses can dynamically mix and match Web services to perform complex transactions with minimal programming. Web services allow buyers and sellers all over the world to discover each other, connect dynamically, and execute transactions in real time with minimal human interaction.
Web services are self-contained, self-describing modular applications that can be published, located, and invoked across the Web.
A network component in a Web Services architecture can play one or
more fundamental roles: service provider, service broker, and service
client.
Service brokers register and categorize published services and provide search services. For example, UDDI acts as a service broker for WSDL-described Web services.
ASP.NET webservices use HTTP protocol to send/receive messages.
But the messaging protocol is SOAP
and SOAP makes use of XML.
This is right?
It is right to some extent, but it is not the whole truth!
I don't think that ASP.NET imposes many constraints on what formats you use to send/receive messages when you implement web services. After all, you're still on top of the .NET framework which offers a really wide variety of options.
That being said, HTTP is the application layer protocol used for message transmission with web services. But other protocol might also be used.
SOAP is XML-based, and is a commonly used as format of exchange of structured information. But you can also have REST services (see http://spf13.com/post/soap-vs-rest) that do not use SOAP. You can even exchange plain text or XML or some private format - it depends on your case.
It really depends on your purpose and the client applications you expect will consume the service. Is this an in-house service where you should follow some obscure internal protocols/formats of communication, or is it a service that has to be accessible from the web and must offer as much compatibility as possible? If it is the latter, go in a standardized manner with SOAP or REST.
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
Both solve completely different problems:
An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
An RPC system provides client and server technologies for performing RPC operations.
I am building an ASP.NET website which will collect data from a user and submit it to a 3rd party webservice. The webservice is somewhat unreliable and for this reason there is a backup service.
If a call to the primary service fails (timeout or some other error) then I need to flip a bit in a static class which will trip the system to use the secondary service.
At this point, I need to start polling the primary service (with dummy data) to see if it is back up (at which point I will receive an OK code in return). At this point I need to flip the bit back so that the website starts using the primary service again.
I've had a read of this Should I use a Windows Service or an ASP.NET Background Thread? and I think that separating out the code into a Windows Service would be the cleanest method of performing the polling, but then how would I communicate with the web appication.
One thought I've had is to expose a webservice that the Windows Service could use to communicate into the webapp but this seems both messy and over-kill.
I'd appreciate your thoughts and experiences performing similar tasks.
Thanks
I think the Windows service is the way to go, definitely.
As for the communication between the service and your web site, the best answer depends on the size and scale of your solution. If you are building something that needs to be reliable, I'd suggest you implement some sort of queue between your ASP.NET site and your Windows service. You have a lot of options here too, depending on budget and ability: BizTalk, MSMQ, and SQL Server queues (SSIS). Alternatively if you are looking for something smaller scale, I'd recommend you just stick it into a database table somewhere.
I would avoid using files on the file system because you will encounter issues with file locks and multithreading. I would also avoid directly communicating with the service because you risk losing the in-memory queue if the service fails for any reason.
Edited to add:
If reliability isn't a concern here, you could use a WPF named-pipes hosted service for communication between your website and your Windows service. This avoids much of the overheads normally involved in classic Web Services and is surprisingly quick. The only down-side is that self-hosting a WPF service is tricky and can be difficult to keep the service up.