I am using WCF in Wan.The basic activity of WCF is Database Synchronization.
Therefore the performance is critical.Currently I am using wsHttpBindings.
Is there any other optimized option which shall survive the Wan and Latency Options?
Related
Questions:
Why information on this subject are so poor?
Nobody uses WCF transaction services?
In this production environment is only allowed to use the ports 80 and 443, WCF tranaction technology uses other ports?
This technology is interoperable in any way? Client Java server .NET C#?
I am using WCF transaction to ensure complete communication between the client and the service. There is another way to ensure this without using WCF Transaction?
I appreciate any help and thanks
Why information on this subject are so poor?
Because no-one in their right minds wants to do transactional service calls over port 80 on the public web unless there is no other option (including suicide).
Nobody uses WCF transaction services?
See answer to the previous question.
In this production environment is only allowed to use the ports 80 and
443, WCF transaction technology uses other ports?
No, WCF transactions are an implementation of WS-Atomic Transaction, which uses port public ports. This was originally part of the SOAP 1.2 standard.
This technology is interoperable in any way? Client Java server .NET C#?
In theory yes because it's based on a standard which, as long as it's implemented correctly, should be interoperable with any other correct implementation. However, in practice, standards are almost impossible to implement uniformly and so I would seriously doubt that .net and java implementations would just work with each other (they're rarely able to interop over SOAP 1.1 even).
I am using WCF transaction to ensure complete communication between
the client and the service. There is another way to ensure this
without using WCF Transaction?
It depends on what you mean by complete communication. Complete meaning 100% ACID? That doesn't exist. What if the world blows up?
So 99.99% ACID? This level of completeness (1 failure per 10,000 calls) can be achieved without using any transactions at all. This is the normal operating range I would expect to see from a well-designed service-consumer interaction.
If you require a higher completeness rating you could have the service expose a recovery or rollback operation, so the consumer can take the appropriate action and rollback any calls made previously to a failed call. Such an approach is known as a compensation pattern.
Can someone help to what are the major diff between netTcpBinding v/s BasicHttpBinding ?
In my current project we convert BasicHttpBinding to netTcpBinding and get performance issue, it start timing out even thou the value in BizTalk is set to 1:00:00. We couldn't figure out why ?
netTcp and basicHttp bindings use entirely different transport mechanisms: TCP instead of HTTP. In theory, the binary encoding of TCP should be faster than the text encoding of HTTP.
As discussed here, netTcpBinding may not be as fast, because of additional security overhead and/or contention:
By default, NetTcpBinding enables certain levels of security add
overhead to the message processing pipeline of the WCF runtime.
Additionally, the NetTcpBinding also enables the port sharing feature
which means that your WCF host won’t have exclusive access to the port
and instead might share it with other applications. This might get
very interesting if you are hosting your service in a Windows Server
2008 or Windows 7 environment given that there are a number of Windows
applications that rely on NetTcpBinding endpoints. Finally, the
default values for theListenBacklog and MaxConnections settings are
set to 10 which is far from optimal for a large number of clients.
Also note that without more information on what part of communication is timing out, it's difficult to say the exact cause. Remember, each side of the transaction has different timeout settings for Open, Close, and Send or Receive.
After developing mini project with WCF duplex (Chat Service | Sms Service), I got a Point that maybe not be correct!!
I believed Duplex theory is good and useful but there is a lot problem about using Wcf Duplex. (like reliable session, Time-out exceptions, Client address-Management on server side, proxy management on Client Side)
am I think wrong ? am I miss something?
For more Information I Used wsDualHttpBinding not tcpBinding.
If you need bidirectional communication and you want to use WCF, duplex channels are the way to go. You just need to design your application correctly and correctly handle all problems you have described. If you feel that these problems are overhead and make things even worse you can always use network programming directly (sockets) or handle bidirectional communication by yourselves exposing separate service on server and another on client (where first call from client inform server about clients address) - this scenario will suffer from the same communication problems as WsDualHttpBinding.
WsDualHttpBinding itself is special kind of duplex communication. I personally don't like it because people very often misuse it. The problem is that this binding uses two separate connections - one from client to server and second from server to client. That is big difference to net.tcp where only connection initiated from client to server is used. Obviously using WsDualHttpBinding over internet (= you don't have control over client machines) becomes much more complicated because each client must configure its firewall (in computer, on home internet gateway, etc.) to allow connection on some port. Also if you want to run more then one instance of application on the same client machine, each instance must use its own port.
Just a technology update, now that .NET 4.0 is out.
I write an application that communicates to the server through what is basically a message bus (instead of method calls). This is based on the internal architecture of the application (which is multi threaded, passing the messages around).
There are a limited number of messages to go from the client to the server, quite a lot more from the server to the client. Most of those can be handled via a separate specialized mechanism, but at the end we talk of possibly 10-100 small messages per second going from the server to the client.
The client is supposed to operate under "internet conditions". THis means possibly home end users behind standard NAT devices (i.e. typical DSL routers) - a firewalled secure and thus "open" network can not be assumed.
I want to have as little latency and as little overhad for the communication as possible.
What is the technologally best way to handle the message bus callback? I Have no problem regularly calling to the server for message delivery if something needs to be sent...
...but what are my options to handle the messagtes from the server to the client?
WsDualHttp does work how? Especially under a NAT scenario?
Just as a note: polling is most likely out - the main problem here is that I would have a significant overhead OR a significant delay, both aren ot really wanted. Technically I would love some sort of streaming appraoch, where the server can write messags to a stream while he generates them and they get sent to the client as they come. Not esure this is doable with WCF, though (if not, I may acutally decide to handle the whole message part outside of WCF and just do control / login / setup / destruction via WCF).
For bidirectional communications, your best bet is NetTcpBinding, rather than the http bindings, if they're available.
This has the advantage of only requiring that the client can initiate a connection with the server.
I would go with Windows Azure Service Bus. See my answer in the following question:
WCF, 4.0, Bidirectional
Take a look at Windows AppFabric, good place to start is Here. It fundamentally wraps up WCF and WF into an application server, with WCF activation supported through WAS. Its where I would host this type of app. It offerd full duplex connection orientated, p2p or sessions between client and server. Don't confuse the Windows appfabric with Azure appfabric, (formely called Azure Service Bus).
As regards bindings above, both NetTcpBinding and WsDualHttp offer callbacks, but the ws binding you get a lot for your cash, especially if it's a mixed programming environment and you have to flatten the wsdl to make interop work. I also think that WsDual is easier on routers traversal, although I understand talking to friends, that Windows AppFabric mitigates this, with new Relay Services, (which i've not seen, and I think have now been renamed).
Hope that helps.
I am looking at using MSMQ as a solution to do asynchronous execution in my upcoming project. I want to know the differences between using WCF and frameworks like MassTransit or even hand written MSMQ client to place/read task off MSMQ.
Basically the application will be several websites (internal through LAN or external through the Internet) reading/writing data through a service layer (be it WCF or normal web service). Then this service layer will do one of two things: 1. write data to database 2. and/or trigger the background process by placing a message in the queue. 3. obviously it can also retrieve data from database. The little agent (a windows service) on the other side of the queue will monitor the queue and execute based on the task command.
This architecture will be quite easy to scale (add more queues and agents) and easy to implement compared to RPC or distributed execution or whatever. And the agent processing doesn’t need to be real time. And the agent and service layer are separate applications except they share the common domain objects and Repositories etc.
What do you think? Architecture suggestions for the above requirements are welcomed. Thank you!
WCF adds an abstraction over MSMQ. In fact, once you define compatible contracts (operations must be OneWay), you can switch out MSMQ in the config, transparently. (For instance, you could switch to normal HttpWS or a NetTcp binding.)
You should evaluate the other WCF benefits, like security and so on, to see how those fit in with your needs. Again, they should be reasonably transparent of the fact you're using MSMQ underneath. For instance, adding SOAP security and so on should "just work", independent of using MSMQ.
(Although, IIRC, you still need to login to the desktop on each machine that uses MSMQ, with the service account that will use MSMQ, to generate the certificate in the machines local profile. And then, it doesn't work very well from IIS6, since user profiles aren't loaded. A real pain in general, but nothing to do with WCF specifically.)
Apart from that:
Have you looked at SQL Server Service Broker? After using MSMQ + WCF and SSSB, I think that SSSB is vastly easier to configure and manage. SSSB works with T-SQL commands over any SQL client (I use it from Mono, on Linux, with transactions). It'll also give you transactional send/receive, even remotely (I think MSMQ 4 now allows this). It really takes a lot of the pain away from message queuing, and if you're using SQL Server already...
SSSB is often overlooked since the SQL Management Studio doesn't have GUI designers for it all, but it isn't hard and is a great option. The one downside is that if you want local send capability (i.e., queue message when network is down), you'll need to run a local SQL Express instance.
Your architecture seems sound and reasonable. However you should consider using the WCF net MSMQ transport over hand coded MSMQ classes. WCF wraps this common functionality into a nice programming model. Also I believe there is some improvements in the protocol used by wcf compared to basic System.Messaging
Have a look at the value-add over plain MSMQ:
http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html
In summary, you get a lot of messaging concepts clearly presented in the API with MassTransit; to an extent you wouldn't have if you hand-coded it or used WCF.