Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-04

Web Service Toolkit For FPC & Lazarus

10 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Inoussa OUEDRAOGO

Hi.
My congratulations to the FPC team and Lazarus team. I'am working on this toolkit, to add Web Service support to FPC and Lazarus. My aim is to merge it with the FCL (LCL). The attached archive contains all the source code and a documentation file ( OpenDocument format, I use OpenOffice 2.0 to write it ). What do you think about it?

Overview >>
"Web Service Toolkit for FPC & Lazarus" is a web services package for FPC and Lazarus; "Web Service Toolkit" is meant to ease web services consumption by FPC and Lazarus users.
"Web Service Toolkit" is made of two parts, a command line tool "ws_helper" and a collection of support units. Given an interface definition file( describing à web service ), "ws_helper" will create a FPC unit containing a proxy implementing that interface. At runtime when a call targeting the web service is issued, the proxy's role is to :

(a)marshall the call paramaters,
(b)make the call to the target web service,
(c)receive the call return and unmarshall output parameters to the caller.

Behind the scene, the proxy will take care of the SOAP plumbing details.

Reply by email

Vincent Snijders
to Inoussa OUEDRAOGO
Inoussa OUEDRAOGO wrote 7 lines
Hi. My congratulations to the FPC team and Lazarus team. I'am working on this toolkit, to add Web Service support to FPC and Lazarus. My aim is to merge it with the FCL (LCL). The attached archive contains all the source code and a documentation file ( OpenDocument format, I use OpenOffice 2.0 to write it ). What do you think about it?

I have no idea, if this is going to be added to the FCL, (that is more appropiate than the LCL), but I do think it is a good idea to put this package on the Lazarus Code and Components Repository. Some people might try and test it. If you are interested in create a new entry for it on http://wiki.lazarus.freepascal.org/index.php/Components_and_Code_examples and create a similar wiki pages as for the other downloads.

Show quoted text 17 lines
Overview >> "Web Service Toolkit for FPC & Lazarus" is a web services package for FPC and Lazarus; "Web Service Toolkit" is meant to ease web services consumption by FPC and Lazarus users. "Web Service Toolkit" is made of two parts, a command line tool "ws_helper" and a collection of support units. Given an interface definition file( describing à web service ), "ws_helper" will create a FPC unit containing a proxy implementing that interface. At runtime when a call targeting the web service is issued, the proxy's role is to : (a)marshall the call paramaters, (b)make the call to the target web service, (c)receive the call return and unmarshall output parameters to the caller. Behind the scene, the proxy will take care of the SOAP plumbing details.

Does it use the xmlrpc unit from the FCL
(http://svn.freepascal.org/svn/fpc/trunk/fcl/net/)?

Does it overlap regarding functionality?

Vincent.

Reply by email

Inoussa OUEDRAOGO
to Vincent Snijders
Show quoted text 6 lines
I have no idea, if this is going to be added to the FCL, (that is more appropiate than the LCL), but I do think it is a good idea to put this package on the Lazarus Code and Components Repository. Some people might try and test it. If you are interested in create a new entry for it on http://wiki.lazarus.freepascal.org/index.php/Components_and_Code_examples and create a similar wiki pages as for the other downloads.

I will do so

Reply by email

Inoussa OUEDRAOGO
to Inoussa OUEDRAOGO
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.

Reply by email

Vincent Snijders
to Inoussa OUEDRAOGO
Inoussa OUEDRAOGO wrote 5 lines
> 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.

Unfortuanately, I don't have openoffice installed on my windows 2k computer.

Vincent.

Reply by email

Michael Van Canneyt
to Inoussa OUEDRAOGO: This package have a different goal; The primary goal is to expose services as normal fpc…
Inoussa OUEDRAOGO wrote 5 lines
> 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.

Reply by email

Inoussa OUEDRAOGO
to Michael Van Canneyt: It is interesting to see this, as it is complementary to the fpRPC mechanism. Before I…

2006/4/24, Michael Van Canneyt :

Show quoted text 49 lines
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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Michael, that is great! I'm glad too to discuss this with you.

Reply by email

Inoussa OUEDRAOGO
to Michael Van Canneyt: It is interesting to see this, as it is complementary to the fpRPC mechanism. Before I…

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 :

Show quoted text 49 lines
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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email