SOAP and Web Services

Rym

So, I'm an IT guy, not CS. I write code, but I am by no means a coder. My work is mostly in scripting, infrastructure, planning, logistics, etc...

For SOAP web services (WSDLs and all that), what platforms do you proper CS guys prefer? I basically just need to expose some server-side functionality to an application that has no other interface than this. (Otherwise, I would have used simpler means). I'm using ZSI in python right now, and it works well enough, but it's hardly robust, and most of the documentation I've found is fairly dated.

I'm not beholden to Python: that was just the quickest way to get an interface up for my developers to start testing with. Should I use .NET or Java? The latter, at least, seems to have a more well documented suite for this sort of thing.

Apreche

I've never made a SOAP web service from the server side, but I have done non-SOAP on the server. From the client side I have used Ruby, PHP, Python, you name it.

Surprisingly enough, the easiest time I ever had with SOAP was when the server side was .NET and the client side was PHP. All I had to do was create a SoapClient and pass it the WSDL. After that it "just worked". The SoapClient object provided all the API calls in the WSDL, and they all worked. I had to do some processing on the output, of course, but that's what glue programming is all about.

George Patches

.NET is super easy as Microsoft has done most of the heavy lifting for you. The downside is that you're tied to Microsoft stuff and from what I've heard from you, you guys sound like more of a Linux shop. I can't really comment on Java right now, as I've never done a server side web service in Java. I've just been handed the task and I'm still setting up my dev environment. The immediate downside seems to be that it's not a robust and varied framework that's ready setup for you like .NET. I'm still fiddling with packages just trying to get the pre-existing code to compile.

But yeah, from what I remember in college it's .NET or Java. Anything else for server side is probably gonna be pulling teeth.

Rym

Surprisingly enough, the easiest time I ever had with SOAP was when the server side was .NET and the client side was PHP. All I had to do was create a SoapClient and pass it the WSDL.

Yeah, client-side is easy. The WSDL provides everything you need to interact even if you don't know fully what's on the other side of the interface. I even wrote a raw client before I used the proper libraries.

Server side is more of a bitch, I'm finding. At least Eclipse has a tool that will make a properly formed WSDL. ZSI has a tool (wsdl2py) that will take that wsdl, validate it, and then create the stubs for a server and client. It just feels so hacked together they way I'm doing it. 99% of the examples on the Internet are for clients, and I have a feeling that the people who write servers are the same people who don't bother documenting things for the public eye. ^_~

Rym

So, in case anyone cared, the end result is that Python is not where you want to be making SOAP servers. The infrastructure is too immature, fractured, and unmaintained. Clients are fine (because clients are easy).

.NET is where you want to be if you have to serve compliant SOAP with WSDL files.

Apreche

So, in case anyone cared, the end result is that Python isnotwhere you want to be making SOAP servers. The infrastructure is too immature, fractured, and unmaintained. Clients are fine (because clients are easy).

.NET is where you want to be if you have to serve compliant SOAP with WSDL files.

Mostly because anyone using Python isn't using SOAP.

Rym

Yeah. It's just annoying to me, as the enterprise world uses SOAP extensively. Every job I've had in IT has involved SOAP (except the project implementor gig I had at RIT), and most enterprise apps can only interact via SOAP.

George Patches

So, in case anyone cared, the end result is that Python isnotwhere you want to be making SOAP servers. The infrastructure is too immature, fractured, and unmaintained. Clients are fine (because clients are easy).

.NET is where you want to be if you have to serve compliant SOAP with WSDL files.

Sounds like what I thought. .NET is not too bad though, despite needing microsoft servers.

Apreche

Yeah. It's just annoying to me, as the enterprise world uses SOAP extensively. Every job I've had in IT has involved SOAP (except the project implementor gig I had at RIT), and most enterprise apps can only interact via SOAP.

That's because the systems you are working with were written years ago by Java and .NET guys. Thus, it sort of makes it advantageous to also be a Java/.NET guys, and so it spreads.