Hi again!
Obviously client side should be much simpler then server.
On the other hand if the Apache XML-RPC is going to support different
transports it would be useful to provide way to buid roburst gateway
between transports (but it's only example of some active use).
That means plugin should have opportunity to build some connection pool
but client code wouldn't use it in normal situation.
So in usual case we use simple handler that takes URL and prologless
XML-RPC message which is called by the framework.
Such handler would be registered somehow in the framework
(framework could simply keep some Map(String proto, Factory transport))
Client just uses the fraework to execute request
Object response =
Framework.execute("proto://server/service", method, params)
alternatively execution proccess could go this way:
Transport t = Transport.forURL("proto://server/service");
Object response = t.execute(method, params);
Its important that Transport is part of framework and it gives back
transport registered for given protocol. It is assumed that, unless
other specified, client wants traditional HTTP XML-RPC so this is
what he gets by default (ie HTTP is the dafault handler).
I suppose for more active use client side can use the same design
as server side with little modification.
Ithink it's all ...for now
comments apreciated and required
Regards, rufio
