Soap Server? Is it possible?

[NeilA]

I have made some methods that I invoke using REST. I have been helped to write a C# layer that converts SOAP calls to REST URI (long story , my team decided on SOAP over a year ago before I worked here, and that is that) any way I had a lot of trouble importing SOAP WSDL to do some calls back the other way so I built my own client using string manipulation and TCP vi's to send calls and collect the responses (these work well so far). This got me to thinking about making my own server! I was wondering if I could use a similar technique to the XML-RPC work in the code repository. There are similarities between the two protocols that make me think it could be possible. It sounds like hard work but my soap to REST implementation is a bit dodgy and I really don't like the way that I cant debug the methods through the calls as they are run in memory in a different instance.

I had the REST implementation working fine but after making the SOAP client I found I needed a lot of tidying in my project and the REST implemention has not worked since. This is what once again highlighted the the debug issue when using REST. I would like to keep it simple by implementing my own server for SOAP and be done with aditional layers etc. The problem here is I had trouble after tidying the project what could happen after building an executable and moving machines etc. for the additional time spent now I may have a better more robust deliverable later.

So, has anyone had similar experiences with REST and application instance issues( I was helped out a lot by guys on here before and followed the steps that were given to me then but to no end this time)? Has any one attempted to write there own SOAP Server? Do you think it may be possible to use some of the XML-RPC ideas to get a SOAP server running?

Thanks in advance!

Neil.

[Mark Smith]

QUOTE (NeilA @ Apr 2 2009, 12:00 PM)

I have made some methods that I invoke using REST. I have been helped to write a C# layer that converts SOAP calls to REST URI (long story , my team decided on SOAP over a year ago before I worked here, and that is that) any way I had a lot of trouble importing SOAP WSDL to do some calls back the other way so I built my own client using string manipulation and TCP vi's to send calls and collect the responses (these work well so far). This got me to thinking about making my own server! I was wondering if I could use a similar technique to the XML-RPC work in the code repository. There are similarities between the two protocols that make me think it could be possible. It sounds like hard work but my soap to REST implementation is a bit dodgy and I really don't like the way that I cant debug the methods through the calls as they are run in memory in a different instance.

I had the REST implementation working fine but after making the SOAP client I found I needed a lot of tidying in my project and the REST implemention has not worked since. This is what once again highlighted the the debug issue when using REST. I would like to keep it simple by implementing my own server for SOAP and be done with aditional layers etc. The problem here is I had trouble after tidying the project what could happen after building an executable and moving machines etc. for the additional time spent now I may have a better more robust deliverable later.

So, has anyone had similar experiences with REST and application instance issues( I was helped out a lot by guys on here before and followed the steps that were given to me then but to no end this time)? Has any one attempted to write there own SOAP Server? Do you think it may be possible to use some of the XML-RPC ideas to get a SOAP server running?

Thanks in advance!

Neil.

Neil,

As the developer of the XML-RPC LabVIEW server, I thought I'd throw in my two cents worth. First, I am not any kind of expert on web services, either SOAP or the RESTful protocol the LV 8.6 Web Server uses. I developed the XML-RPC server to support a project where the intention was to deploy LVRT targets (cRIO chassis) and then be able to control and monitor the distributed systems from any platform (the orginal spec was a Java app running under Linux as the system manager). I kept the implementation pure G with as little bells and whistles as I could so I could be confident I could deploy the project as an executable under LV as old as 7.1 and to any target that supports LabVIEW. The XML-RPC protocol was chosen because most languages and platforms have XML-RPC toolkits (Java, .NET, python, perl, etc) and because the protocol is very simple and lightweight - the whole spec can be printed on seven pages (at 10 point font)! This made it practical to roll my own server including the protocol parsing and packaging. I'm not so sure the same can be said of SOAP. I briefly looked at the spec and it seems like it might be an order of magnitude more difficult to create the necessary parsers and message packaging tools. I also poked around a little and I had a hard time finding any useful information about SOAP parsers/packagers - most of the SOAP protocol stuff is wrapped in WSDL and then that is wrapped in a server-specific implementation (ASP, for example). If you can find a simple SOAP parser, that could simplify using the XML-RPC server as a framework for a SOAP server. But the SOAP protocol is still just XML so if one can do XML-RPC then one can do SOAP - it just will take longer.

