I Want to create a SOAP proxy, that modifies the original web service SOAP header, nampespace and keeping the body the same)
What is the best way to do this? Create a SOAP provider , that consumes the original web service then modify the header and namespacs? (this seems like alot of work?)
If you have few SOAP services, your suggestion is the way to go. If you have many SOAP services you want to transform, it might be a better idea to write a HttpHandler. See http://msdn.microsoft.com/en-us/library/5c67a8bd(VS.71).aspx for more information.
Related
I have code that calls a web service. We'll say a "3rd party" web service. So I can get the wsdl for this service, in fact I've generated a proxy class using this wsdl.
The requirement that I'm trying to meet is this: Create a web service that LOOKS just like the above mentioned one, but does other stuff. So the web service URL will be changed in a config file/database, to allow switching between the two web services.
What I'm not sure about is how I can use that proxy class that I generated, or some other method, so that the namespacing and data contract look exactly the same. I don't know much about this and these are terms that colleagues have tossed out there. I only need to actually implement one of the web service's methods in my version.
Build site with any technology you know of and return responses that match that service.
Note that if you just need to return static enough responses for occasional testing you can use Fiddler as it allows to return arbitrary responses instead of real once.
don't know if you can help a poor befuddled c# programmer, but here goes. I have a client with a legacy Java Soap app that we need to accept incoming Soap requests from. I have built a solution and tested it and all is well.
When I let the Java app loose on the ASMX file, it fails because I cannot for the life of me get my code to accept the soap action needs to be understood at my end.
The soap action sent is by the Java is:
urn:mycode:uk:gi:dis:supplierenmanager:v02:SupplierManager:AppointManager
Whereas I have used the following against the class that is created when a new web service is added:
<WebService(Namespace:="urn:mycode:uk:gy:dis:suppliermanager:v02:SupplierManager:")>
Then on the method, I have added:
<WebMethod(MessageName:="AppointSupplier")>
This works apart from one little problem. The combination of the above provides the following soap action:
urn:mycode:uk:gi:dis:supplierenmanager:v02:SupplierManager:/AppointManager
As you can see, I am getting an extra forward slash and thus the soap action is rejected.
Does anyone know a work around, or if I am better off using WCF now?
If the answer is USE WCF DUMMY, that is fine and would willing accept that as an answer, but if that IS the case, can someone please point me in the direction of some samples that will explain how to deal with SOAP headers and the dreaded SOAPAction.
Thank you
Can't see a solution to this, but now looking at converting code from ASMX web service to WCF service that consumes soap.
This is because if I create an empty asp.net site and add a wcf service, I can add the following code to the function declaration in the interface code:
<OperationContract
(Action:="urn:mycode:uk:gi:dis:supplierenmanager:v02:SupplierManager:AppointManager")> _
This DOES create the correct SOAPAction.
If REST based web services are as simple as GETing and POSTing to a url and parsing the response wht exactly do we need a wsdl? Whats the point. I understand that when using SOAP based services it is used to construct the SOAP requests and responses but dont really see why visual studio provides me with a wsdl when I create a REST based service...
WSDL is designed to allow clients to discover service capabilities, primarily at design time. REST has the hypermedia constraint that requires that all service capabilities should be discoverable at runtime via the linked representations that they return.
Proper REST services are naturally discoverable therefore there is no need for a WSDL specification in addition.
There is no point in WSDL for REST services created with WCF because WCF supports only WSDL 1.1 (or 1.0) which cannot describe REST seevice. If you try to use WSDL generated for WCF REST service to create a client proxy you will not be able to call the service anyway. Visual studio templates for REST don't expose metadata so you will get useless WSDL only if you add serviceMetada behavior (and possibly also mex endpoint) yourselves.
WSDL 2.0 and WADL supports description of REST services and the point is similar as with SOAP services - describe what you can do with the service but in the REST way.
There's no point. WSDL is just a standardized description of what a service exposes and how can be invoked. You don't need WSDL, but you need some way of documenting what can be done with your service, so that clients know how to invoke it.
Just trying to wrap my head around SOAP vs REST. We currently have some asmx web services, mostly used between our own JavaScript and server code (not a public API). When I specify my method as a ScriptService and specify a ResponseFormat of Json, is it still considered just a SOAP service? It still doesn't feel RESTful to me, but maybe thats because of the way my "resources" are designed (not well/fully represented by rest).
EDIT: Reading more I might be confusing the format (JSON vs XML) with the fact that most descriptions of the SOAP protocol tie in XML. For example, wikipedia states:
It relies on Extensible Markup
Language (XML) for its message format
To me logically that says if I'm using JSON I must not be using SOAP.
This isn't exactly what you asked, but ASMX services are not RESTful if you're calling them from JavaScript and retrieving JSON. You must make a POST request to ASMX services to get JSON out of them, even if the request is idempotent and only retrieves data. In a RESTful API, a GET request would be used in that case, not POST.
That's not to say that the lack of RESTfulness is an actual problem for a private API. I've found ASMX services as a JSON-based service layer for AJAX callbacks works great in practice.
You define what kind of requests are made to you web service (asmx). Many protocols are allowed:
HTTP POST,
HTTP GET,
SOAP 1.1,
SOAP 1.2,
etc... OR you can block any of them.
When you call the web service with javascript you can use POST or GET. It doesn't matter. The trick is what type of content you tell the service to return in these calls. You can tell the service to send you JSON or you can tell the service to send you XML.
When you create a service client in Visual Studio to connect to a ASMX service, Visual studio will try to access the WSDL for the service and the client will be in charge of generating the SOAP envelopes to communicate with the service and in this case you will send and receive XML because thats what the client and server have agreed to use to communicate.
Before I venture down the path of creating one, I was wondering if anyone knows of a utility program which will take the REST Help page of a WCF Rest Service and create the relevant Client for C# consumption.
Similar to what svcutil.exe does for WCF Services or what wsdl.exe did for web services but for WCF REST Services
Kind Regards,
Andrew
EDIT Some more detail:
Please see this link: http://msdn.microsoft.com/en-us/library/dd203052.aspx
In the restful service using the WCF Rest Starter Kit Preview 2, they supply types which will be serialized. But My intention is be able to create clients form the help page which describes schemas. Clients could then be created for C#, JavaScript, ActionScript etc.. shearly as a strongly typed version of the restful service, not a requirement or necessity. It is a program or uitlity I am wondering exists which does this
I think you might be looking for the WebChannelFactory. It can generate a channel class based on a WCF-attributed REST interface.
Well, there will not be any use even if you would like to abstract. ALL Rest services can use HTTP verbs like GET, POST, PUT, DELETE
So, basically what your client can have is only a static class which can accept the end point, network credentials, a name value collection which needs to be passed and the verb to use.
This would be more of a utility class rather than a client.
I don't remember seeing WSDL or some contract based on which we can write clients for the REST services.
I hope you don't spend too much time basing your code on the current help page of a pre-release piece of code. Are you even sure this help page provides all the information you would need to produce clients?
Also, have you seen Prerelease 2 of the WCF REST Starter kit yet? If no, go look. There's new client-side technology in there.
Why would you create clients for a RESTful service? You don't need one - you just need to be able to initial HTTP requests. If you would like to call the same operations via SOAP or some other method then create a new endpoint for the service and a new contract and expose mex for it so that svcutil can consume it.