Как и предыдущая версия, Kylix 2 поставляется в 3-х вариантах, но называются они теперь по-другому: Enterprise, Professional и Open. Самый “тяжеловесный” вариант, Enterprise Edition, насчитывает более 190 компонентов библиотеки CLX и включает мощные средства взаимодействия с базами данных и создания распределенных приложений. В варианте Professional Edition насчитывается около 165 компонентов CLX, а средства для работы с базами данных несколько урезаны по сравнению с Enterprise Edition. Самый “легкий” вариант, распространяемый бесплатно Open Edition, включает около 70 компонентов CLX. При этом в Open Edition отсутствуют средства для работы с базами данных и разработки приложений для Web-серверов. Кроме того бесплатный вариант Kylix 2 лишен таких "приятных мелочей" как исходные тексты модулей библиотеки CLX, а также некоторых функций редактора кода, например всплывающих подсказок для символов в окне редактора (ToolTip Symbol Insight) и механизма завершения кода (Code Completion Wizard). Далее в этой статье все новые возможности и характеристики Kylix 2 будут рассматриваться на примере наиболее полного варианта Enterprise Edition.

Среди главных новшеств Kylix 2 следует отметить средства разработки приложений Web-служб (Web Services), основанных на протоколе SOAP, поддержку сценариев на стороне сервера (server-side scripting) и средства преобразования данных в формате XML в наборы данных Dataset.

Отличия новой версии Kylix от предшествующей заметны уже в меню запуска программ. В меню Borland Kylix 2 теперь три пункта: запуск самой среды Kylix IDE, справочной системы Kylix и утилиты XML Mapper. Итак, запускаем интегрированную среду разработки. Изменения по сравнению с предыдущей версией не сразу бросаются в глаза, но они есть и их немало. Прежде всего замечаем, что палитра компонентов обогатилась двумя новыми вкладками: WebSnap и WebServices. Группа WebSnap включает компоненты для быстрой разработки мощных приложений для Web-серверов с поддержкой сценариев на стороне сервера, аутентификации и авторизации пользователей, интеграции с базами данных. Назвав эти компоненты "WebSnap", Borland очевидно намекает на то, что теперь Web-приложения можно создавать "одним щелчком мыши" и как мы убедимся, это утверждение не так уж далеко от действительности.

По данным компании Evans Data, (на которые Borland ссылается в своем пресс-релизе от 6 ноября), 70% Linux-разаботчиков считают, что Web-службы "представляют собой будущее интернет-приложений". Неудивительно по этому, что в новой версии Kylix разработке приложений Web-служб уделено особое внимание. Kylix 2 позволяет создавать приложения Web-служб на основе протокола SOAP.

Разработка SOAP-приложений в Kylix 2 очень похожа на процесс создания обычного Kylix-приложения. Для того, чтобы создать приложение-сервер, выбираем пункт SOAP Server Application на вкладке WebServices диалогового окна New Items. Как и другие приложения для Web-сервера, сервер SOAP можно разрабатывать в одном из двух вариантов: в виде независимого CGI-приложения и в виде разделяемого модуля для сервера Apache. После выбора варианта сервера Kylix автоматически создает его главный модуль - форму, содержащую три основных компонента - HTTPSoapDispatcher, HTTPSoapPascalInvoker и WSDLHTMLPublish. HTTPSoapDispatcher выполняет маршрутизацию вызовов SOAP, HTTPSoapPascalInvoker отвечает за вызов соответствующих методов объектов Kylix, а WSDLHTMLPublish динамически генерирует описание интерфейса в формате WSDL в ответ на запрос клиента.

Мы создали костяк приложения-сервера SOAP, но наш сервер не экспортирует никаких интерфейсов. Справочная система Kylix настоятельно рекомендует размещать объекты и их интерфейсы в собственных модулях, что мы и сделаем. Выбираем пункт SOAP Server Data Module на той же вкладке WebServices диалога New Items и в открывшемся окне вводим имя нового класса. В нашем проекте появляется новый модуль, в котором Kylix почти все уже сделал за нас: создал описание объекта и соответствующего интерфейса, сгенерировал для него уникальный идентификатор, объявил и вызвал функции для регистрации интерфейса и объекта во внутренней базе данных приложения. Нам осталось только добавить в описание класса и интерфейса методы, реализующие функциональность сервера. В принципе с формой Web-модуля можно работать также, как и с формой обычного приложения, т. е. добавлять компоненты, назначать обработчики свойств и т. п. Ниже приводится исходный код модуля с автоматически сгенерированным классом TMyClass и добавленными к нему методами.

