Grzegorz Caban, grzegorz.caban@gmail.com

Investigate runtime integration aspects, mainly the integration of the Object-Oriented Model in Prolog with a Java VC possibilities executable design, LogTalk, etc.

• input Java, OO Prolog documentation, MVC concept. Prolog OOP, LogTalk, TrincProlog, SICStus Prolog
• output

Feasibility study, a prototype.

Historia spotkań

Celem projektu było przetestowanie możliwości budowy aplikacji wielowarstwowych opartych o wzorzec projektowy MVC przy użyciu Javy oraz Prologa. Zakładając, że aplikacja jest projektowana zgodnie z metodologia programowania obiektowego i na etapie projektowania aplikacji nie decydujemy, który moduł, czy wręcz obiekt której klasy ma zostać zaimplementowany przy użyciu Javy, a który w Prologu. Dopiero osoba implementująca ten projekt powinna mieć możliwość teoretycznie dowolnego wyboru jednej z tych technologii, w zależności od tego jak wygodniej będzie zaimplementować dany obiekt. Tak postawione założenia wymuszają znalezienie technologi/framework'a umożliwiającego:

• Tworzenie kodu w języku Prolog z wykorzystaniem wszystkich dobrodziejstw programowania obiektowego. Jest to warunek konieczny, aby zapewnić pełną dowolność implementowania poszczególnych klas modelu w Prologu lub Javie, musimy zapewnić, że Prolog będzie zapewniał te same możliwości abstrakcji danych, enkapsulacji, dziedziczenia itp co Java.

• Wygodną integracje kodu Prolog'a z kodem w Javie, w ideale bez tworzenia dodatkowego kodu służącego tylko do komunikacji pomiędzy obiektami napisanymi w różnych językach, a w praktyce minimalizujących ilość takiego kodu. Zwłaszcza istotne wydaje się aby implementacja tej warstwy komunikacyjnej dała się łatwo odseparować od logiki samej aplikacji, tak aby minimalnie zaburzyć projekt wejściowy.
• Warte podkreślenia jest też wymóg integracji obiektów Prologa i Javy dopiero na etapie runtime'u, nie chodzi tutaj o wygenerowanie kodu Javy na podstawie kodu Prologa i poźniejsze uruchomienie aplikacji w samej Javie.

Pierwszym zatem zadaniem było znalezienie odpowiedniego framework'a umożliwiającego tworzenie obiektów w Prologu oraz integracje tych obiektów z obiektami zaimplementowanymi w Javie.

Poniżej znajduje się lista framework'ów, które zostały w ramach tego projektu przetestowane w nadziei znalezienia spełniającego wyżej postawione zadania :

• yap - yap jako wysoko wydajny kompilator Prologa, wzbogacony o takie funkcjonalności jak : strumienie We/Wy, socket'y, moduły wyjątki, debugger itp. nie wydaje się być narzędziem przydatnym w tym projekcie, zwłaszcza że gdy w jego dokumentacji pojawia się temat obiektowości polecane jest użycie LogTalk'a, który swoją drogą podobno dość dobrze się integruje z yap'em.
• amzi - narzędzie płatne, choć można wykorzystywać do celów akademickich za darmo, niestety bez źródeł. Bardzo dobrze udokumentowane. Posiada interface do używania prologa z Javy, poprzez obiekt klasy LogicServer możemy się łatwo odwoływać do bazy wiedzy Prologa, w sposób przypominający przesyłanie zapytań do bazy danych.Natomiast dokładna dokumentacja : LogicServer API. Rozwiązanie wydaje się być zbliżone do SICStus'a. Wygląda na brak wsparcia dla obiektowości.
• SICStus Prolog - umożliwia integracje aplikacji napisanej w Prologu z inna napisana w Java/.NET poprzez PrologBeans. Klient, aplikacja JAVA'owowa przesyła komunikaty, które są odpowiednio oceniane przez server-Prolog'a, obie aplikacje są osobnymi procesami, komunikują się przez sockety TCP, czyli w architekturze klient-serwer. SICStus Prolog wspiera także obiektowość poprzez moduł „The Objects Package—library(objects)”, czyli zapewnia enkapsulacje, dziedziczenie itp.

• LogTalk - własne wsparcie dla obiektowości, poprzez LogTalk objects, zapewnia wszystkie podstawowe wymagania. Nie znalazłem bezpośredniego wsparcia dla integracji z innymi platformami, natomiast dokumentacja wspomina o takich możliwościach, dzięki "wysoko poziomowemu mapowaniu obiektów LogTalk".. Szczegóły na razie nie znane, ale przykład integracji Javy z LogTalk tutaj

