No, WebServices are not about objects. This is the point I'm trying to make.
The Wizards and VS.NET are trying to hide the details form you (which is
good in some scenarios), but you still must understand at least the concepts
and limitations of the underlying technology. Web Services are about passing
XML messages. The fact that in your C# code the XML message is presented
as an object is simply an artifact of the tool/framework you're using.
So... in a sense, yes you can send back objects, but realize those objects
are just being mapped onto XML. And then the XML is sent back to the client.
The XML is all they end up with (and it might get mapped into some programming
language specific construct on their side, but that's their business). So,
objects in WebServices in .NET are just there to map the state of the object
onto XML and the XML onto the state of an object. There are many things you
can build with objects that don't map correctly onto XML as used by Web Services.
So, yes, your toolkit (VS.NET) allows you to hand around object, but I'd
suggest making simple objects to hold this data and be aware that that's
the only purpose of the object. Here's a short sample (I hope the formatting
isn't messed up... sorry if it is):
public class Stock
{
public int Shares;
public string Ticker;
}
public class Portfolio
{
public double TotalValue;
public Stock[] Stocks;
}
public class StockQuote : System.Web.Services.WebService
{
[WebMethod]
public Portfolio GetPortfolio(string cutomer)
{
Portfolio p = new Portfolio();
p.TotalValue = 3456;
p.Stocks = new Stock[1];
p.Stocks[0] = new Stock();
p.Stocks[0].Shares = 400;
p.Stocks[0].Ticker = "WCOM";
return p;
}
[ WebMethod ]
public double GetQuote(string ticker)
{
switch (ticker)
{
case "MSFT": return 67.89;
case "IBM": return 43.12;
case "DELL": return 12.34;
case "WCOM": return 0.000000645;
default: return 0;
}
}
}
So this example uses objects, but their purpose in life (as parameters and
return values to/from the web service) is just to model the underlying XML.
Like I said, this stuff isn't easy but once you understand where the framework
relates to the real underlying technology then it becomes easier... HTH
Hello Brock, I don't know if I've understanding correctly your answer.
You are telling me that I can return any object from a WebService?
So in my example I can do this?
[WebService(Namespace="WebServiceA")]
public class WSA: System.Web.Services.WebService
{
[WebMethod(EnableSession=true)]
public CL1 WM1()
{
CL1 test;
test.SomeMethod();
}
[WebMethod(EnableSession=true)]
public string WM2(CL1 LocalTest)
{
return(LocalTest.SomeValue);
}
}
public class CL1
{
...
}
And if I can, how tha caller that doesn't know the object CL1 can send
this parameter?
Thank you.
Alessandro Benedetti
So that's fine. I don't see what the problem is then? Every request
in creates a new instance of the WSA class. This protocol is not
stateful. That's why you're going to have to build in your own
correlation mechanism as I mentioned before. This stuff isn't easy --
don't let the VS.NET wizards fool you.
Also, I'd beware of using things like Session, as that relies upon an
out of band contract of using cookies from the client. The web
service specs don't incorporate these like browsers do. If you do use
Sessions/cookies, then what's a java client going to do? What about a
perl script client? Where in the WSDL does it to say use cookies? If
you have to explain to them outside of your WSDL file that cookies
are required on their end, then you're no longer really doing web
services... at least in the spirt of the web service specs. You've
just built your own XML protocol that sorta looks like SOAP....
