How do I build a XML-RPC web service in C#?
I've seen some people produce "web services" that are just simple .aspx pages that spits out Xml instead of html.
The "proper" way to do this is to probably to implement your own custom http handler though.
That said, you should have a really good reason to not use SOAP based services before you go to all that effort.
UPDATE: Have you seen XML-RPC.NET?
[It] is a library for implementing XML-RPC Services and clients in the .NET environment.
You could implement either a generic handler (.ashx) or an ASP.NET 2.0-compatible service (.asmx). You would then need to handle the XML parsing and construction either using .NET classes for XML or just on your own.
Edit: I took out information about WCF since the question changed, making it irrelevant.
if you mean RPC where you cliend simply sends raw XML via form variables, etc, and you parse it in the implementation of your service, .net 3.5 and wcf support out of the box POX services.
http://msdn.microsoft.com/en-us/library/aa395208.aspx
Related
I am trying to create a Windows Store App that consumes a web service. Visual Studio denies to create service proxy methods with following warning in logs:
Custom tool warning: Contract ... is not compatible with Windows Store apps because it contains one or more operations with SOAP Encoding (use='encoded'). Only the non-encoded operations will be generated.
So the questions are:
Where can I find full list of Windows Store app limitations on web services consumption?
Are there any known workarounds (given I can't change the service)?
It seems you're pretty much screwed if you can't change the web service because of the way that any wrappers are most likely SOAP encoded, and also the SOAP Toolkit doesn't allow for much output customisation.
Perhaps writing a (possibly functionally duplicated) web.api based webservice is a better solution? See this link for an example
EDIT: In response to the first comment...
Yes and no; essentially create a REST (whether that be webapi, WCF etc is upto you) wrapper.
See these informative posts on creating a REST wrapper:
helpfull post number 1 and helpfull post number 2
You can create a NETStandard class library to reference the webservice, then reference this library to your web project.
Does WebAPI support SOAP? I'm trying to write a SOAP Server in MVC4 and whilst I can do it in WCF it seems that WebAPI is replacing this but I see no ways to utilize SOAP in this yet, just JSON / XML using a REST Style interface.
To quote Scott Guthrie: The last few years have seen the rise of Web APIs - services exposed over plain HTTP rather than through a more formal service contract (like SOAP or WS*).
So I would say no.
You should consider looking at ServiceStack which allows your same service to support REST + SOAP APIs, although since SOAP only works over HTTP POST it has some restrictions
Add ServiceStack Reference
As an alternative to SOAP, ServiceStack offers a better alternative to WCF's Add Service Reference which can generate a typed API from a URL using Add ServiceStack Reference feature that's built into ServiceStackVS.
Advantages over WCF
Simple Uses a small T4 template to save generated POCO Types. Updating as easy as re-running T4 template
Versatile Clean DTOs works in all JSON, XML, JSV, MsgPack and ProtoBuf generic service clients
Reusable Generated DTO's are not coupled to any endpoint or format. Defaults are both partial and virtual for maximum re-use
Resilient Messaging-based services offer a number of advantages over RPC Services
Flexible DTO generation is customizable, Server and Clients can override built-in defaults
Integrated Rich Service metadata annotated on DTO's, Internal Services are excluded when accessed externally
WebAPI and WCF both promote RPC method signatures
What's interesting is that despite WebAPI ApiController methods having taken the same RPC approach as WCF in using C# RPC methods to create and define chatty web services with, that they're still not able to support their own SOAP standard made by the same company.
ServiceStack supports REST, SOAP, HTML and MQ endpoints with same service
This is a testament to ServiceStack's message-based design which offers numerous advantages not withstanding being able for the same service to support multiple endpoints and formats including REST, SOAP and MQ endpoints as well as generating server-side or client-side HTML websites if you need it. Here's an example of a rich Northwind database editor that because it was built with ServiceStack automatically enables a typed REST APIs that is able to be called with rich native Desktop clients, Mobile Apps and Single Page Apps.
SOAP is still a poor option for remote services
Although despite supporting SOAP for interoperability, accessibility and backwards compatibility reasons, we don't recommend it for building web services platforms with as it's un-necessarily complex, brittle, slow and verbose and there are much better alternatives to use. I explain more in detail in my interview on InfoQ.
WEB API is Microsoft's answer to REST based apis. If you want SOAP, go with WCF.
WebApi does not support SOAP out of the box, indeed. But it is a quite flexible framework and you could "adapt" it to handle SOAP: nothing prevents you from manually parsing the received SOAP messages (they are plain XML after all) and manually generating the responses as XML strings, then sending them with the approproate content-type header (you could even write your own content formatter for this).
Depending on your needs and your existing codebase, this may be worth the effort or you may want to use a more SOAP-firendly technology such as WCF or the already mentioned ServiceStack framework.
You might want to look at ServiceStack which should support both SOAP and REST in one interface without any hassle. It claims to be a better match than WebAPI for web services.
I can't claim to know everything about the difference, but the problems they claim are inherent in the Web API approach I can say from experience are real - API evolution (inevitable in a real project) is quite tricky in web api. And of course, web api doesn't support SOAP.
It is not like Wed API supports SOAP but due to SOAP is just a standard that uses XML and it travels throw HTTP you can use Web API to expose a POST Service to read the XML and find the nodes you need using XPath and then Deserialize the nodes to objects.
First, you need to add XML support to the ConfigureServices
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
.AddXmlSerializerFormatters();
}
Then in your controller, you just need to add a method that receives an XMLDocument and with XPath search for the node you are interested (Basically removing the soap envelope, the header, the body) and then you can deserialize the object.
In my case, I add the service reference using the WSDL and with that, I deserialize the object.
[HttpPost("reservationxml")]
public void CreateReservationFromTSW(XmlDocument soapCreateReservationRq)
{
XmlNamespaceManager nsmgr = new XmlNamespaceManager(soapCreateReservationRq.NameTable);
nsmgr.AddNamespace("r", "http://soa.company.com/ReservationEnt");
nsmgr.AddNamespace("s", "http://www.w3.org/2003/05/soap-envelope");
XmlNodeList xmlNodeList = soapCreateReservationRq.SelectNodes("s:Envelope/s:Body/r:CreateReservationRq",nsmgr);
XmlNode xmlnode = xmlNodeList[0];
XmlSerializer serial = new XmlSerializer(typeof(ServiceReference1.CreateReservationRqType));
ServiceReference1.CreateReservationRqType rq = (ServiceReference1.CreateReservationRqType)serial.Deserialize(new XmlNodeReader(xmlnode));
}
As you can see in the next image the service that tries to consume your service uses a Request Method POST with the Accept-Encoding: gzip. That is why you can expose a Web API that can be consumed for a SOAP service.
Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
At my last place we used to do a lot via XML SOAP - Basically the client would construct an XML request which would contain the service to invoke and send that onto a host and port
The server would then take that service request and figure out the class and method to call and serialise the request / response
This was helpful as we had Java and C# and wanted to segregate the two
If you had to build this out what libraries would you use?
Specifically how the main machine translates a service name => class and method invocation
In C# I'd look at WCF in the first instance, that allows you to create web services very simply.
For Java, I have experience with axis2 from Apache. It works well enough that I would recommend it and use it again on a SOAP project.
I've recently discovered a way to implement RESTful services using Global.asax (by handling the Application_BeginRequest event). Basically, I am saying it is possible (and easy) to implement a RESTful web service in classic ASP.NET, without any need for WCF.
It takes approximately 30 lines of code to figure out which method you want to call (from the URL) and pass it parameters (from the query string, via reflection) as well as serialize the result using XmlSerializer. It all leads to a web service that can be accessed through HTTP GET requests, and returns standard XML data.
So with that in mind, is there any reason to use WCF when creating a RESTful web service that will be invoked only through HTTP GET requests? WCF introduces a lot of overhead and restrictions, whereas the Global.asax approach I described above is much easier to implement, customize, and deploy.
Note - JSON endpoints can also be implemented without WCF by using the JavaScriptSerializer.
Also - HTTP POST requests can be handled by Global.asax in a similar way.
So in the end, what would be the reason to use WCF in such a case? Is there better scalability or performance?
You can also use Asp.Net MVC to implement REST quite easy.
What you don't get for free with this approach is:
non-HTTP bindings.
support for multiple message formats.
non-IIS hosting.
control over the process activation.
control over the instance creation.
object pooling.
message queueing.
transactions.
scalability and reliability.
additional technologies built on top of WCF like the OData support.
If none of these applies to your scenario - you don't need WCF.
The answer is, 2 different pipelines, but the WCF pipeline was built specifically for services, and ASP.Net was built for rendering content via HTTP. Both have their pluses and minuses.
If you are comfortable with the ASP.net stack, and don't have to worry about things like standards, then ASP.Net is fine.
But if you want the best of both worlds, try WCF Data Services, all the cool built-in features of WCF, with none of the hassles. Currently, MVC does not have a view engine to generate OData.