I don't want to come across as stupid by reiterating the question but
you are telling me that SOAP is nothing more than XML-RPC.
Yes, SOAP is the successor to XML-RPC, and like XML-RPC it returns
simple objects which are nothing more than a set of properties (no
methods).
That there
is a wall of functions (like a C style API) that return simple types
or structures
If by "simple types or structures" you mean objects with only
properties than you are correct.
and I still question this.
Which is fine, I'll try to explain as best I can.
I *believe* that with SOAP I
can return references to instance objects.
AFAIK, you cannot return references to server side objects through
the .NET 2.0 SOAP Web Services.
I believe I can *somehow*
(possibly with the use of a proxy or a stub) invoke functions on the
client, which is wrapped up in a SOAP request and translated to an
actual invocation and running of the object instances method on the
server side.
The only way to invoke functions is to call them through the web
service using a SOAP formatted request. There is no "magic"
translation that happens that gives the client the ability to invoke
methods on the object. If I confused you by talking about proxy
classes earlier than let me rephrase - proxy classes are just very
simple objects (properties only) that .NET creates for you to give you
compile time support. All that happens is that the framework reads the
WSDL, pulls out the property structure and does a simple code gen to
create the classes. You'll notice that you'll also lose any
functionality in the properties (such as validation code), they become
simple get..set.. pairs.
You are suggesting this is all that is possible:
Nope. I'm saying if you want to invoke functions on a web service you
must call them through the web service, not the objects served by the
web service.
Take a look at this simple, pseudocode, example on how to use a
service.
Here's the Web Service code:
////////////////
<WebMethod()_
Public Function GetProgrammerByBadgeId(badgeId as integer) As
Programmer
Return New Programmer(badgeId)
End Function
<WebMethod()_
Public Sub SaveProgrammer(programmer as Programmer)
'// We get the Programmer's methods back
programmer.Save()
End Sub
///////////////
And the code for the programmer class:
//////////////
Public Class Programmer
Public Sub New()
End Sub
Public Sub New(badgeId as Integer)
Me.New()
Me.BadgeId = badgeId
Me.Load()
End Sub
'// I'm too lazy to type these out, they are standard properties
Public Property BadgeId As Integer()
Public Property Name As String()
Public Property FavoriteLanguage As String()
Private Sub Load()
'// Load the object from the data access layer
DALC.Load(Me, badgeId)
End Sub
Private Sub Save()
'// Save the object through the data access layer
DALC.Save(Me)
End Sub
End Class
/////////////
This is the client side code:
///////////////
'// Instantiate a new web service
Using service As New ProgrammersService()
Dim programmer As ProgrammersService.Programmer =
service.GetProgrammerByBadgeId(999)
Console.WriteLine("The Programmer's Name is {0}", programmer.Name)
'// Prints "Seth Rowe"
Console.WriteLine("The Programmer's preferred language is {0}",
programmer.PreferredLanguage) '// Prints C#
'// Since C# isn't my favorite language, we need to update the
database
programmer.PreferredLanguage = "VB.NET"
'// That call only sets the client side property value, we now
need to save the object back
service.SaveProgrammer(programmer)
End Using
///////////////
Hopefully that makes a little more sense on how you should be using
web services. Basically you just get the object, do any client side
processing with the properties, and then save the object back to the
web service. If you're really, really stuck and can't figure out how
to implement this pattern with your CustomerService object, let me
know and I'll try to help.
Thanks,
Seth Rowe [MVP]
