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.
Related
I have a web service written in C# using SOAP. A client has requested the same service be available as a REST based service.
Is there a clever/quick way I can achieve this, or am I looking at a rebuild from new?
SOAP based services are built with a completely different set of constraints than REST services. If the services is simple then the end result of the two approaches may look somewhat related, but in reality they are two completely different approaches.
SOAP and REST are different not only conceptually but mechanically.
Conceptually SOAP methods are pretty much RPC, remote procedures. So your web methods look like "GetListOfCustomers" and "DeleteCustomer". While in REST you model Customers as resources and use HTTP verbs on these resource. To get the list of customers client will send HTTP GET and server will return customer representation in XML, JSON, HTML or custom format. Customer representation may have embedded URL links that will allow client code to delete customer for example. This is called HATEOAS
Mechanically SOAP is a layer on top of HTTP. Layer that ignores and reimplements existing HTTP capabilities like envelop, verbs, caching, encoding etc. As opposed to REST that relies on all these HTTP features. So mechanically REST is simpler because there is no additional layer that SOAP has.
When you were asked to make existing SOAP service to be available as REST it probably implied purely mechanical aspects. You probably need "XML RPC over HTTP" which will require some work on your part but may not be as hard as redesigning API from SOAP/RPC to REST/HATEOAS.
The solution will depend on how you implemented the SOAP web service.
This is not a "conversion". You will be writing a REST-based service to do the same sorts of thing that your SOAP service does. If you developed your SOAP service correctly, then you will be able to reuse much of the code. You will then be able to deploy a single service that serves both requirements.
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.
So I'd like to connect a wpf c# client to a java backend via web services.
I have a few questions regarding this and I am a bit new to web services so please bear with me..
Would I be using a wcf web service or would it most likely be a java construct (and if so which one?)
Would I be using soap or rest? i know this is a big topic but I'm just looking for which one would most likely be used.
Lastly, would I be able to run java methods via my c#? for example say I have a method that lives on the server called called "Customer GetCustomer(int id);" ... would i be able to call this method in my c# client? And how would the customer come back would it come back as xml and then I'd have to parse this xml and build a Customer object on the client side? meaning, would I have a duplicated class definition on both the server and client, or would I somehow share the same Customer reference?
Thanks in advance!
Expose a SOAP service from your Java backend, and access it using WCF. Easy and painless
SOAP is easier, and requires less work when you use WCF.
Yes. SOAP allows you to define ComplexTypes which would represent your classes, so the C# mappings would be pretty much the same as your Java ones.
I would recommend reading up about SOAP and WebServices in general, that should answer a lot of your questions.
Regarding question number 3, when you expose your logic in Java as as a web service... Now I do not have enough knowlegde on how to deploy a java web service but when you deploy it, what remains is to create a proxy in C# and start calling your web methods.
Elaboration:
Creating a proxy (in .NET web services or WCF) (AKA adding a Web/Service reference) means that you recreate all the exposed classes/types in your java WS methods as local types in C#. These types will be exposed (on Java WS side) using an XML document called WSDL (Web Service Definition Language). This will make a second copy of all the types used in the Java WS webmethods in your C# program, you can call this redundent, but this is the only way that you can communicate with a Java WS from .NET
Afterwards, when your C# program runs, and reaches the call to the proxy of your Java WebMethod, the proxy will transform the web method call's arguments (class instances) used by the WS proxy to XML representation. This is called encoding your object(s) using SOAP, the client creates a SOAP envelope that contains all the necessary data/objects - arguments (encoded with SOAP) and sends the SOAP envelope to the JAVA WS. The Java WS decodes (reverses XML to java instances) the objects embedded in the envelope, and calls the correct Web Method according to some hints also found in the SOAP envelope.
When the call to the Java WS is completed all the instances that must be returned to the client (if any) are also encoded using SOAP, and sent to the client as a response to the WS call.
My understanding is that a c# based client "prefers" SOAP because when you add a web service reference it creates a proxy class from the wsdl found at the url you specify.
Which almost makes it transparent to the c# client that we are even using a web service, it almost feels like we are using a local class library. you call methods and you use objects.
My question is can REST achieve the same affect. I assume that it can't since it doesn't have wsdl and thus visual studio can't generate a proxy class for it. But Please correct me if I'm wrong?
A "run of the mill" REST service cannot achieve the same kind of tight integration with C# - mostly because it lacks the metadata that a SOAP service will provide (with a list of methods and their parameters and all that stuff).
The WCF Data Services (built on top of REST) do work much the same way as SOAP services, since the OData protocol contains extensions for pure REST services that provide metadata information needed to create a good, useful client-side proxy.
REST can be used to generate client side class libraries. For Example You can create proxy classes for MS generated REST services. In fact MS is actively pushing this model for Entity Framework based WCF DATA Services, e.g. those used by Silverlight and RIA applications. check out MS ODATA framework for REST which involves creating client objects out of standard REST queries.
http://msdn.microsoft.com/en-us/library/dd673930.aspx
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