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.
Related
Am creating a WCF service which will be hosted in IIS 7. Can I expose webHttpBinding for Json communication and also netNamedPipeBinding for internal to the system
No, It's not allowed to have two types of protocol on single WCF service in one hosting process on IIS. The reason is that for WebHttpBinding you would need to use AspnetcompatibilityMode which allows WCF to be hosted side by side in Asp.net app domain and allows functionalities like Routing, access to HttpContext.Current.
Other binding types won't be supported with other types of biding if you have Aspnetcompatiblitymode enabled. For more details read the MSDN documentation here.
My understanding on routing service in WCF is this -
The actual services resides in your private network which is not accessible to the world. You then have a routing service as an intermediary which internally (based on inspecting the request) calls the services in protected environment. This routing service is accessible to client and client uses this routing service to communicate with actual services.
Hence, how will the client know about the service contract exposed by the back-end service (as explained in most of the articles on routing)? If from WSDL, then client will anyway know about base address of back-end service and directly call the service instead of routing service. How can we enforce this constraint on client side?
Thought?
Thanks!
Normally, in said cases, you will expose the service contract through other means, such as a statically published WSDL. This is going to be more prevalent in scenarios in which you are using mechanisms such as protocol transitions, as the original, dynamically-generated metadata is going to be wrong anyhow.
For simpler scenarios (in which all you want to do is avoiding exposing your server directly to the network), a reverse proxy might be a preferable alternative in some cases if you're using HTTP.
I have a WCF service running inside Windows Service and it is located on my local network. What I want is to be able to discover WCF from my Silverlight app on my WP7 (on the same network).
I know there a Discovery feature in WCF, however it requires to UDP, which is not supported on WP7. So are there any other ways to discover local WCF?
I also do not know prior to launching WCF the IP address of the WCF service.
The solution I came up with, is to use Sockets as on WP7 they support multicast.
So set up would like this:
Desktop service - Windows Service hosting WCF and small Socket app
which listens on specific port.
WP7 client - before connecting to WCF
a broadcast would be sent using Sockets to find out an IP address of
the machine which runs WCF, when got a response connect to WCF.
For a WCF Service to be referenced in a WP7 project the WCF Service MUST be a BasicEndpoint
You could provide a basic endpoint that exposes a kind of catalog service. It doesn't have to implement UDDI but it could be a custom protocol to suit your needs and return addresses of web services.
This way you only need to know a single address. Of course you can cache returned addresses and query the catalog service only when you are not able to connect.
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.
We have a solution where we are picking the messages using Windows Service.
The Windows Service fires every after 2 minutes and retrieves the MSMQ message to pass it to a Web Service.
Can I create a WCF service which will automatically picks up the messages from MSMQ Queue?
Can I avoid Windows Service by using WCF Service if it support auto invocation?
Q1: you can automatically pick up messages from MSMQ, you will need to look into the netmsmqbinding, there are some design considerations that you have to think about though, if you are used to the native MSMQ, you know that you have the ability to peek at the messages. But when you use WCF, you loose that ability to peek. WCF will intercept the messages in MSMQ and you are responsible for keeping your WCF service and the peeking app in synch.
You will also need to look into whether you need transactional or non-transactional queues and you will have to modify your binding based on that.
Q2: You will need to host the WCF service in windows service or in IIS7. if you host in IIS7 look into enabling MSMQ WAS listener
Here is a nice article:
http://blogs.msdn.com/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx
One way to transfer messages from an MSMQ to a web service call is to use a netMsmqBinding service endpoint and a basicHttpBinding client endpoint that support the same contract. The netMsmq service will automatically grab messages from the queue and deserialize them into an object. In your implementation of your netMsmq service, just instantiate your basicHttp client proxy and just call the same method. Basically a pass-through or proxy pattern from the web-service to the MSMQ and vice-versa. In Juval Lowy's "Programming WCF" he calls this pattern the "HTTP Bridge" for queues.