• Prolog OOP - umożliwia stosowanie prolog'owych modułów do za modelowania obiektowości, umożliwia wykorzystywanie wiekszości podstawowych predykatów obiektowości takich jak:
  • dziedziczenie modułów
  • enkapsulacje predykatów
  • abstrakcyjne definiowanie modułów

Natomiast nie ma w nim mowy o możliwościach integracji Prologa z innym obiektowym językiem, to jest tylko próba wprowadzenia obiektowości do samego Prologa.

• TrincProlog - oferuje właściwie analogiczny pomysł, czyli rozszerzenie prologa o obiektowość. Tyle, że tym razem dodatkowe słowa kluczowe pozwalają na deklarowanie klas niezależnie od modułów (czyli np kilka klas w jednym module, itp ). Tyle, że niestety znowu brak możliwości integracji z innymi językami. Obiecująco wyglądała część do tworzenia aplikacji Windows, ale okazało się że jest już gotowe API pozwalające odwoływać się do obiektów GUI (Window, Button, itp.) poprzez predykaty prologa. Być może można by wykorzystać to API od odwoływania się do dowolnych obiektów, zbudować analogiczne?

Jako docelowa platforma realizacji projektu został wybrany LogTalk ze względu na fakt że zapewnia on pełne wsparcie dla obiektowości w Prologu, oraz jest w przeciwieństwie do SICStus Prolog i SICStus Prolog technologią w pełni Open Source, podczas gdy pozostałe dające praktycznie podobne możliwości są niestety technologiami komercyjnymi.

Niestety sam Logtalk nie wspiera w żaden sposób integracji obiektów tworzonych przy jego pomocy z innymi językami obiektowymi. Dlatego kolejnym krokiem jest było znalezienie narzędzia umożliwiającego integracje Logtalk'a z Java. Ponieważ docelowym kompilatorem Prologa używanym w tym projekcie jest SWI Prolog, naturalna wydała się próba użycia do tego celu jedno z pakietów standardowych dołączanych do tej dysytrybucji, czyli JPL który oferuje dwustronny interface pomiędzy Prologiem a Java. Przykład użycia JPL do komunikacji Prolog'a z Java.

Opierając się na przykładzie znalezionym na stronie jednym z sposobów integracji obiektów LogTalk z Java jest użycie jednego z pakietów SWI_Prolog, JPL : Java to Prolog Interface. Jeżeli dodać do tego obiektowość oferowaną przez LogTalk to wydaje się, że jest to zestaw spełniający dane wymagania. Przykład całej klasy napisanej w Javie, służącej do komunikacji z obiektami LogTalk znajduje się tutaj LogTalkEngine

Podczas realizacji tego projektu natrafiono na sporo problemów natury konfiguracyjnej, co wydaje się dość naturalne jako że używamy kilka niezależnie tworzonych bibliotek. Oto lista ważniejszych problemów wraz z opisem ich rozwiązania :

• Używanie modułów zewnętrznych modułów Prologa z obiektów Logtalk
• Konfiguracja SWI-Prolog do współpracy z Logtalk

Aby zebrać te i inne nieuwzględnione powyżej uwagi na temat użycia i konfiguracji JPL i Logtalk do współpracy z Java: Opis konfiguracji JPL i Logtalk

O podmianie obiektow Javy na Logtalk

O napisaniu prostej aplikacji od podstaw w MVC z Logtalk'iem

• strona z Suna z edytorem
• kod edytora z logtalk
• kod termostatu

Edytor dokumentów – Pomysły na system regułowy:

• kolorowanie składni
• wyszukiwanie słów kluczowych, analiza zdan, jezyka,
• xml, html (np formatowanie tekstu na podstawie tagów i atrybutów html)
• kontrola czy tekst zawiera wszystkie wymagane elementy (np sprawdzanie poprawnosci podania, faktury itp)
• inteligentne wyszukiwanie strukturalne

• Edytor dokumentów – bardzo prosty przykład z stron Sun'a, aplikacja do „edycji” tekstu, ale zbudowana zgodnie z MVC i przede wszystkim pełne źródła w Javie.
• System do rejestracji PUM
• Sklep internetowy - dość dokładnie opisany ale bez źródeł. Wydaje się trochę za duży.
• Mailing List - krótki tutorial do J2EE i Struts'ów ze stron IBM'a. Przykład dość prosty ale niezle udokumentowany i są też wystawione źródła.