Has anyone ever implemented batching support on top of WCF Service(not WCF data service) using HTTP multipart requests? I was looking over internet an found a tutorial over how to do the same in WebAPI and WCF Data Service but not on how to do the same in WCF Service. Any suggestion or references.
Also, if there is no in build support to do the same then how to construct the multipart response in the azure web role and what should be the return type of the request handler function?
Take a look at the messageEncoding property in the wsHttpBinding. You will want to use MTOM as your encoder for this scenario. Here is an example from the SDK.
http://msdn.microsoft.com/en-us/library/aa395209(v=vs.110).aspx
Related
I have an azure function app (v1, with no possibility for upgrading, unfortunately) with an endpoint receiving JSON via POST requests, doing some computation and returning JSON in the response. This endpoint needs to be made SOAP-compatible, meaning that it should receive SOAP requests and return SOAP responses and also be able to provide a WSDL file.
Using the SOAP mapper in API Management is not an option, due to its limitations.
The methods I have tried are:
Create a WCF service and try to delegate the HTTP request to it from the Azure function endpoint. This didn't seem to work because the corresponding handler in WCF can only receive a request via its own HTTP endpoint (which does not seem to be exposable via the azure function endpoint), but cannot be called from within the code.
Use an ASP.net web application with SoapCore as a starting point and try to migrate it to an azure function. This doesn't seem possible because of a completely different structure. SoapCore is attached to the ASP.net app instance as a middleware, whereas azure function does not provide the means to use middleware.
Parse the SOAP request manually, convert it to JSON, do the computation, convert the result back to a SOAP message and return it. The seems very hacky and also the WSDL must be created and served manually. Despite these drawbacks, I'm leaning towards this solution because of the unfeasibility of the first two.
Is there any other possible solution that I have might missed?
If you are using Azure API Management , then below option works;
You can write transformation policies at the service or endpoint level - JSON to SOAP refer: https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#convert-json-to-soap-using-a-liquid-template
Also refer this link Expose REST API as SOAP via Azure API Management would help.
I have a WCF Service, and I need know it ,is possible consume form an ajax client?
The extension of the workflow files that I intend to consume are of type .xaml
WCF Xaml-based WF Services are exposed as SOAP based services, so ajax client can work out, but it would be very difficult to construct the payload. I would recommend to create a thin layer of webapi that can accept json and interact with WCF service.
I have an old SOAP api that uses an ASMX endpoint, will Azure API Management be able to recognize and interface with it?
There are more people interested in this feature: feedback.azure.com. This is currently not supported however.
Support for pass-through SOAP endpoints was added recently: https://azure.microsoft.com/en-us/updates/general-availibility-azure-api-management-soap-pass-through/
SOAP-to-REST scenarios are also possible using policies: https://blogs.msdn.microsoft.com/apimanagement/2016/12/14/soap-to-rest/
I'm looking for a way to secure my WCF service using http and simple username-password authentication, without using certificates.
The service is consumed by an Android device so I can't use the .NET Proxy generated classes.
I've read about basic HTTP authentication but haven't found an easy way to implement this method.
Have you tried using the MSDN custom Username/Password validator for WCF? It relies on the serviceCredentials configuration and implementing a UsernamePasswordValidator.
I've found ASP.NET Web API, seems like a better solution for REST-based Services than WCF.
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.