But it would just be a SOAP server - it seems that generally SOAP calls are made thru a web server. The web server must recognize the SOAP protocol and dispatch it correctly but also handle anything else that a web client might throw at it. My XML-RPC server just returns an error if it sees ANYTHING other than an XML-RPC call. But the up side is that the server architecture is straightforward and easy to follow, which can't be said of most other implementations.

Mark

[NeilA]

QUOTE (mesmith @ Apr 3 2009, 04:14 AM)

But it would just be a SOAP server.

This is the thing, I have the request and response templates for each of the 10 or so methods that will be used. I have already made methods for decyphering the xml in the soap body when used with my SOAP to REST conversion and REST LV invocation. I have written a robust client for the methods in the other direction so, I am familiar with SOAP messaging. Therefore it is literally a server. I dont need a template etc. it will be just (for now) an implementation for this system with methods that map to an older messaging system so we know that the messages are mature and unlikely to change drastically in the future.

The problem I had was with the incoming TCP connection, but after looking at your server I see that you use a producer consumer pattern to dequeue TCP references. Is it possible to explain a bit further what you are doing in the server vi? Is there any particular reason that you use the set server vi (I have not seen this before)?

I have attached an example of the SOAP methods I have to use they are all pretty simple having a body that either contain a UUID (a GUID provided by the other system to tie the messageing) and/or parameters in xml format. and the response is similar but with an additonal status.

POST /RMSInterfaceSim/RMSWebService/RMSService.asmx

HTTP/1.1Host: pthaitwebdev

Content-Type: text/xml;

charset=utf-8Content-Length: length

SOAPAction: "http://RMS/TerminateTest"

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header>

<UUID xmlns="http://RMS/">

<UUID>guid</UUID>

</UUID> </soap:Header>

<soap:Body>

<TerminateTest xmlns="http://RMS/" />

</soap:Body>

</soap:Envelope>

HTTP/1.1 200 OK

Content-Type: text/xml;

charset=utf-8Content-Length: length

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header>

<UUID xmlns="http://RMS/">

<UUID>guid</UUID>

</UUID>

</soap:Header>

<soap:Body>

<TerminateTestResponse xmlns="http://RMS/">

<TerminateTestResult>

<Status>int</Status>

<Message>string</Message>

</TerminateTestResult>

</TerminateTestResponse>

</soap:Body>

</soap:Envelope>

Many thanks for any help!!

Neil.

[Mark Smith]

QUOTE (NeilA @ Apr 3 2009, 03:33 AM)

This is the thing, I have the request and response templates for each of the 10 or so methods that will be used. I have already made methods for decyphering the xml in the soap body when used with my SOAP to REST conversion and REST LV invocation. I have written a robust client for the methods in the other direction so, I am familiar with SOAP messaging. Therefore it is literally a server. I dont need a template etc. it will be just (for now) an implementation for this system with methods that map to an older messaging system so we know that the messages are mature and unlikely to change drastically in the future.

It seems you want a single purpose server (just to handle SOAP requests) so in many ways this would look a lot like the XML-RPC server I built except the protocol would be a bit different. And it seems you have a way to unwrap the incoming requests into LabVIEW calls and then wrap the responses into SOAP as well - so I would think you're better than halfway there - maybe three-quarters.

QUOTE (NeilA @ Apr 3 2009, 03:33 AM)

The problem I had was with the incoming TCP connection, but after looking at your server I see that you use a producer consumer pattern to dequeue TCP references. Is it possible to explain a bit further what you are doing in the server vi? Is there any particular reason that you use the set server vi (I have not seen this before)?

Initialize: The server VI creates a queue for connections and opens a listener with the Wait on Listener - whenever a new connection is accepted, it gets dequeued in the "Dequeue" case. The initialize also creates queues for the message request and the message response and establishes a path for the Fault Log and hides the front panel. Queuing up the connection requests means that the server can service those requests even if they come faster than the methods requested can respond.

Transitions to Dequeue or Error

Dequeue: In this case, a connection gets dequeued and the TCP Read All reads the data from that connection. Inside the TCP Read All the logic is to read enough of the HTTP header to make sure you get the "Content-Length" field and use that value to make sure you've retrieved the entire message (or timed out or gotten an indication the client has closed the connection) before you stop reading. Now you should have a complete XML-RPC method invocation message in HTTP - in your case, you should have a complete SOAP invocation. Now, the message gets passed to the XML-RPC Request Parser that checks that it is a valid Method Call and if it is it parses out the method name (in this implementation, the method name is the VI that will get called) and the parameters (if any) that get passed to the VI. Here's where you would parse your SOAP invocation into the VI that will service the request and the parameters to pass.

