URL of SOAP Data Module
Jean-Marie Babet
(This message is for Bob and others who participated on last month's thread
regarding the URL to use in TSoapConnection)
I seem to remember that the conclusion was that sometimes one needs to
specify the interface in addition to just the baseServer + /soap.
I'd like to better understand the scenario under which this happened because
I'd like to keep things like the documentation specifies - i.e. only
baseServer + /soap. Maybe I should explain why:
We're thinking of moving away from IAppServer for the TSoapConnection <->
TSoapDataModule. The two main reasons for such a move would be
#1 IAppServer is 'safecall' and not all environments support the safecall
calling convention (namely C++ :)
#2 [De]Serializing OleVariants is challenging because (unless we also send
the varType also) it's not easy to make sure the OleVariant is reacreated
correctly on the other end. In other words, when an integer comes down the
wire, and the matching native type is an OleVariant, it's not clear whether
to store the integer directly in the variant or to store the integer as the
single element of a variant holding a SafeArray of integers, etc. etc..
I'll be happy to expand on the issues (the ones above and others) that are
prompting me to ensure that no one relies on IAppServer for the SOAP portion
of Data Modules. This means that I'd like to make sure that baseServer +
/soap is all that's set in TSoapConnection.
Upon inspection of the code, I've found cases where the URL might have
required /soap/IAppServer or /soap/IMyDMInterface. One such case would beif
the Application Namespace prefix was defined. I'd like to make sure that
we've found them all such cases, fix them and don't have any remaining
issues.
If you have one such setup where simply specifying baseServer + /soap does
not work, please let me know. I'd like to find out more.
Thank you,
Bruneau.
Deepak Shenoy
> specify the interface in addition to just the baseServer + /soap.
>
> I'd like to better understand the scenario under which this happened
because
> I'd like to keep things like the documentation specifies - i.e. only
> baseServer + /soap.
Would you restrict this to /soap only (i.e disallow using the interface
after the /soap)? What if the soap datamodule had functions it needed to
expose directly (like you would using a Midas server, by adding functions to
your TLB and therefore your TRemoteDataModule descendant)
> #2 [De]Serializing OleVariants is challenging because (unless we also send
> the varType also) it's not easy to make sure the OleVariant is reacreated
> correctly on the other end. In other words, when an integer comes down the
> wire, and the matching native type is an OleVariant, it's not clear
whether
> to store the integer directly in the variant or to store the integer as
the
> single element of a variant holding a SafeArray of integers, etc. etc..
I agree - It makes writing a non Delphi client all that more difficult.
> Upon inspection of the code, I've found cases where the URL might have
> required /soap/IAppServer or /soap/IMyDMInterface. One such case would
beif
> the Application Namespace prefix was defined. I'd like to make sure that
> we've found them all such cases, fix them and don't have any remaining
> issues.
I'm not sure if I can recreate this but I would like to be able to call a
soap server function using a (TSoapConnection.[property which replaces
appserver but gives me access to the server as a httprio] as
IMyInterface).FunctionName ....
I'm not sure if it can be doen right now, let me give it a shot.
Also, how about multiple Soap Datamodules on the server? Which one would be
the default?
Other than this I don't see why we would need IMyDMInterface or IAppServer
suffixed - /soap should suffice.
--
Deepak Shenoy
Agni Software
http://www.agnisoft.com
Bob Swart
> I'll be happy to expand on the issues (the ones above and others) that are
> prompting me to ensure that no one relies on IAppServer for the SOAP portion
> of Data Modules. This means that I'd like to make sure that baseServer +
> /soap is all that's set in TSoapConnection.
But what about multiple soap data modules? The way I "solved" the issue, by
explicitly listing the IMySoapDataMod interface, at least made sure I should
be able to have multiple Soap Data Modules (something I haven't tried, yet,
but will try next week for my next column).
If I only pass /soap, will I be able to have multiple remote (SOAP) data
modules? Or should I use a TSharedConnection component and define one as
being the master (which one? the first one?). Just asking...
> Upon inspection of the code, I've found cases where the URL might have
> required /soap/IAppServer or /soap/IMyDMInterface.
Just today I found a case where it was *not* required: a plain Kylix 2
Enterprise (trial) SOAP server with a Delphi 6 Enterprise SOAP client. It
worked with IAppServer and with IMySoapDataMod, but also - to my big surprise
- with just /soap (it was on my laptop using Linux on VMWare as "guest" and
Win2K as "host", so I need to look at this further). I was sure I tested all
combinations, but perhaps I was (un)lucky today ;-)
> If you have one such setup where simply specifying baseServer + /soap does
> not work, please let me know. I'd like to find out more.
I will send you my non-working (/soap) scenarios later this weekend. First I
need to finish some work on the "session hopping" code (which also works in
Kylix!).
> Bruneau.
Groetjes,
Bob Swart (aka Dr.Bob - www.DrBob42.com)
--
drs. Robert E. (Bob) Swart - Consultant, Delphi Trainer & Author
UK-BUG Borland User Group Member & Borland UK Connections Member
Jean-Marie Babet
Thanks for the replies.
> But what about multiple soap data modules? The way I "solved" the issue,
by
> explicitly listing the IMySoapDataMod interface, at least made sure I
should
> be able to have multiple Soap Data Modules
The issue here is that TSoapConnection only knows about IAppServer. IOW the
TSoapConnection hardcodes its HTTPRIO to request IAppServer (see
SoapConn.pas). Which IAppServer you get will depends on two things:
1. Delphi servers dispatch SOAP requests primarily by SOAPActions. The
SOAPAction of IAppServer is preset (i.e. using the default namespaces [which
in turn defaults to a name derived from the unit name:
'urn:Midas-IAppServer'] ); this means that the TSoapConnection calls will be
dispatched directly to the IAppServer of your Service - even if you have
other interfaces [i.e. Data Modules] that derive from IAppServer.
2. If the SOAPAction above fails, then the dispatcher will use the path. So,
in that case using baseServer/soap/IMyDataModule will get you to the
IAppServer in IMyDataModule. But TSoapConnection will only utilize the
IAppServer portion of IMyDataModule. IOW, none of the additional methods
you've added to IMyDataModule will be accessible from that connection.
So now we have two problems:
A. If you have multiple DataModules and TSoapConnection asks for IAppServer
which one will the client get? Well, let's take scenario #1 above (most
common): It will get the IAppServer implementation. So now the question is
which one of my DataModules will be picked as *the* implementor of
IAppServer: the answer to that is the *last* one registered. All
TSoapDataModules implement IMyDataModule and IAppServer. i.e.:
TMyDataModule = class(TSoapDataModule, IMyDataModule,
IAppServer)
So registry will see this and take the last one as the one who's the
implementor of IAppServer.
That's not very predictable.
B. The other problem is let's say we fail to dispatch via SOAPAction (either
because you registered IAppServer first and you gave an explicit namespace
or because you redifined AppNamespacePrefix)... now we dispatch by path but
that's a problem since you'd be relying on something that is fixed [i.e.
redefining 'AppNamespacePrefix' gets your application a different namespace
for IAppServer than the one with which TSoapConnection was built].
And the issues mentioned above don't even touch on the other bugs related to
the problem with the lack of symetry when serializing OleVariants. [BTW, for
the OleVariant serialization, we could pass in an attribute on the node that
tells us the varType; so we can reconstruct the original OleVariant on the
other hand; so this is a minor point in this issue but I'm mentioning it
because it's part of our decision-making]; or the fact that you still
cannot get to the additional methods of your DataModule because
TSoapConnection only asks/knows about IAppServer.
Sure you could say that I'll access the additional functionality of my
DataModule via a separate HTTPRIO which I'll set to /soap/IMyDataModule and
tie that to my TSoapConnection in a unified way. But doing is that dangerous
for as we saw above, you can't predict which IAppServer implementation your
TSoapConnection received, so your RIO and TSoapConnection could be talking
to totally different DataModules
Thanks again for the info. I look forward to anything you have that will
allow me to better understand the issues at hand. When this solidifies I'll
send some info. on the approach we're taking. My goal is to remove all these
unpredictable behaviours.
I'm very open to suggestions regarding these. I understand the need to get
to the additional methods of your DataModule and the need for predictability
as to which implementation you get and integrity of serialized data.
Suggestions/comments/etc are welcome.
Regards,
Bruneau.
"Bob Swart" <dr...@chello.nl> wrote in message
news:3BEC0B64...@chello.nl...
Bob Swart
>> But what about multiple soap data modules? The way I "solved" the issue,
>> by explicitly listing the IMySoapDataMod interface, at least made sure I
>> should be able to have multiple Soap Data Modules
>
> The issue here is that TSoapConnection only knows about IAppServer.
> IOW the TSoapConnection hardcodes its HTTPRIO to request IAppServer
> (see SoapConn.pas). Which IAppServer you get will depends on two things:
>
> 1. Delphi servers dispatch SOAP requests primarily by SOAPActions. The
> SOAPAction of IAppServer is preset
Yes, that's the IAppServer published interface that I see.
> 2. If the SOAPAction above fails, then the dispatcher will use the path.
I see. But if I specify the path (the /SoapDataMod42 after the /soap), then
surely it will only try the interface that I have specified, and not the
default IAppServer, right?
> But TSoapConnection will only utilize the IAppServer portion
> of IMyDataModule.
Hmm, I didn't know that (nor did I try to add more methods). Bummer...
> A. If you have multiple DataModules and TSoapConnection asks
> for IAppServer which one will the client get? Well, let's take
> scenario #1 above (most common): It will get the IAppServer
? implementation. So now the question is which one of my DataModules
> will be picked as *the* implementor of IAppServer: the answer to
> that is the *last* one registered.
Aha, the last one. That's good to know. But I would love to be able to have a
choice.
I wouldn't mind if the /soap would be the preferred solution, but please
don't "kill" the other way where you can explicitly add the ISoapDataMod42
interface to it (if you keep both working, with the "plain" /soap as default
or "best" way, then at least I can use the explicit addressing, and use
multiple remote (soap) data modules - even the one that got registered first
;-)
> B. The other problem is let's say we fail to dispatch via SOAPAction
> (either because you registered IAppServer first and you gave an
> explicit namespace or because you redifined AppNamespacePrefix)
You're losing me here... How would I be able to redefine AppNamespacePrefix?
> ... now we dispatch by path but that's a problem since you'd be
> relying on something that is fixed [i.e. redefining 'AppNamespacePrefix'
> gets your application a different namespace for IAppServer than
> the one with which TSoapConnection was built].
>
> And the issues mentioned above don't even touch on the other bugs
> related to the problem with the lack of symetry when serializing
> OleVariants.
You've lost me now. Sorry...
> still cannot get to the additional methods of your DataModule because
> TSoapConnection only asks/knows about IAppServer.
That part I understand ;-)
> Sure you could say that I'll access the additional functionality of
> my DataModule via a separate HTTPRIO which I'll set to
> /soap/IMyDataModule and tie that to my TSoapConnection in a unified
> way. But doing is that dangerous for as we saw above, you can't
> predict which IAppServer implementation your TSoapConnection
> received, so your RIO and TSoapConnection could be talking
> to totally different DataModules
I don't understand this. If I explicitly specify /soap/IMyDataModule, then
doesn't that ensure that I get the TMyDataModule implementation of the
IAppServer interface? That's what I'm asking for, right?
> Thanks again for the info. I look forward to anything you have that
> will allow me to better understand the issues at hand.
I've just put a quick test together. Kylix 2 Enterprise (trial edition - 42
days left) seems to produce SOAP Server applications that can "export" their
DataSetProviders without a problem if you only access them using /soap (both
from Delphi 6 and Kylix 2 itself). I have a test SoapServer42 on a Linux
machine (URL available on request) that tests just fine.
Using Delphi 6.01 (and Delphi 6.0 for that matter), I can only produce SOAP
Servers that will NOT work when only providing /soap in the URL of a
SoapConnection component (either from Delphi 6 or Kylix 2 SOAP clients). For
a Delphi 6 SOAP Server, I need to add the /ISoapDataMod42 (this is what
triggered me to the article at http://www.drbob42.com/soap42.htm in the first
place - somehow I "verified" that Kylix 2 Enterprise had the same problem,
but the most recent Trial Edition doesn't have this problem! So Kylix 2 is
"better" than Delphi 6.01 in that matter it seems... <grin>
BTW, I also have the Delphi 6 SoapServer42.exe available to test (hosted on a
Win2K web server - just like the Kylix edition on a Linux web server).
Oh yeah, before I forget: if you have a URL that ends on /soap and you set
"Connected" to True, then you can't just add the /ISoapDataMod42 to it. It
won't "reconnect" until you set Connected to False and back to True again.
Even if Connected doesn't seem to do anything special (I'm able to set it to
"True" if the URL only contains something like http://server/whatever - a
warning that the URL is wrong or invalid would be welcome ;-)
> When this solidifies I'll send some info. on the approach we're
> taking. My goal is to remove all these unpredictable behaviours.
I agree. The most unpredictable, however, is the fact that you claim that
it's not certain which implementation of IAppServer I would get when I call
the /soap/ISoapDataMod42 interface in the URL property of the SoapConnection.
I'm hoping that I still get the TSoapDataMod42 implementation, which would
solve most of the issues (for me at last ;-)
Jean-Marie Babet
> Would you restrict this to /soap only (i.e disallow using the interface
> after the /soap)? What if the soap datamodule had functions it needed to
> expose directly (like you would using a Midas server, by adding functions
to
> your TLB and therefore your TRemoteDataModule descendant)
I would not restrict this to /soap only. However, the issue is that
currently the path is rarely used for dispatching. The SOAPAction takes
precedence. What that means is that baseServer/soap/IMyDataModule could
easily get you to baseServer/soap/SomethingElse since SOAPAction dispatching
is hardcoded to that of IAppServer. IOW, it depends up whether the
implementation or IMyDataModule or that of SomethingElse was registered
last.
> I'm not sure if I can recreate this but I would like to be able to call a
> soap server function using a (TSoapConnection.[property which replaces
> appserver but gives me access to the server as a httprio] as
> IMyInterface).FunctionName ....
I'm afraid to say that we'll have to wait for Generic support for this. IOW,
the 'FAppServer' member of TSoapConnection is an IAppServer. To allow the
type to change would either require you to change the code, create a derived
TSoapConnection or for me to lobby for more weight behind Generic support
(something that comes up every once in a while but the opposition is very
well funded:)
Regards,
Bruneau.
Deepak Shenoy
the
> TSoapConnection hardcodes its HTTPRIO to request IAppServer (see
> SoapConn.pas).
I see where you're going. Can we perhaps change this to ask for a specific
interface (for which we will need to "import" the WSDL first, get the
interfaces into the project) instead of IAppServer? Instead of querying for
appserver directly TSoapConnection can use a proxy to get the IAppServer -
the proxy can be configured (either through events or through a register
function) to get any other interface, and relay the IAppServer methods to
the TSoapConnection. This way TSoapConnection only talks to this proxy and
never to the soap server direct, which really gives you the added
functionality of implementing different transports - right now you are
limited to THttpRio.
> 2. If the SOAPAction above fails, then the dispatcher will use the path.
So,
> in that case using baseServer/soap/IMyDataModule will get you to the
> IAppServer in IMyDataModule. But TSoapConnection will only utilize the
> IAppServer portion of IMyDataModule. IOW, none of the additional methods
> you've added to IMyDataModule will be accessible from that connection.
Which is where this proxy comes in. If you want methods you've added manuall
to the server, you must first import the WSDL and make sure whatever comes
in shows that your interface is derived from IAppServer (or duplicates its
methods - though I don't like that too much) Now this proxy class will by
default query for IAppServer, but if you "register" an interface using some
event on the proxy class, or by a register procedure (which would take the
Proxy instance AND the name of the interface) this proxy class will query
for this other interface instead. A property can give you direct access to
the interface, which has been imported, so you can do some typecasting and
then do your call...I don't know if this makes any sense at all...
> So registry will see this and take the last one as the one who's the
> implementor of IAppServer.
>
> That's not very predictable.
One way to get around this is to either use specific "soapaction" header
(again this restricts you to HTTP) or, you could use the SOAP:Header. You
might be able to reuse some of the currently defined attributes to your
needs...so that when an appserver is requested, and multiple IAppservers are
found in the register, we must MAP the Soap Header (or soapaction) to the
actual interface at the server. If you ensure that after /soap the actual
interface name is always present (for multiple DMs at the server) you can
make sure that the proxy class (or the TSoapConnection itself) sets whatever
is required - either the soapaction or the soap header.
> B. The other problem is let's say we fail to dispatch via SOAPAction
(either
> because you registered IAppServer first and you gave an explicit namespace
> or because you redifined AppNamespacePrefix)... now we dispatch by path
but
> that's a problem since you'd be relying on something that is fixed [i.e.
> redefining 'AppNamespacePrefix' gets your application a different
namespace
> for IAppServer than the one with which TSoapConnection was built].
This would actually ruin things...maybe you should simply disallow changing
appnamespaceprefix unless done at both ends :)
> And the issues mentioned above don't even touch on the other bugs related
to
> the problem with the lack of symetry when serializing OleVariants. [BTW,
for
> the OleVariant serialization, we could pass in an attribute on the node
that
> tells us the varType; so we can reconstruct the original OleVariant on the
> other hand; so this is a minor point in this issue but I'm mentioning it
> because it's part of our decision-making];
This is actually quite interesting. How about variants that are arrays of
Variants etc?
> Sure you could say that I'll access the additional functionality of my
> DataModule via a separate HTTPRIO which I'll set to /soap/IMyDataModule
and
> tie that to my TSoapConnection in a unified way. But doing is that
dangerous
> for as we saw above, you can't predict which IAppServer implementation
your
> TSoapConnection received, so your RIO and TSoapConnection could be talking
> to totally different DataModules
Apart from that you might be accessing different server instances of the
same Datamodule! A new THTTPRio will query for something on the server, and
it's possible that the server creates a new datamodule instance to
give to you. Now your new functionality you added to the datamodule might
involve say setting of certain SQL or some property on the datasets...but if
you access through a ClientDataset, your TSOapConnection is using a
different instance of the Datamodule, which would not have this SQL set,
which therefore becomes an issue...But I think you might want to avoid this
kind of thing anyhow given that you want to make things stateless.
Thanks,
John Kaster (Borland)
> I'm very open to suggestions regarding these. I understand the need to get
> to the additional methods of your DataModule and the need for predictability
> as to which implementation you get and integrity of serialized data.
> Suggestions/comments/etc are welcome.
I look forward to chatting with you on this when I'm back in the office.
Definitely a thorny issue. I hope we end up with the rose without
getting poked too many times.
--
John Kaster, Borland Developer Relations, http://community.borland.com
$1280/$50K: Thanks to my donors!
http://homepages.borland.com/jkaster/tnt/thanks.html
Buy Kylix! http://www.borland.com/kylix * Got source?
http://codecentral.borland.com
The #1 Java IDE: http://www.borland.com/jbuilder
Jean-Marie Babet
> I see. But if I specify the path (the /SoapDataMod42 after the /soap),
then
> surely it will only try the interface that I have specified, and not the
> default IAppServer, right?
I'm afraid to say but no it won't: The default it to dispatch via SOAPAction
first. The HTTPRIO will send the SOAPAction of IAppServer. The way to get
path dispatching (with the current implementation) is to make SOAPAction
dispatching fail.
> Aha, the last one. That's good to know. But I would love to be able to
have a
> choice.
Yes, I've changed it so you have control. I'll explain the approach later
(after it's settled).
> You're losing me here... How would I be able to redefine
AppNamespacePrefix?
By setting the 'AppNameSpacePrefix' variable to something. The logic
otherwise uses 'urn:UnitName-InterfaceName' which is not very unique.
> > And the issues mentioned above don't even touch on the other bugs
> > related to the problem with the lack of symmetry when serializing
> > OleVariants.
>
> You've lost me now. Sorry...
IAppServer passes OleVariant [vestige of it COM/Automation legacy]. The SOAP
code that [de]serializes OleVariants is heavily Midas-biased. But even then,
it's impossible to reconstruct an OleVariant correctly because we don't
serialize the original varType. Also, Variants/OleVariant is the way we
support XML/SOAP 'anyType' and 'anySimpleType'. The Midas bias of our
serialization routine hurts our interop. in cases involving 'anyType' and
'anySimpleType'.
> I don't understand this. If I explicitly specify /soap/IMyDataModule, then
> doesn't that ensure that I get the TMyDataModule implementation of the
> IAppServer interface? That's what I'm asking for, right?
Unfortunately not! Even if you set /soap/IMyDataModule, the
TSoapConnection's RIO will still send the SOAPAction of IAppServer which
means that you'll get the implementation of IAppServer. If the
implementation of IMyDataModule was the last one registered, you'll get that
but otherwise.... :(
> So Kylix 2 is
> "better" than Delphi 6.01 in that matter it seems... <grin>
I'd hope so - it was shipped after Delphi6 Update#1 went out and we're
almost single source :)
> It
> won't "reconnect" until you set Connected to False and back to True again
This has been fixed. Actually it's fixed in Kylix.
> I'm hoping that I still get the TSoapDataMod42 implementation, which would
> solve most of the issues (for me at last ;-)
Yes, the fix will allow you to know exactly which implementation you're
getting. Thanks for the feedback.
Regards,
Bruneau.
Jean-Marie Babet
> Can we perhaps change this .. way TSoapConnection only talks to this proxy
and
> never to the soap server direct...
That's the prototype I have right now... Prescience across time zones :)
> A property can give you direct access to
> the interface, which has been imported, so you can do some typecasting and
> then do your call...I don't know if this makes any sense at all...
Yes, makes total sense!
> we must MAP the Soap Header (or soapaction) to the
> actual interface at the server. If you ensure that after /soap the actual
> interface name is always present (for multiple DMs at the server) you can
> make sure that the proxy class (or the TSoapConnection itself) sets
whatever
> is required - either the soapaction or the soap header.
Good suggestion. I've been thinking of allowing more control on the
dispatching. Since SOAP does not have the luxury of COM's CoClass [where you
can say I want the implementation of this interface from *that* CoClass],
allowing control at both the Server and Client end would help a lot.
> This would actually ruin things...maybe you should simply disallow
changing
> appnamespaceprefix unless done at both ends :)
I'm more of the opinion that we should have provided explicit Namespaces for
all Borland types. IOW, instead of having:
InvRegistry.RegisterInterface(TypeInfo(IAppServer));
we should have done:
InvRegistry.RegisterInterface(TypeInfo(IAppServer),
sDelphiTypeNamespace);
The 'sDelphiTypeNamespace' is already declared in SoapConst.pas. We had good
intentions :(
Now, for backward compatibility, I've fixed the issue with:
InvRegistry.RegisterInterface(TypeInfo(IAppServer),
'urn:Midas-IAppServer');
> This is actually quite interesting. How about variants that are arrays of
> Variants etc?
You've got it... unless we pass the vartype(s) [as an attribute of the
node], we'd need some odyllic heuristics to maintain symmetry in
serialization and deserialization :)
> Now your new functionality you added to the datamodule might
> involve say setting of certain SQL or some property on the datasets...but
if
> you access through a ClientDataset, your TSOapConnection is using a
> different instance of the Datamodule, which would not have this SQL set,
> which therefore becomes an issue...
Good point further stressing the danger of the current situation when one
has multiple DM or needs access to additional methods.
Regards,
Bruneau.
Deepak Shenoy
> > Can we perhaps change this .. way TSoapConnection only talks to this
proxy
> and
> > never to the soap server direct...
>
> That's the prototype I have right now... Prescience across time zones :)
Cool! I was thinking a bit more, and maybe you could allow assignment of
this property in the object inspector, so that we could write other
components that would do the job. I mean if you called this a property of
TSoapConnection, say "CallProxy" that needs a TCallProxy [note: I suck at
names], and by default it uses an internal instance called "THTTPCallProxy"
but we coudl change that to a component we could write. Something like the
WSDLView property on THTTPRio (which I have never needed to write a
compoennt for but who knows)
Also you could use Interface Component references instead of mapping to a
Delphi class type - anyhow TCallProxy will be an abstract thingy IMHO.
> > we must MAP the Soap Header (or soapaction) to the
> > actual interface at the server. If you ensure that after /soap the
actual
> > interface name is always present (for multiple DMs at the server) you
can
> > make sure that the proxy class (or the TSoapConnection itself) sets
> whatever
> > is required - either the soapaction or the soap header.
>
> Good suggestion. I've been thinking of allowing more control on the
> dispatching. Since SOAP does not have the luxury of COM's CoClass [where
you
> can say I want the implementation of this interface from *that* CoClass],
> allowing control at both the Server and Client end would help a lot.
Come to think of it we could use more control on the header tags
anyhow....all this talk about the actor attributes and all that make me feel
a bit queasy about no control :)
> I'm more of the opinion that we should have provided explicit Namespaces
for
> all Borland types. IOW, instead of having:
> InvRegistry.RegisterInterface(TypeInfo(IAppServer));
>
> we should have done:
> InvRegistry.RegisterInterface(TypeInfo(IAppServer),
> sDelphiTypeNamespace);
>
> The 'sDelphiTypeNamespace' is already declared in SoapConst.pas. We had
good
> intentions :(
hmm...btw, this defaulting to unit name thingy - why is that always done
when you register against a namespace of ''? I would sometimes LIKE my
namespace to be '' - i know it sounds crazy but you know how other soap
servers can send you the most inane packets sometimes...(take faults for
example)
> Now, for backward compatibility, I've fixed the issue with:
> InvRegistry.RegisterInterface(TypeInfo(IAppServer),
> 'urn:Midas-IAppServer');
Do you really need to worry about backward compatibility now? I think the
soap implementation is going to change enough over the next few months to
render all my projects (test projects) incompatible anyhow :)
> > This is actually quite interesting. How about variants that are arrays
of
> > Variants etc?
>
> You've got it... unless we pass the vartype(s) [as an attribute of the
> node], we'd need some odyllic heuristics to maintain symmetry in
> serialization and deserialization :)
Now I know why you want to avoid this...<g>
I'd love to see where this is going...my paper on Soap with Midas is
instantly going back to the drawing board :)
Thanks,
--
Bob Swart
To continue an old discussion, I've derived a new interface and class from a
Soap data module (interface called ISoapDataMod42 - derived from IAppServer)
and added a method GetInformation to it at the server side. Both to the
interface and implementation, and everything went fine. So far.
At the client side, I cannot use the SoapConnection component to get to the
ISoapDataMod42 interface, since it only returns a "real" IAppServer
interface.
So I needed a HTTPRIO component to point to the /wsdl/ISoapDataMod42 to get
my real ISoapDataMod42 interface. But before I could use it, I decided to use
the Web Services Importer to import the /wsdl/ISoapDataMod42 into an import
unit (useful for crossplatform development in K2 and D6 when you cannot
easily copy-and-paste the interface definition of ISoapDataMod42).
At first I was surprised when the generated import unit also contained the
six methods from IAppServer. But on second thought, that's obvious, since
ISoapDataMod42 is derived from IAppServer, so the "base" methods are also
included. As well as the new method that I added myself.
Unfortunately, the generated source code for the first two IAppServer methods
is wrong. They both end in something like ": Integer : Variant; stdcall;"
(i.e. the result type is Integer as well as Variant), which makes no sense to
me or the compiler. Below is the entire generated source code, which the
IAppServer methods in comments (it compiles and runs fine now).
Unit iDataMod;
interface
uses
Types, XSBuiltIns;
type
ISoapDataMod42 = interface(IInvokable)
['{DB2E16FC-386E-4B93-A102-3D9A60AC25F5}']
// function AS_ApplyUpdates(const ProviderName: WideString; const Delta:
Variant; const MaxErrors: Integer; var OwnerData: Variant): Integer:
Variant; stdcall;
// function AS_GetRecords(const ProviderName: WideString; const Count:
Integer; const Options: Integer; const CommandText: WideString; var Params:
Variant; var OwnerData: Variant): Integer: Variant; stdcall;
// function AS_DataRequest(const ProviderName: WideString; const Data:
Variant): Variant; stdcall;
// function AS_GetProviderNames: Variant; stdcall;
// function AS_GetParams(const ProviderName: WideString; var OwnerData:
Variant): Variant; stdcall;
// function AS_RowRequest(const ProviderName: WideString; const Row:
Variant; const RequestType: Integer; var OwnerData: Variant): Variant;
stdcall;
// procedure AS_Execute(const ProviderName: WideString; const CommandText:
WideString; var Params: Variant; var OwnerData: Variant); stdcall;
function GetInformation: WideString; stdcall;
end;
implementation
uses
InvokeRegistry;
initialization
InvRegistry.RegisterInterface(TypeInfo(ISoapDataMod42),
'urn:sDataMod-ISoapDataMod42', '');
end.
I guess what I'm trying to say is: the Web Services Importer doesn't import
the IAppServer interface correctly (for the first two methods AS_ApplyUpdates
and AS_GetRecords).
I'm using Delphi 6 Update Pack 1 applied (but no other fixes or tweaks ;-)
Jean-Marie Babet
Obviously the importer is confused by IAppServer. I'll take a look and relay
my findings. Thanks for the report.
More later....
Bruneau.