unit MyClass;

interface

uses
SysUtils, Classes, InvokeRegistry, Midas, SOAPMidas, SOAPDm,
HTTPApp, HTTPProd, StdConvs;

type

IMyClass = interface(IAppServer)
['{0A0EEBA1-C6D5-D511-8973-20465108E021}']
function Cel2Fahr(Value : Double) : Double; stdcall;
function Fahr2Cel(Value : Double) : Double; stdcall;
end;

TMyClass = class(TSoapDataModule, IMyClass, IAppServer)

private

public
function Cel2Fahr(Value : Double) : Double; stdcall;
function Fahr2Cel(Value : Double) : Double; stdcall;
end;

implementation

{$R *.xfm}

procedure TMyClassCreateInstance(out obj: TObject);
begin
obj := TMyClass.Create(nil);
end;

function TMyClass.Cel2Fahr;
begin
Result := CelsiusToFahrenheit(Value);
end;

function TMyClass.Fahr2Cel;
begin
Result := FahrenheitToCelsius(Value);
end;

initialization
InvRegistry.RegisterInvokableClass(TMyClass,
TMyClassCreateInstance);
InvRegistry.RegisterInterface(TypeInfo(IMyClass));
end.

Как видно из этого листинга, наш сервер выполняет невероятно важную функцию: переводит значения температуры по шкале Цельсия в шкалу Фаренгейта и наоборот. Кстати, перевод значений из одной шкалы в другую выполняется при помощи функций из появившегося в Kylix 2 модуля StdConvs.

Процесс создания SOAP-сервера завершен. Осталось только скомпилировать проект и скопировать полученный модуль в соответствующий каталог Web-сервера Apache. Размеры скомпилированного модуля впечатляют: мегабайт с лишним. Однако, взглянем на это с другой стороны. Только что мы, буквально за пять минут, создали настоящий SOAP-сервер, наделенный такими возможностями, как динамическая генерация WSDL-описаний.

Написать SOAP-клиент еще проще, чем написать сервер. Для написания клиента нам потребуется всего лишь один специальный компонент - HTTPRIO (он расположен на вкладке WebServices). Создадим новое стандартное приложение Kylix и поместим компонент HTTPRIO в его форму. Назначим свойству URL компонента HTTPRIO строку, соответствующую URL нашего SOAP-сервера (например 'http://localhost/cgi-bin/SOAPServ/SOAP/', где SOAPServ – имя нашего модуля). Теперь нам потребуется описание интерфейса, экспортируемого сервером. Компонент HTTPRIO может получить такое описание из публикуемой сервером WSDL-страницы, однако у нас есть модуль MyClass, в котором нужный интерфейс уже описан. Добавим модуль MyClass в раздел uses главного модуля нашего приложения, добавим переменную MyIntf типа IMyClass и в конструкторе формы напишем:

MyIntf := HTTPRIO1 as IMyClass;

Теперь мы можем в приложении-клиенте обращаться к методам IMyClass Cel2Fahr и Fahr2Cel. Запрос на выполнение методов будет передан серверу SOAP. В деструкторе формы следует присвоить переменной MyIntf значение nil, чтобы приложение не пыталось дважды удалить один и тот же объект.

При проверке работы клиента вам может показаться, что клиент использует реализации методов Cel2Fahr и Fahr2Cel из "своего" модуля MyClass, но это не так. Чтобы убедиться в этом, попробуйте запустить клиент, отключив предварительно сервер Apache.

Набор компонентов WebSnap настолько многообразен, а возможности этих компонентов столь многочисленны, что для полного их описания не хватило бы и отдельной статьи. В этом разделе мы лишь кратко остановимся на таких возможностях WebSnap как поддержка сценариев на стороне сервера (server-side scripting) и контроль удаленных пользователей, работающих с приложением.

Для того, чтобы понять смысл сценариев (скриптов), выполняемых на стороне сервера, следует вспомнить "идеологию" компонентов-генераторов контента (content-producers). Одна из задач компонентов-генераторов заключается в том, чтобы вывести описание содержимого HTML страниц, предоставляемых сервером, за пределы самого приложения. Например, компонент TPageProducer использует HTML-шаблон, в котором во время выполнения программы заменяются лишь отдельные тэги. Шаблон может храниться в отдельном файле и изменяться уже после компиляции приложения, что, кроме прочего, позволяет пользователям вашей программы настраивать ее, не имея доступа к исходным текстам.

