we had developed a webservice in vb.net,framework 2.0. We would need to rewrite this
websevice in WCF with framework 3.5. Please provide some guidance regarding this and also
there are many othersystems consuming our webservice url. Will this conversion have impact on the source system or does it involve any build activity for the source system to consume the url that will be developed with WCF method?
Please provide sample example to have better understanding on this. Thanks!
A few thoughts.
Case 1: Your webservice is having consumers and you want to rewrite only the service and not disturb the consumers.
In this case using a basicHttpBinding end point with regular wcf service implementation would do. You can find many references to build WCF service with basicHttpBinding. Most probably this would fit your need.
Follwoing links may be helpful to you.
http://msdn.microsoft.com/en-us/library/aa480190.aspx
http://msdn.microsoft.com/en-us/library/ms731361(v=VS.90).aspx
Case 2: If You want to rewrite the service, and it is acceptable to have changes in the consumers, then it is worthy to consider the following points.
Endpoint Choice
a. If your preference is to keep your service interoperable (i.e. you would like the service to serve different platforms), Soap based endpoints would help. basicHTTPBinding, wsHTTPBinding, etc.
b. If your consumers are in the windows platform, and you prefer better performance than SOAP based bindings, netTCPBinding based endpoints would help.
c. If your consumers are in the same machine, netNamedPipe can would be a choice.
Service Design
The service design offers you to go with a lot of combination of the following.
a. Choice of deciding the service instance's life cycle.
b. Choice of Concurrency.
c. Choice of Sessions, and enforcing the order in which the service has to be called (prefered by specific designers)
d. Choice of having or not having the transactions.
You shouldn't need to change anything. It should work the same.
Have you tried migrating it yet? If so, what were the problems? If not, just switch it to 3.5 and see what happens.
The Only need is to change the service endpoints in WCF service making as
http://localhost/YourProjectName/Servicename.svc ,
Without changing the Server Side coding , You
need to expose the Remote Interfaces making them as [Service Contract] and the Methods as [Data Contract] on the client Side
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 have to write an online chess program using WCF. I'm new to service programming, so could you please give me some advice.
I thought of using duplex communication, so that the service could poll the database and call the client, if the opponent has made a new step. but I don't think this would be a quite optimal solution. Could you please tell me what better alternatives can be here?
Thanks a lot.
Depends on the type of clients that will use the service. If for example the clients are .NET clients you could use wcf Net.Tcp communication and set up a callback contract that the clients need to implement and the service can call when someone makes a move. If you use other type of clients polling is probably the best way to go.
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.
Is it possible to create a WCF service (web service) that only accepts a single connection at any one time with all other calls either queued or rejected.
Need to implement the competitive consumer pattern where there are a number of clients which could deal with task at hand but when a client askes for more work a task must go to only one of them. Usual done as part of an enterprise service bus but can not find one that I'm happy to start using so looking to get this behaviour through a WCF service.
Any ideas people ?
Absolutely. You can set the ServiceThrottlingBehavior's maxConcurrentCalls to 1.
Have you looked at the distributor in NServiceBus? It does pretty much what you described.
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.