SOAP/.NET Web service question on use of xsd:any or xsd:choice types

Hello,

I'd like to write a .NET WebService that performs the following
function:

The Service would have a WebMethod, implemented in .NET as
WebService-derived class with a method

[WebMethod]
xResult PerformCalculation(xInfo CalcParameters)

which takes a set of parameters passed in a struct xInfo & then works
out a result set & passes it back in a struct xResult

I would then implement a base class cCalculator that extracts the
information from the xInfo struct and populates the xResult struct with
the answers.


However, whilst the main guts of the calculation remains the same, I am
looking to support a range of different calculations by generating
subclasses of cCalculator to perform the calculations in slightly, as
yet undefined ways, i.e. a new set of classes cNew1Calculator,
cNew2Calculator etc derived from cCalculator.

What I want to be able to do is have the flexibility, in future, to use
these new cCalculator-derived classes, which cannot be totally specified
at this time.

The additional complication is that these new classes may require
additional parameters & result data specific to each new calculation.

From a native SOAP/XML message format I can see that such additional
parameters could be sent across the wire in an element, say <EXTENSION>
as follows:

<EXTENSION>
    <DERIVEDCALCULATIONTYPE>CalculationName2<\DERIVEDCALCULATIONTYPE>
    <NEWPARM1>VALUE1<\NEWPARM1>
    <NEWPARM2>VALUE2<\NEWPARM2>
<\EXTENSION>

where the <EXTENSION> element is defined on the Schema as having content
of type "xsd:any".
I could see that if the parameters were known in the content type
"xsd:choice" might be used, but this would constrain me too much.

The additional result elements could then be encoded & returned in a
similar way.


The questions I have are these:

1) If my client at the other end (possibly a non-MS SOAP platform) knows
what parameters to encode & send, is there anyway with the MS .NET SOAP
implementation that I can support such behavior?

2) If this is not possible, is it possible to support an "xsd:choice"
based solution? & if so, how?

In both cases how does this translate into the .NET class
implementation?

Is there a better way of doing it?

I'd like to fix & tie the client interface down now to avoid having to
add a new WebService or WebMethod on the Webservice for each new future
calculation type.


Regards,

John

-
***********************************************************************
John Dougrez-Lewis
***********************************************************************

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.