Поддержка сценариев на стороне сервера развивает эту тенденцию. В новой версии Kylix компонент TPageProducer "обзавелся" свойством ScriptEngine, так что теперь кроме специальных тэгов в его шаблоны можно включать и сценарии, написанные на языке JavaScript (в Kylix 2 для поддержки сценариев используется движок SpiderMonkey, являющийся частью открытого проекта Mozilla). В тексте шаблона блоки сценариев выделяются элементами <% и %>. В качестве примера приведем скрипт, выводящий первые 10 чисел Фибоначчи:

<%
fibp = 0;
fib = 1;
Response.Write("No 1 : 1<BR>");
for (i = 2; i <= 10; i++)
{
fib = fib + fibp;
fibp = fib - fibp;
Response.Write("No "+i+" : "+fib+"<BR>");
}
%>

Необходимо особо подчеркнуть, что речь идет именно о скрипте, выполняемом приложением-сервером перед отправкой страницы клиенту, т. е. клиент никогда не увидит этого скрипта. В странице, отправленной клиенту, приведенный выше скрипт будет замещен следующим фрагментом HTML-кода:

No 1 : 1<BR>No 2 : 1<BR>No 3 : 2<BR>No 4 : 3<BR>No 5 : 5<BR>No 6 : 8<BR>No 7 : 13<BR>No 8 : 21<BR>No 9 : 34<BR>No 10 : 55<BR>

Как и обработчики событий, сценарии на стороне сервера должны получать доступ не только к стандартным объектам приложения, но и к тем объектам, которые создает программист. Для этой цели в Kylix 2 реализованы компоненты-адаптеры. Адаптеры позволяют разработчику сервера добавлять в объектную модель скриптов собственные поля и методы, отражающие специфику сервера. Генерация шаблонов, содержащих скрипты, обращающиеся к полям и методам адаптеров, может быть автоматизирована при помощи компонента AdapterPageProducer. Нельзя не отметить также весьма удобную возможность редактирования шаблонов страниц и просмотра результатов непосредственно в окне редактора Kylix.

В общем и целом можно сказать, что технология WebSnap действительно упрощает разработку Web-приложений самого широкого спектра и, как было отмечено выше, вполне оправдывает свое гордое название.

Новая версия Kylix представляет собой существенный шаг вперед и как средство разработки от Borland и как среда программирования для Linux и потому говорить о ее недостатках не хочется. Но и молчать о них нельзя ;-). Так и не исправлена ошибка в интерфейсе CLXDisplay API, замеченная мной еще в первой версии: функция QEvent_IsQDropEvent, экспортируемая libqtintf, импортируется в модуле Qt под именем QEvent_IsQDropEventEvent. Вызов функции QEvent_IsQDropEventEvent приведет к тому, что программа завершится не успев начаться. Для того, чтобы преодолеть эту проблему, следует либо исправить и перекомпилировать модуль Qt, либо импортировать функцию явным образом:

function QEvent_isQDropEvent(e: QEventH): Boolean; cdecl;
...
function QEvent_isQDropEvent; external 'libqtintf.so' name 'QEvent_isQDropEvent'

Возможно, это не единственное "разночтение" между библиотекой libqtintf и модулем Qt, но обнаружить подобные ошибки довольно трудно, так как libqtintf не позволяет просматривать таблицу экспортируемых имен.

Плохо проработан в Kylix вывод текста в различных кодировках. Внесите в форму Kylix компонент TextBrowser и откройте в нем HTML-страницу, созданную, например, в кодировке cp-1251. Если эта кодировка не установлена по умолчанию в вашей системе, окно броузера заполнят вопросительные знаки. Проблемы возникнут при выводе текста в любых кодировках кроме базовой латинской и той, которая установлена при локализации. И это при том, что Konqueror Browser, основанный на том же Qt-классе QTextBrowser, прекрасно справится с выводом страниц в русской кодировке Windows даже в нерусифицированных версиях Linux. Дело в том, что хотя Qt library обладает весьма широкими средствами для работы с разными кодировками и, в том числе, предоставляет целый ряд текстовых кодеков, к которым к тому же можно добавлять свои собственные, Kylix не позволяет нам воспользоваться всем этим богатством. Функции для работы с классом QTextCodec в модуле Qt не определены, да и получение низкоуровневневого контроля над выводом текста в компонентах не предусмотрено.

Итак, пришла пора ответить на самый важный вопрос, который порой возникает у некоторых представителей Linux-сообщества: