I need to capture and run realtime analysis on messages being exchanged between various web services implemented in Java and client apps. The server code and config can not be modified and is hosted on various servers.
Is it possible to build a proxy layer that will take all calls from the client app and route them to actual web services.
So it needs to do the following:
Accept a config file containing endpoints for various web services that need to be proxied
For each end point, generate a proxy URL
The client apps will point to these proxy URLs
The proxy layer will listen to traffic on these proxy URLs, and route them to real end points.
Track all SOAP traffic in between the client and services and run the necessary analysis.
I considered SoapUI but it does not seem to provide enough control that I need for realtime analysis.
You should start with WCF Routing service. Once you have working communication you can add some custom message processing through custom behaviours or channels to grab SOAP messages and do your analysis.
Related
UPDATE 2: Solved the first problem (note below) - reduced the complexity/scope.
NOTE: If migrating from self-hosting WCF services in Cloud Services to Service Fabric using HttpsBinding then you need to change the HostNameComparisonMode from Exact to StrongWildcard.
I have scenario where I have to open many (100+) WCF Service Hosts to receive callbacks from an external service. They have same Contract but with differing credentials (service certificates are unique to each of our customers).
I would like to know if it is possible to route all requests through a single Host/Router that could check the connecting clients expected service certificate and either a) spoof/ignore (preferably) the service certificate or forward the connection onto the correct host.
I want to avoid having to load hundreds of service hosts with different credentials (which are stored in a database) when the service fabric node first comes up so I don't receive traffic to a service that's not loaded yet. Ideally I could load them when needed or not have to load them at all (spoofing certificate or something).
Looking for someone who is a lot savvier with WCF to shed some light on the possibilities. Thanks.
I am integrating an application with database through Mule. I have exposed database queries as SOAP web services in Mule. In all there are 4 such services. These are in 4 different flows hence will be running on different ports. The problem is there is an internal firewall between application and Mule. I need to tell network administrator upfront the ports that I want to open up for inbound connections from application to Mule.
For any new service I need another HTTP port and ask for changes in firewall rules. One solution I could think of is having common entry flow (hence single HTTP port) which then delegates requests to other flows through VM or JMS transport. However I think it can be designed in better way to remove or minimize dependency on network configurations with multiple HTTP endpoints. Please advise.
If you would be deploying four different web services (i.e. 4 different WSDLs) in a JavaEE container, you would probably use the URL's path to discriminate across the services (say: /accounts /orders...).
You can achieve the same in Mule using a single HTTP endpoint and choice router, since your four services are in 4 different flows (and not 4 different applications, for which case using JMS, or the new shared VM endpoints, would be a must).
In the choice router, you can route the HTTP requests based on the http.request.path inbound property (see: http://www.mulesoft.org/documentation/display/current/HTTP+Transport+Reference#HTTPTransportReference-HTTPProperties )
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.
I have built a Windows forms application in C# using WCF for client -> server communication. I have recently begun toying with Silverlight and built a web front end for the application which still uses the same WCF service for web client to server application. What I'd like to do is have my WCF behind a firewall on a different machine and then build an "intermediary" WCF service which would live in a DMZ between IIS hosting my Silverlight client and the WCF box.
Essentially I want to seperate the WCF service which runs my windows forms application from also acting as a webserver. Does it make sense to build this intermediary app to increase security?
Can't see how that would increase security other than forcing connections to the WCF service to go through the DMZ ... but a straight forward http proxy server would do the trick.
The intermediary becomes more useful when you have a whole bunch of services and you want to centralize things like aunthentication, message logging in a single location or if you want to do some fancy (or not so fancy) message routing such as load balancing between a few services.
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.