I'm building a WCF router which needs to act as a proxy for a number of internal web services (WCF and ASMX). The routing part is fairly straight-forward, but I can't understand how the service metadata exchange would work in this solution.
In other words: how would a client obtain metadata for an internal service behind the router? Do I need to manually supply WSDL files to the consumer? Can I somehow setup the router to return the metadata for an appropriate internal service?
Or perhaps my architecture is completely wrong?
I see 2 options here:
It may be an option to create a "non-transparent" proxy, if you don't want to expose the internal addresses. The advantage is that you can do more than just routing messages (i.e. such proxy may serve as a "security boundary", unwrapping ciphered messages and passing them plain to the internal endpoint). It can also provide an "interoperable level", exposing a WCF service as simple SOAP using same datatypes/message XML structure. The downside is that you'll have to update its code along with the proxied services
You may implement a WSDL rewriter. With it, you can mask the internal service URL on-the-fly - depending on your conditions, a simple string replace may or may not suffice.
Refer to:
Message Inspectors
IWsdlExportExtension
The same "router service" can also be used to get the individual WSDL for internal services behind the router.
Check out this thread
Have you considered using a simple HTTP Proxy instead? All WCF using REST or SOAP are at their core HTTP requests. It seems like the routing functionality (which I am assuming you are basing on hostname, URL path or parameters) could be performed by proxying the HTTP request without needing to understand the contents. ASP.Net will do a fairly good job of sanitizing incoming requests on its own, but you could always add additional custom filtering as necessary.
Related
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.
We have developed the wcf service with the existing web service code. the existing customer wants to consume that service only changing the new url. They do not want to replace the proxy class. is it possible in any case.
The customer is able to consume the same with replacing the proxy and config. but he does not want to replace the proxy. please share ur comments whether it is possible or not.
You may be able to do this by configuring an endpoint using basicHttpBinding. I believe you will also need to force the use of the XML Serializer, and I don't know how to do that offhand, so someone else will have to help you with that. I'm concerned that there could still be small differences that would cause errors using the same proxy class.
On the other hand, if performance isn't the top consideration, you could create an ASMX service using the original class and method attributes from the old service. This ASMX service would then call the WCF service.
BTW, the ASMX service could call the WCF service on a fast endpoint. If they were running on the same server, they could use netNamedPipesBinding, for instance, but in any case could use netTcpBinding, which uses binary over TCP/IP. That would mitigate the performance difference from the extra hop.
I am developing a wcf service (basicHttpBinding) that should also be consumed by non .net clients (e.g. Java clients). But now I wonder how the client can define his client config file. Or is this file only needed for .net-clients? (I am thinking of configurations like maxReceivedMessageSize or maxItemsInObjectGraph for example).
Each development platform (call it as you want: SOAP stack, Framework, API) has its own way to configure communication. You don't need to bother with it. You just need to expose correct WSDL and client's developer will be responsible for configuring the client application based on his needs.
If you want to extend documentation of your service in WSDL you can use wsdl:documentation. WCF doesn't offer it by default but you can use this technology sample to extend WCF. You can use such documentation for example to describe that service operation can return large amount of data. Another approach to add wsdl:documentation is using WCF Extras.
From the sound of it, the client shouldn't have access to those configuration options. For instance, why should a client to the WCF service be able to specify the maxReceivedMessageSize?
What you probably want to do is define these configuration options on the server-side. If a client makes a call and there is a conflict with one of your options (i.e. the client exceeds maxReceivedMessageSize), you'll want to throw a SoapException back to the client.
If you want to let the client have access to the configuration settings before he or she sends a request, you can always implement a simple web service method that sends back the values.
I have a WCF Service that I want my client to be able to consume from IIS without going through a proxy. The client was consuming asmx service in vbscript using the htc behavior:
<div id="oWSInterop" style="behavior:url(webservice.htc)"></div>
oWSInterop.useService "http://localhost/WSInteroperability.asmx", "WSInteroperability"
Set response = oWSInterop.WSInteroperability.callServiceSync("BuildSingleDoc", 1002, 19499, XMLEncode(sAdditionalDetail))
So basically I just want to make this work with making as few changes as possible on the existing client. Am I forced to use a proxy (that is, a class on the client side that exposes the operations in the WCF service) when consuming a WCF service? I do understand the benefits of a proxy and am not opposed to using it for most other client implementations, but in this case I'm not sure I have the time to deal with it on the client - i just want it to work the way it has been with only the endpoint changing.
A client-side proxy class to call the service?
Yes, you definitely need that (unless you do REST-based WCF services, which you can call with a HttpClient alone) - that's where the whole WCF runtime lives and does its magic.
If you want to call up REST-based services, you can do this without any proxy whatsoever - but then you're left to do XML or JSON parsing yourself. It can be done, but it might not be such a great idea.
What's the problem with the proxy?? It's really just a small wrapper that bundles up your calls into a serialized message and sends it to the server side. No big harm, in my opinion....
What are you seeing? What makes you thank that proxy is an issue? If that is server-side code, it should use the browsers settings (WinINet) which should work fine. Perhaps the "localhost" would be an issue, though, since to the client that still means "talk to yourself" (i.e. not the server).
If that is server side you'll probably need to configure WinHTTP appropriately; in particular, to skip the proxy for local addresses. Of course, "localhost" should loop-back anyway...
I want to invoke a wcf service for testing on the http layer. I do not want to add a service reference and create a proxy and invoke. I want to create a new web test(VSTS) which sends a http request to the service and posts(Http post) the request in http body as an xml.
I have service metadata, with which I can see the datacontracts, but the wsdl:operation has only the operation name, wsdl:input is just blank.
On the Contary, an asmx service will have the soap request in the metadata which can be copied as the http request body, with the parameters replaced.
How to build a wcf service xml body from scratch just by looking at the service metadata (no access to the service logs as well), have got just the end point.
It is something like
<root>
<element1>element1</element1>
<element2>element2</element2>
</root>
But, how to find out this, root has to be some thing like
<FunctionRequest xmlns=""http://schemas...."" xmlns:i=""http://www.w3.org/2001/XMLSchema-instance"">
(tested for a local service and worked)
Now, without having access to service logs(svctraceviewer logs), not able to add a service reference, not able to use svcutil.exe(certificate based service), just only with metadata - wsdl, is there a way to find out the request that is to be sent to service?
Well, you will have to create proxy - either statically by adding a service reference or running svcutil on your service metadata, or you can construct it dynamically totally in code, if you wish.
In that case, you'd have to have your service contract (ISomethingService) at hand, and check out the ChannelFactory < ISomethingService > () concept - that should get you started.
Marc
Yes you can, but you have to do a little work first.
Build the service client by running svcutil.exe on the wsdl/xsd metadata. This will generate a c# with your service and data contract objects. Compile that to an assembly using csc.exe.
See the soap envelope body you can create a request object and manually serialize it with data contract serializer. Or you can host the assembly in WcfSvcHost.exe and add wcf logging to the config file. In either case you will only have the correct xml for the body, and even that might be wrong if the real service uses xml serializer instead of data contract serializer.
The next part is the hard part because you need to know the security model for the real service. If it only uses certificates for SSL and server identification, you should be able to send the xml using WebClient. But if it uses mutual certs and/or security tokens, you pretty much have to create a channelfactory by hand with the right bindings.