I write my service with multiple binding.And I use 2 baseadress and I create 3 end points for tcp and 3 end points for http.How can I use all endpoints with service reference in client app?Is it enough to add base adress to service reference?
Assuming that you have only one service which exposes three contracts, then you would have to have for each contract an defined endpoint. In your case, because you are using two bindings basicHttp and tcp you will have three for each binding type. I don't see the point of referencing the endpoints for both bindings in your client application. Is this a API library or something? If that is the case I recommend you to use the channel factory in order to build your client proxies manually, svcutil.exe will cause you trouble in this scenario.
Related
i have seen people decorate their config file with multiple endpoints in WCF service. is there any reason. when one endpoint is ok then why two or more endpoints are require?
tell me small situation when multiple endpoints is required.
Scenario for multiple endpoints:
Service wants to expose more than one type of binding.
Service wants to expose more than one contract on the same binding.
Service wants to expose same binding and contract on different addresses.
http://debugmode.net/2010/05/25/multipleendpoint/
The goal I'm working toward is having a WCF routing service that can receive messages from clients, persist them to some type of data store, and then process/send them to their destination WCF services.
Things to consider:
You can create a routing service by using the ClientViaBehavior (outlined here and here)
The ClientViaBehavior will not work with basicHttpBinding, so I need to use wsHttpBinding (basicHttpBinding doesn't set the "To" header on the message, found out the hard way)
The WCF Message object itself is sent to the Routing Service, where it can be persisted as a serialized string
I don't want the Routing Service to know what's in the message - consequently, the service will not have a reference to the Data Contracts involved
When the time comes to route the Message to its destination, I need to be able to create a channel between the Routing Service and the Destination Service
It is not desirable for the Routing Service to be aware of each destination service - ideally, WCF could create the proper channel dynamically based on the content/headers of the message being processed.
Is this too much to ask of WCF? (I have a feeling it might be...)
Any advice on how to accomplish something like this would be appreciated.
If you're on .NET 4 (or can move to it), WCF 4.0 has introduced a RoutingService infrastructure of its own.
Check it out, before you re-invent the wheel!
See A Developer's Introduction to Windows Communication Foundation 4 for a great general intro to the new features (including RoutingService) in WCF 4
Yes, you can make your routing service accepts any message.
This link should help you: Building a WCF Router, Part 1
When I deploy the same service on different machines as they have different information that I need , how can I use my client gracely to consume these service .
You need to define the service endpoint you want to connect to in your client's config.
You cannot define a list of endpoints - if you need load-balancing features, you need to implement those on the server side and "hide" them behind a single service endpoint.
With .NET 4 and WCF 4, you have new capabilities you could check out:
WCF 4 has a new routing service which you can use to get called on a single URL, and you have control over how to "distribute" those calls to the actual back-end servers
WCF 4 also supports dynamic service discovery, so you could potentially just "yell out onto the network" and get back one service endpoint address that supports your contract you're interested in
Resources:
Developer's Introduction to WCF 4
10-4 Show on WCF 4 Routing Service
Content-based routing with WCF 4
WCF 4.0 Routing Service
WCF 4.0 Routing Service - Failover
Using WS-Discovery in WCF 4.0
Ad-hoc Discovery with Probing messages
It sounds like you want to connect to BOTH servers. you say they have different data that you need. Well, if you already know how to make a client to one of them, the easiest way is to define an entire other client to access the second one. You can define as many clients as you want in the config file. Then just call them both in code.
I have a callback service that is hosted over wsDualHttpBinding. I'm looking to add a client that will poll for the data rather than receive the callback (will be a mobile device using wince for demo purposes). I was curious what the best way to do this is? You cannot create a client proxy using NetCFSvcUtil with a service hosted with wsDualHttpBinding (I understand that), but you cannot host a callback service over basicHttpBinding. I really need the same service hosted over both basicaHttpBinding (clients will poll for data) and wsDualHttpBinding (callback will notify clients of data). Any ideas on the best way to handle this without creating two separate services to host the same data?
What do you mean by two separate services hosting the same data? Do you expect to share same service instance to handle both wsDualHttpBinding and basicHttpBinding requests?
Your current problem is that service interface for duplex communication cannot be used for basicHttpBinding. You have to create second service contract and implement it in the same service. In that case you can expose two endpoints for the service: one duplex with WSDualHttpBinding and one with BasicHttpBinding. Endpoints must have different relative addresses. From the perspective of the client those endpoints are separate services - each of them requires separate client proxy. So unless your service is singleton you will have new service instance for each client proxy. New service instance means no data sharing.
Thera are some possibilities to modify this behavior but it means replacing Instance provider.
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc