I am to design a webservice using WCF that yields methods that don't require a session (like static calls, eg: giving back some information about the webservice itsself) and other methods that require a session.
furthermore, the session based methods are using Workflows that are supposed to be able to be changed at runtime.
my current design would look like this:
there is a singleton service that runs in IIS that handles all the per call methods which also works as a host for the session based services. that way the singleton class knows about all the sessions and can halt the running workflows to exchange them.
is this a good/possible design choice?
is this a common scenario that uses a common design?
would be happy about any reading hints as the msdn help wasn't such a help to me.
thanks for your answers
-redoced
Using a singleton WCF service class is almost never a good idea - unless you really have just one single (physical) resource which you want to protect from concurrent access, it doesn't really make sense.
Because: either it's not multi-threading capable, but in this case, it becomes a huge bottleneck - requests are handled strictly sequentially - one after another. Not very good for performance.
Or then you need to make the whole service multi-threading aware - and let me tell you, making this properly, safely, and efficiently isn't for the faint of heart. It's really really hard to get this right, and make it perform well.
I really don't see any need for this, at all.
leave you "static" message calls (as you call them) be per-call services - those are easy to program, work well, perform well, never cause any multithreading issues
those few service calls (hopefully!) that do require a session - put them on their own service endpoint(s), make them per-session, use the "SessionId" in your session to identify them. It's a bit more work than per-call - but still nowhere near as complicated and error-prone as multi-threaded programming
Resources for WCF sessions:
MSDN article on Using Sessions in WCF
WCF Sessions blog post
Resources for WCF durable services (that persist their state between calls):
Blog post on "durable services"
WCF Durable Services
Orcas durable services
Screencast by Mike Taulty on durable WCF Services
Resources for WCF Workflow Services:
Foundataions: Workflow Services
Channel9 webcast: Intro to Workflow Services
Webcast: Intro to workflow services in WCF 4.0
Related
Simplified... We are using NServiceBus for updating our storage.
In our sagas we first read data from our storage and updates the data and puts it back again to storage.The NServicebus instance is selfhosted in a windows service. Calls to storage are separated in its own assembly ('assembly1').
Now we will also need synchronous read from our storage through WCF. In some cases there will be the same reads that were needed when updating in sagas.
I have my opinion quite clear but maybe I am wrong and therefore I am asking this question...
Should we set up a separate WCF service that is using a copy of 'assembly1'?
Or, should the WCF instance host nservicebus?
Or, is there even a better way to do it?
It is in a way two endpoints, WCF for the synchronous calls and the windows service that hosts nservicebus (which already exists) right now.
I see no reason to separate into two distinct endpoints in your question or comments. It sounds like you are describing a single logical service, and my default position would be to host each logical service in a single process. This is usually the simplest approach, as it makes deployment and troubleshooting easier.
Edit
Not sure if this is helpful, but my current client runs NSB in an IIS-hosted WCF endpoint. So commands are handled via NSB messages, while queries are still exposed via WCF. To date we have had no problems hosting the two together in a single process.
Generally speaking, a saga should only update its own state (the Data property) and send messages to other endpoints. It should not update other state or make RPC calls (like to WCF).
Before giving more specific recommendations, it would be best to understand more about the specific responsibilities of your saga and the data being updated by 'assembly1'.
I want to develop a simple Windows Forms application in C# using WPF and MVVM that will connect to an SQL server installed on a different machine. So I've read that, even for a simple structure like that, some developers would use WCF and make their application Service Oriented. I totally understand that SOA is the way to go with WebApps and SilverLight, but I don't see why, for a simple situation like a Winform and an SQL Server, would somebody use WCF. I would really appreciate if somebody could give me a couple of good reasons why to use WCF in my WinForm application (considering that the SQL Server will be in the same network with the clients)?
Thanks,
Aris
If you don't need it, don't use it :)
But you should consider whether there are plans to change the application - for example, to convert it to a web app or Silverlight. In that case, having a service which does the database access will make the conversion easier. Personally, I think this is usually over engineering, but it may make sense for your application if you foresee one such change in the near future.
Do you have to use WCF? Nope.
In my opinion, though, there aren't too many reasons NOT to create a WCF service for this sort of work.
Using WCF services for your different layers instead of class libraries is an excellent way to go. Using WCF, you can control how your components are hosted (IIS and http all the way down to in-process with named pipes) and where they're located.
WCF doesn't add much overhead and in return you get a bunch of benefits.
The point isn't necessarily to worry about SOA, but more to think ahead about flexibility and better reuse.
I can't think of a particularly compelling reason, other than habit. When you do something the same way for 99% of your projects, it's often just as easy to do it the same way for the other 1% if it doesn't go actively against your requirements.
The only other reason I can think of would be if you're writing something that could, potentially, be really useful externally or as a web-app. Using WCF in that instance would allow any client which could connect to the host (web browser, external application, or whatever) to connect to your library without you having to modify things after the fact.
If you know for (relatively) certain that this will only be a windows application run on the desktop of your own organizations' employees, I don't see a reason to use WCF in this instance.
Bottom line is that you're on a network so WCF or any web service makes sense.
Your network calls are all going to be async (or should be!). That's easy to do with WCF. Not so much with direct connections.
Even WinForm applications are connected these days.
I personally don't believe in creating services for everything, just to be creating services. Create a service when you know that you have a consumer for that service. Don't just say, "well, we might use it from another application some day", and call that an excuse for a service.
Services should be planned. The service contracts should be those which are required by their consumers. No consumers, no contracts, so no service.
I have a DAL that is replicated across multiple apps (I know its a bad design but ignore this for now) , what I want to do is this...
Create a WCF DAL Component that will be accessed via all Desktop apps.. Could anyone share their thoughts on following ??
I am intending to use TCP Binding
What will be the overhead in terms of performance ( since 1 DAL component will b consumed via multiple apps )???
Since TCP Binding can only be hosted on IIS-7.0, this will be another overhead in terms of hardware+s/w ( or is it possible to have HTTP binding at top and TCP beneath that so that I can use IIS version 5 or 6 )???
Can I have multiple end points for multiple apps and is good from performace point of view as it will help us creating different thread for different client apps and can have diff contracts in future as well so that one application goes unaffected due changes in the DAL..
What Instancing Mode is preferred in this case (we are expecting a traffic of 100 concurrent user per day) , and DAL already handles this using SINGLETON design pattern.
Let me know your thoughts on all of above mentioned points and also if you could provide me more insight on this... will b gr8.
Thanks in advance...
Let me answer a few:
1) netTcpBinding is a great binding - very fast, very good in performance - definitely go with that!
3) Either host in IIS 7.0, or then self-host - write a little Windows NT Service and handle the hosting yourself. Gives you more control, and the ability to manually start and stop your DAL Service. I wouldn't even bother trying to get NetTcp working on IIS5/6 with some kind of a trick/hack - waste of time.
4) Multiple endpoints of the same binding are neither useful, nor do they help with performance.
5) I would always use "Per-Call". Each service request gets its own instance of the service, the call is handled, and then you're done. That makes programming the WCF service implementation a snap - if you go singleton, to have any performance at all, you need to worry about multi-threaded and thread-safe programming - a mess, really. Don't do it. NO, just don't do it.
A DAL should always be stateless and should operate on the "open the database connection as late as possible, do the work, and close the connection as soon as possible" again pattern which is a perfect fit for the per-call instance mode. When your service request comes in, the connection is opened (those are pooled in a connection pool in ADO.NET anyway, on the server side), the works is done, and the connection is closed again.
I have a web tier that forwards calls onto an application tier. The web tier uses a shared, cached channel to do so. The application tier services in question are stateless and have concurrency enabled.
But they are not being called concurrently.
If I alter the web tier to create a new channel on every call, then I do get concurrent calls onto the application tier. But I want to avoid that cost since it is functionally unnecessary for my scenario. I have no session state, and nor do I need to re-authenticate the caller each time. I understand that the creation of the channel factory is far more expensive than than the creation of the channels, but it is still a cost I'd like to avoid if possible.
I found this article on MSDN that states:
While channels and clients created by
the channels are thread-safe, they
might not support writing more than
one message to the wire concurrently.
If you are sending large messages,
particularly if streaming, the send
operation might block waiting for
another send to complete.
Firstly, I'm not sending large messages (just a lot of small ones since I'm doing load testing) but am still seeing the blocking behavior. Secondly, this is rather open-ended and unhelpful documentation. It says they "might not" support writing more than one message but doesn't explain the scenarios under which they would support concurrent messages.
Can anyone shed some light on this?
Addendum: I am also considering creating a pool of channels that the web server uses to fulfill requests. But again, I see no reason why my existing approach should block and I'd rather avoid the complexity if possible.
After much ado, this all came down to the fact that I wasn't calling Open explicitly on the channel before using it. Apparently an implicit Open can preclude concurrency in some scenarios.
You can cache the WCF proxy, but still create a channel for each service call - this will ensure concurrency, is not very expensive in comparison to creating a channel from scratch, and re-authentication for each call will not be necessary. This is explained on Wenlong Dong's blog - "Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices" (a much better source of WCF information and guidance than MSDN).
Just for completeness: Here is a blog entry explaining the observed behavior of request serialization when not opening the channel explicitly:
http://blogs.msdn.com/b/wenlong/archive/2007/10/26/best-practice-always-open-wcf-client-proxy-explicitly-when-it-is-shared.aspx
I have found myself responsible for carrying on the development of a system which I did not originally design and can't ask the original designers why certain design decisions were taken, as they are no longer here. I am a junior developer on design issues so didn't really know what to ask when I started on the project which was my first SOA / WCF project.
The system has 7 WCF services, will grow to 9, each self-hosted in a seperate console app/windows service. All of them are single instance and single threaded. All services have the same OperationContract: they expose a Register() and Send() method. When client services want to connect to another service, they first call Register(), then if successful they do all the rest of their communication with Send(). We have a DataContract that has an enum MessageType and a Content propety which can contain other DataContract "payloads." What the service does with the message is determined by the enum MessageType...everything comes through the Send() method and then gets routed to a switch statement...I suspect this is unusual
Register() and Send() are actually OneWay and Async...ALL results from services are returned to client services by a WCF CallbackContract. I believe that the reson for using CallbackContracts is to facilitate the Publish-Subscribe model we are using. The problem is not all of our communication fits publish-subscribe and using CallbackContracts means we have to include source details in returned result messages so clients can work out what the returned results were originally for...again clients have a switch statements to work out what to do with messages arriving from services based on the MessageType (and other embedded details).
In terms of topology: the services form "nodes" in a graph. Each service has hardcoded a list of other services it must connect to when it starts, and wont allow client services to "Register" with it until is has made all of the connections it needs. As an example, we have a LoggingService and a DataAccessService. The DataAccessSevice is a client of the LoggingService and so the DataAccess service will attempt to Register with the LoggingService when it starts. Until it can successfully Register the DataAccess service will not allow any clients to Register with it. The result is that when the system is fired up as a whole the services start up in a cascadeing manner. I don't see this as an issue, but is this unusual?
To make matters more complex, one of the systems requirements is that services or "nodes" do not need to be directly registered with one another in order to send messages to one another, but can communicate via indirect links. For example, say we have 3 services A, B and C connected in a chain, A can send a message to C via B...using 2 hops.
I was actually tasked with this and wrote the routing system, it was fun, but the lead left before I could ask why it was really needed. As far as I can see, there is no reason why services cannot just connect direct to the other services they need. Whats more I had to write a reliability system on top of everything as the requirement was to have reliable messaging across nodes in the system, wheras with simple point-to-point links WCF reliabily does the job.
Prior to this project I had only worked on winforms desktop apps for 3 years, do didn't know any better. My suspicions are things are overcomplicated with this project: I guess to summarise, my questions are:
1) Is this idea of a graph topology with messages hopping over indirect links unusual? Why not just connect services directly to the services that they need to access (which in reality is what we do anyway...I dont think we have any messages hopping)?
2) Is exposing just 2 methods in the OperationContract and using the a MessageType enum to determine what the message is for/what to do with it unusual? Shouldnt a WCF service expose lots of methods with specific purposes instead and the client chooses what methods it wants to call?
3) Is doing all communication back to a client via CallbackContracts unusual. Surely sync or asyc request-response is simpler.
4) Is the idea of a service not allowing client services to connect to it (Register) until it has connected to all of its services (to which it is a client) a sound design? I think this is the only design aspect I agree with, I mean the DataAccessService should not accept clients until it has a connection with the logging service.
I have so many WCF questions, more will come in later threads. Thanks in advance.
Well, the whole things seems a bit odd, agreed.
All of them are single instance and
single threaded.
That's definitely going to come back and cause massive performance headaches - guaranteed. I don't understand why anyone would want to write a singleton WCF service to begin with (except for a few edge cases, where it does make sense), and if you do have a singleton WCF service, to get any decent performance, it must be multi-threaded (which is tricky programming, and is why I almost always advise against it).
All services have the same
OperationContract: they expose a
Register() and Send() method.
That's rather odd, too. So anyone calling will first .Register(), and then call .Send() with different parameters several times?? Funny design, really.... The SOA assumption is that you design your services to be the model of a set of functionality you want to expose to the outside world, e.g. your CustomerService might have methods like GetCustomerByID, GetAllCustomersByCountry, etc. methods - depending on what you need.
Having just a single Send() method with parameters which define what is being done seems a bit.... unusual and not very intuitive / clear.
Is this idea of a graph topology with
messages hopping over indirect links
unusual?
Not necessarily. It can make sense to expose just a single interface to the outside world, and then use some internal backend services to do the actual work. .NET 4 will actually introduce a RoutingService in WCF which makes these kind of scenarios easier. I don't think this is a big no-no.
Is doing all communication back to a
client via CallbackContracts unusual.
Yes, unusual, fragile, messy - if you can ever do without it - go for it. If you have mostly simple calls, like GetCustomerByID - make those a standard Request/Response call - the client requests something (by supplying a Customer ID) and gets back a Customer object as a return value. Much much simpler!
If you do have long-running service calls, that might take minutes or more to complete - then you might consider One-Way calls which just deposit a request into a queue, and that request gets handled later on. Typically, here, you can either deposit the answer into a response queue which the client then checks, or you can have two additional service methods which give you the status of a request (is it done yet?) and a second method to retrieve the result(s) of that request.
Hope that helps to get you started !
All services have the same OperationContract: they expose a Register() and Send() method.
Your design seems unusual at some parts specially exposing only two operations. I haven't worked with WCF, we use Java. But based on my understanding the whole purpose of Web Services is to expose Operations that your partners can utilise.
Having only two Operations looks like odd design to me. You generally expose your API using WSDL. In this case the WSDL would add nothing of value to the partners, unless you have lot of documentation. Generally the operation name should be self-explanatory. Right now your system cannot be used by partners without having internal knowledge.
Is doing all communication back to a client via CallbackContracts unusual. Surely sync or asyc request-response is simpler.
Agree with you. Async should only be used for long running processes. Async adds the overhead of correlation.