Transitions to Remote Procedure Call (if the message is a Method Request) or Server State or Exit (if the message is from the Set Server VI) or Error

Remote Procedure Call: In this case, as documented on the diagram, we use the Method Name to identify the VI to call, enqueue the parameters onto the methodCall queue, and launch (asynchronously) the method VI. If we get an error calling the method, flush the methodCall queue and push a fault on the methodResponseQueue - if no error was encountered, the called VI will push a response on the methodResponse queue. The MethodResponse will have a connection ID the identifies which connection made the request and expects the response. When the MethodResponse gets put on the queue it's already a fully formatted XML-RPC Response. The called VI is responsible for wrapping the response in the XML-RPC Response format.

Transitions to Dequeue (to wait for the next request) or Error

The Server State case just responds to commands form the Set Server VI, the Error case converts errors to XML-RPC faults (reported to the caller) and logs faults to file, and the Exit case just cleans up on the way out.

The Set Server State VI exists because the Server runs "headless" - no front panel. If you want to open the server front panel or stop it or change the debug level, you need this UI component - or you could pass it the appropriate XML-RPC method call from any client. But you can start the server directly and never use the Set Server State if desired.

Hope this helps!

Mark

[NeilA]

QUOTE (mesmith @ Apr 3 2009, 05:18 PM)

Hope this helps!

It does indeed, a great write, up thank you very much for taking the time. It clarifies what I worked out today and more. I was uncertain about the internecine avoider.vi, I even had to look the name up on google lol. However after doing some investigating I see that it just negates any TCP port issues, is that correct?

I am going to try and investigate the implementation next week after the weekend, if I have any good progress and come up with anything useful to others I will post it up.

Many Thanks,

Neil.

[Mark Smith]

QUOTE (NeilA @ Apr 3 2009, 12:11 PM)

It does indeed, a great write, up thank you very much for taking the time. It clarifies what I worked out today and more. I was uncertain about the internecine avoider.vi, I even had to look the name up on google lol. However after doing some investigating I see that it just negates any TCP port issues, is that correct?

I am going to try and investigate the implementation next week after the weekend, if I have any good progress and come up with anything useful to others I will post it up.

Many Thanks,

Neil.

The internecine avoider (I had to look up as well) is from the \vi.lib\Utility\tcp.llb and is part of LabVIEW - as far as I can tell it just prevents two services from listening on the same port since then you wouldn't have any control over which service actually got the connection. There's some other interesting stuff in that llb, as well.

And if you get something useful, please post it! I'm always learning from the code available here on LAVA.

Mark

[NeilA]

I have had a bit of success creating a SOAP server in LabVIEW that works fine with a single method. Hoorah I thought. I have copied the SOAP messaging by generating the soap encoded XML and TCP headers to post I also watch for the incoming in the server. However, I then tried my server with the C# client my colleague wrote (rather than one I made in LabVIEW). Here is where it all went wrong! I discovered at this point that my colleagues implementation requires WSDL and possibly other things to validate communication or something. The client software is actually an interface simulator that was generated for another company to test their SOAP service comms with ours. Therefore I know the interface works, however, they are using TCL to code there system and java to provide the SOAP server/client. I have read a lot about proxies and WSDL generation etc. and I think this is what I need. I spent some time trying to point the C# client at a WSDL that had already been created I just changed the server info in the WSDL which did not appear to work.

I am not sure what is happening in the client code as my colleague is not here at the moment. But I imagine the implementation is a standard C# thing which means I need to have a WSDL of sorts and may be a proxy. I have read of java SOAP implementations using the wsdl.exe tool to create a proxy for the client but my knowledge at this stage is slim.

Does any one here have any suggestions as to what I could try?

Many Thanks.

[NeilA]

I have had a further chat with my colleague and it appears that the client looks at the service to see that it exists. However I am not sure how to expose my application as a website URL. Im wondering if I could just put a case in to my server that responds to a HTTP GET at the URL I want to use. If I look at the localhost of my service using the web browser I get an error back because it does not deal with a GET command properly which may be why I am having issues.

I have also been if it is possible to do the required detting up using .NET or activeX to try and mimic the c# server by setting up http binding etc to my VI. Is there any one who could shed any light on this? I saw advice on another thread to use net.tcp.dll in activex.

Any help here would be great!