Prolog Web Services 0.2.1 released

[pic...@alice.it]

Sorry for opening another thread but this is to spur on those potentially interested.

New version complies with SWI Prolog HTTP library (http_dispatch).

It also includes PHP support (CGI). MySQL is not yet supported, but I tested several text-based-database CMS. It is not 100% fluent but basic things are there.

I added a couple of examples too.

The project has a small website at http://prologwebservices.com/ while sourceforge page is at http://sourceforge.net/projects/prolog-ws/

Thank you for your interest.

[ses]

Hi,

This looks like a really interesting project. There hasn't been much further development of Prolog web capabilities since SWAPP (http://www.swi-prolog.org/git/contrib/SWAPP.git) and some work I did for an XML based web service wrapper based on this (https://github.com/stewartsims/KMS-dev).

Neither project has seen much wide adoption, but I know of a few examples of companies that have 'rolled their own' wrappers for Prolog so I think there is interest in and practical usage for this.

I'm looking forward to seeing more on the pages about 'Internet Logic Programming' and maybe some more Prolog Server Pages examples.

[pic...@alice.it]

Thank you for your message. I am (slowly) working on it.

If you wish to contribute something you are welcome.

I have a couple of questions. Do you think WSDL+SOAP-based web services can be useful to Prolog? If yes, do you agree that Prolog would need the definition of Prolog-to-XML translation? Do you think it should be possible to avoid "typing Prolog" during this process?

[Jan Burse]

ses schrieb:

> I'm looking forward to seeing more on the pages about
> 'Internet Logic Programming' and maybe some more Prolog
> Server Pages examples.

You might also look at the deployment examples for Jekejeke
Prolog Runtime. A poor mans solution to web services is to use
the GET method and extract the parameters, and then generate
a response. This is for example done here:

http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/15_stdy/08_deploy/08_client/01_agent.html

http://www.jekejeke.ch/idatab/doclet/prod/en/docs/05_run/15_stdy/08_deploy/08_client/03_service.html

The deployment is such that the knowledge base is once loaded
the first time the service is called. And that service requests
are served by the thread pool of the servlet container. Means
no expensive process creation as CGI would do. Dunno, I guess
this is called FastCGI.

With the Jekejeke Prolog Runtime you can have multiple knowledge
bases in a servlet container, since a knowledge base is just
an object that you allocate. Then for the requests, an interpreter
is just an object that you allocate and that sits on a knowledge
base (*). Since the knowledge base allows multi-threaded access
via interpreter objects, you can easily do FastCGI.

Bye

(*)
I had a discussion about this design on LtU some months ago. It
is still that you need one interpreter object per thread. But
you can leave the reclaiming of interpreter objects to the Java
GC. Just create an interpreter object when you need it. Creation
is not ultra cheap, but cheap enough for web service, and I am
still a little bit working on making it cheaper.

[Jan Burse]

Jan Burse schrieb:

> (*)
> I had a discussion about this design on LtU some months ago. It
> is still that you need one interpreter object per thread. But
> you can leave the reclaiming of interpreter objects to the Java
> GC. Just create an interpreter object when you need it. Creation
> is not ultra cheap, but cheap enough for web service, and I am
> still a little bit working on making it cheaper.

The bottomline is currently that interpreter objects are not
pooled, in contrast to the thread objects. I think thread objects
are pooled in many servlet containers since they are again a
little more expensive to create, also their size is a little
bigger. And maybe there are additional reasons to pool them, such
as keeping alive and reusing the socket connections.

But for interpreter objects, currently there is no pooling
support in Jekejeke Prolog. If one would desire this, one would
need to code something along a cache, possibly limited in size.
Not that hard to do, a one day job for a professional programmer.
But be aware that the cache needs to be concurrently accessible,
since this would be FastCGI.

[pic...@alice.it]

Updated to 0.2.2 (some bugfixes).

[ses]

On Tuesday, 14 May 2013 16:31:19 UTC+1, pic...@alice.it wrote:
> I have a couple of questions. Do you think WSDL+SOAP-based web services can be useful to Prolog?

I think some people would find it useful, XML/SOAP based services tend to be used a lot for transactional software, for example in the banking sector. Prolog also seems to be used a lot for financial applications, so they seem like a good match. But it is not purely popularity in certain parts of the industry - I think there is technical merit in web services with consumable contracts such as WSDL definitions.

So I would say yes.

> If yes, do you agree that Prolog would need the definition of Prolog-to-XML translation? Do you think it should be possible to avoid "typing Prolog" during this process?

Of course this is a more difficult question. In my case I didn't attempt to 'type' Prolog, opting to deal with primitive data types instead. In this sense you could say this wasn't fully supporting XML. However without extensions such as Logtalk's OO system I think Prolog is not so well suited to dealing with types.

SWI does have some nice XML parsing tools however so it would be possible to use complex data types.