WAS Features
Application Pooling
Recycling
Idle time management
Identity Management
Isolation
Sounds a lot like COM+ but hosted in IIS 7. Anybody out there using this technology and am I correct comparing the two?
As I understand, that's Microsoft's attempt to allow people use other than HTTP bindings and not bother with self-hosting. .NET and it's set of functionality, Remoting in the early versions of Framework and WCF nowadays are replacement for COM/COM+. WAS is just another solution to host WCF services hassle free with extra functionality.
I don't think that WAS offers the sort of distributed transaction management that COM+ and its predecessor, MTS, offered. So WAS is not really a replacement for COM+, though it does offer some of the same features.
Related
i'm about to decide on technology choices for an agent based application used in the transportaion systems domain.
basically there will be a central system hosting the backend, and multiple agents located across town (installed on desktops) that communicate with devices/kiosks collecting data and then transmitting them back to the central server. the central server could also be hosted on the cloud.
following are important
securing the data and communications between the device and the agent
and the agent and central server.
agents should be easily installable with little or no configuration.
near 100% uptime and availability
Does WCF fit the bill here?
if so what binding types should i go for? netTCP or wsHttp with SSL/HTTPS?
WCF is definitely a fit choice for this kind of scenario. For your bindings, the actual question is what technology you are going to use. Do you want to make the agents run in a non .NET environment like Java, then you should chose for wsHttpBinding. This binding communicates through SOAP and is very interoperable.
If you chose to use .NET agents, you might as well use netTcpBinding because they use the same WCF frameworks. It also supports binary encoding. If you really need to make a choice, take a look at the MSDN Documentation.
For your agents you could use a simple console application that runs in the background as a Windows service. WIX can help you with that (install an application as windows service), but thats all I know. WIX can also help you with basic installing and configure everything for you but it has a high learning curve so you might need to invest time in it.
I've been working with WCF fairly extensively for over two years now and have almost always taken the "lazy" route and deployed everything through IIS. Some of the reading I've done lately is starting to trend to where developers are using custom hosts in windows services or as console applications. Is there major benefits to switching over to that paradigm or is my current strategy of hosting everything in IIS give me everything I need to do WCF services?
When you go the self-hosting route, you limit the scalability & reliability options of your services. If scalability isn't a concern, you still need to consider all the service monitoring functionality that you'd have to create to be sure your services are running reliably.
If I had to pick two reasons to prefer IIS hosting over self-hosting they would be the flexibility of the WAS service instantiation model for IIS 7.x and the Windows Server AppFabric features for WCF 4.
If you're using a pre-WAS version of IIS (5 or 6), Windows services may be your best (only?) good bet for hosting WCF services that communicate via named pipes or netTCP (anything other than HTTP).
In the 3rd Edition of Programming WCF Services (link), Lowy suggests using Windows Server AppFabric in some situations, and suggests self hosting in a few cases - when you need to use the service bus and IIS 7.5 is not available, for example. Pages 22 and 23 show a couple of simple charts to help determine when to use self hosting over IIS, WAS or AppFabric. I think the first chapter (maybe more) is available for free if you get a Kindle sample.
Other than these scenarios, I'm not sure why you'd ever want to chose any sort of self-hosting over WAS. I'm curious to see if anyone presents good reasons.
we are currently on windows server 2008 R2, IIS 7.5 and we are going to open some of our data via WCF services.
To do that, we are planing to host our services on IIS but I heard that it is not a good idea for WCF services.
The problem with the WAS is that it is general purpose hosting engine. it's actually unaware that it's actually hosting a WCF service or a website (as far as I know)
I heard that we can install an extension to the WAS called the Windows Server AppFabric.
does anybody have any experience on
AppFabric?
should my app have to use so called
'Service Bus' to use AppFabric?
should I go ahead and definitely
install it?
at most basic level, how and where
can I install it? does it require
any licence?
Thanks in advance.
I don't think IIS us a bad idea - many developers use IIS to host their WCF services. IMHO you'd only use what you need, so if all you need is a hosting framework, then IIS is a very good option for WCF services. It is (almost) unaware that it's hosting a WCF service, but that in the majority of the cases isn't an issue.
Windows Server AppFabric as it's currently released provides three capabilities: a distributed caching system (so if you need to scale out your service you can use this cache to share state among the nodes); a packaging / deployment interface (in which you can package a project and deploy it a little easier in IIS); and a management / monitoring interface (where you can monitor the instances of WCF and Workflow services which are running in your machine).
Answers to your questions:
Yes, some people have experience with it :)
No, the application doesn't have to use it. You'd only use the ServiceBus if you need its functionality (relay)
Only if you need it. If you don't need caching or the monitoring capabilities, for example, then I'd say you don't need it. I've found in the past that the least number of components I have in my system, the less likely it is to break.
Go to http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx. And AFAIK you don't need any license, but you can check on the download page to see if it has more information.
There is no real common reason why not to host a service in IIS/WAS.
If you want to absolutely, totally 100% make sure that your service is continuously running some process, such as a continuous loop or polling monitor, and if any interruption no matter how brief is a major issue, then you'd want to look at alternative hosts.
Win Server AppFabric is most useful for WF Service hosting and caching. Note however that Win Server AppFabric + Win Server Service Bus 1.0 represents the first steps in convergence between the Azure platform and the Windows Server private platform.... In other words, whichever of the two ways you choose, that's what is going to be earning your bread and butter in 5 years time.
i'm going to build a instant messager
and now i have to decide how i implement the networking.
So far i only worked with Sockets (TCP or UDP). Now i heared about RMI (in Java) and want this in my C#-Chatapplication too.
There is .NET Remoting and WCF. I think building the instant messager with Sockets is not a good idea, right? But that should i use? .NET Remoting or WCF?
.NET Remoting seems to be the older technologie and is similar to Java RMI. I read that .NET Remoting is faster than WCT (article from 2007).
Which technologie should i use for my instant messager? I want to send formatted text from the richtextbox and inline images.
Furthermore i want to exchange files from chat-client to chat-client.
For .NET Remoting i found a tutorial which uses
ChannelServices.RegisterChannel(myChan);
But this is marked as obsolete. Is .NET Remoting a obsolete technologie?
Is it possible to send images and files with WCF or .NET Remoting or are Sockets the better choice?
I read that WCF is a collection of networking technologies (Web Services, Remoting, ...) but if i search for WCF and remote method invocation i only get examples for Web Services...
BTW: Later, i want to implement a Web-Client for my instant messager with ASP.NET. Are there some limitations respective to Networking (WCF/Remoting)?
Thank you :)
.NET Remoting is maintained for backward compatibility only as of .NET 3.0. Thus, if you are going to be using .NET 3.0 or greater, use WCF.
For your immediate use, I would suggest the NetTcpBinding. You can then select a more appropriate binding using the following chart.
.
Finally, to learn about WCF, refer to this SO question.
For your instant messager solution I would recommend WCF P2P here is an article to get you started Peer-to-Peer Programming with WCF and here it is an example of p2p on codeproject.
I need a way to exchange data between a process and a windows service.
The process (Windows Form Application, Console Application, in the future also a Web Solution) needs to instruct and interact with the windows service.
I want to know which way is the best to accompplish this.
I'll write the solution in C#, .NET Framework version does not matter.
In the past I've used Remoting (Activator), WCF Interface with Contracts, Inter Process Exchange IPC and some named pipe implementation. What is your experience? Other ways?
I would choose WCF. It is most modern and probably best supported approach at the moment. It "replaced" older technologies in most scenarios. Nice feature of the WCF is that if you need to move your service to other protocol you can do that simply in configuration.
If you expect that windows service will always run on the same machine as other application you can use WCF with netNamedBinding. If you decide to move your service to other machine you will have to change configuration (probably to netTcpBinding) because Named pipes in WCF are limited only to IPC.
My previous experiences have always been over an IPCChannel, mainly because the only code I've had to be involved in that does any form of inter-process communication. It's never caused me any problems and the code is working away quite merrily as I type.
The only real answer to this question is, whichever you're most comfortable with.