• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Webservice - General question regarding cross-compatibility

b4u

Golden Member
Hi,

I have a basic question about Webservices, and the way they work their compatibility.

Let's say I create a webservice that receives 2 parameters and returns an object. Something like (with the looks of java):

<pre>
public SumObj doSum(Integer value1, int value2) {
...
}
</pre>

Parameters are as specified, one Wrapper for the integer value1, and a primitive type for an integer.

Now for the return object, let's say something like:

<pre>
public class SumObj {
private Integer value1;
private int value2;
private Integer sum;
//Constructor
public Integer getSum() {
return sum;
}
//proper acessors for the properties
}
</pre>


1# First Question

Now all this trouble typing this message to ask a basic question:

What is the philosophy around returning and manipulating objects between different programing languages?

I mean, I can program my core app in Java, and create a Webservice with Axis, so when another Java app accesses it, it will receive a SOAP message with the structure of my SumObj. Also, I can create a new Integer object and pass as an argument, or even any other object instance.

Now if someone has an app written in .NET, they will have to receive a SumObj object as return ... so how does it accomplishes this cross-language compatibility? Or what do I need to do in order to make sure it happens?

If we were talking about passing primitive types around, then it would be understandable that each language would have to implement a set of common interpreters for those types, but we are talking about receiving and/or sending complete custom-made objects ... and some may even have some methods that do some processing?

2# Second Question

Imagine that I have a webservice that receives an object. That object structure is created by me.

The client app don't know about the structure, so I can see two options that would allow my clients to instantiate and pass me the value:

a. Provide the code so they can instantiate objects - don't think that it would work well

b. Provide a webservice method that would instantiate and return to the client the new object, so they can manipulate and send as parameter for another webservice call

Am I seeing it correctly?


Thanks 🙂
 
SOAP always passes XML and uses a WSDL to show the structure of the parameters and returns.

You aren't really passing objects you're passing structures built up from primitive types and serialized as XML.

You don't pass a person object you pass

< person >
< lastname > Smith < /lastname >
< firstname > John < /firstname >
< /person >

And the other side of the connection can send or read this as:

C/C++
struct person { string lastname ; string firstname ; }
sendPerson ( person& p ) ; // transmit person to a server
bool getPerson( person* p ) ; // get person from server, caller must free struct/object allocated by SOAP framework


For another language like Basic or Fortran the SOAP call might pass a set of variables instead of one struct:
SendPerson( String LastName, String FirstName )


#1/#2:

Both the client and server usually must be written in advance to know what kind of message / XML is going to be passed between them, unless its some wacky dynamic language like Lisp.

In SOAP, the Web Service Description Language (WSDL) defines the API / messages just like an .h file defines functions in C++.


It might help to think of SOAP as defining a disk file format. The client writes to an XML file with a well-definied format (specified by the WSDL). The server reads the XML file, then writes its own XML file as a response.

SOAP toolkits make this a little easier by taking the WSDL and generating the file read/write code for you. It's still up to you to write the code on top of that, that makes a write happen and does something with the response.
 
Back
Top