[fpc-devel] Web Service Toolkit For FPC & Lazarus

[Inoussa OUEDRAOGO]

Hi.

Michael, I agree with you for the separation of concerns.

The new design use :
  "TAbstractTransport" for the transport layer
           ( specialization could be HTTP, TCP, ...).
  "TAbstractFormater"  for the serialization of content
          ( specialization could be SOAP, XML-RPC, custom binary, ...)
  "TAbstractCallMaker" to make the call over the transport
          ( specialization could be SOAP handler, XML-RPC handler,
            custom binary handler, ...)

"TAbstractFormater" and "TAbstractCallMaker" has to be synchronized.

There are 2 registries :
  The first one to register transport
  The second for message handling.

The toolkit interface has been unified in one unit, which you'll find
has attached file.

Inoussa O.


2006/4/24, Michael Van Canneyt <michael at freepascal.org>:
>
>
> On Mon, 24 Apr 2006, Inoussa OUEDRAOGO wrote:
>
> >> Does it overlap regarding functionality?
> >
> > This package have a different goal; The primary goal is to expose
> > services as normal fpc interfaces by providing a proxy implementation
> > as Delphi does; please take a look at the doc file.
>
> It is interesting to see this, as it is complementary to the fpRPC
> mechanism.
>
> Before I would include it in the FCL, there is additional work:
>
> 1. Use a plug-in architecture for the transport layer.
>     Hardcoded transport using Indy is good for a first version, but
>     an RPC mechanism should be independent of the transport layer.
>
> 2. Use a messaging system which is not necessarily XML based.
>     XML introduces serious overhead.
>
> 3. The creation of SOAP services should be included as well.
>     (like xml-RPC)
>
> In my opinion, an RPC mechanism needs 3 parts:
>
> - Interface description and generation. You have this in one
>    direction, and fpRPC also has this in the other direction.
>
> - Message handling. Message can be XML, SOAP, binary, whatever.
>    XML is portable, but slow.
>
> - Transport handling. Transport can be HTTP (using Indy, Lcl, Synapse,
>    whatever) or Windows WM_COPY transport, local socket, named pipes,
>    shared memory: whatever. This is independent of the message.
>
> These 2 last parts are separate from each other and from the first part:
> it should be possible, at any stage, to replace one part with another.
>
> Your implementation definitely has the potential to do this. If you have
> ideas of how to achieve what I describe here, I'll be glad to discuss an
> implementation with you !
>
> Michael.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service_intf.pas.tar.gz
Type: application/x-gzip
Size: 2951 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20060428/d2e4db5c/attachment.bin>