Здравствуйте!

Планируется разработка серверного приложения с некоторой сложной внутренней логикой, количество одновременных подключений от 10 до 50, пиковая нагрузка не больше 1-2 запросов в секунду (а в основном значительно ниже), клиенты на Java и Delphi, но совсем отсекать VB и что-либо скриптовое (Python?) не хочется. Еще хочется вести разработку в терминах интерфейсов и методов, а не на уровне сокетов. А еще требуется авторизовать клиентов и на основании выданных им прав разрешать или или запрещать вызов методов (ну или всех методов одного интерфейса).

Варианты:

1. XMLRPC — реализации есть для всего, но понятие интерфейса отсутствует, более того, вместо:

Integer result = interface.method(param1, param2);

на клиенте придется писать:

Object[] params = new Object[]{param1, param2};
Integer result = (Integer)client.execute("interface.method", params);

что, впрочем решается путем описания на сервере фиктивного интерфейса и доставки сгенерированного враппера на клиента.

2. SOAP — реализации есть для всего, роль интерфейса играет WSDL, генерация врапперов уже есть, по крайней мере в Axis (а в Delphi есть?)

В обоих случаях поддержки авторизации нет, но можно задействовать средства сервлет-контейнера и что-нибудь вроде http://www.acegisecurity.org/ . Но нет ли каких ограничений на создание внутри Tomcat или Jetty собственных потоков?

3. RMI, EJB — похоже, что в Delphi малой кровью их не задействовать, или я не прав?

4. Corba — все совсем сложно, как использовать security непонятно, есть только одна проприетарная и небесплатная реализация ORB (VisiBroker), работающая с Java и Delphi.

Может я еще чего забыл? Какие будут соображения у присутствующих?

Посмотри еще протоколы Hessian и Burlap. Есть реализации для Java, Python, C++, C#, PHP и Ruby. Использовать очень просто, правда как это дело пойдет между разными платформами не знаю, использовал только Java2Java.

Здравствуйте, tuxthepenguin, Вы писали:

T>Посмотри еще протоколы Hessian и Burlap. Есть реализации для Java, Python, C++, C#, PHP и Ruby. Использовать очень просто, правда как это дело пойдет между разными платформами не знаю, использовал только Java2Java.


думал об этом, но реализации для Delphi нет

Здравствуйте, ENP, Вы писали:

ENP>Может я еще чего забыл? Какие будут соображения у присутствующих?

ничего категоричного, но мне кажется, что если есть Delphi и без него никак, то лучше думать про .NET-технологии

ENP>3. RMI, EJB — похоже, что в Delphi малой кровью их не задействовать, или я не прав?

подозреваю, что если EJB развернут на Borland AppServer'е, то его удастся задействивать и в Delphi. правда, сам не делал, говорю из общих соображений
другое дело, что тогда вступают все те же соображения относительности стоимости, как и в п. 4 — сервер придется лицензировать

ENP>Но нет ли каких ограничений на создание внутри Tomcat или Jetty собственных потоков?

уже неоднократно обсуждалось (в поиск). формально, спецификация не препятствует созданию потоков внутри контейнера, но это очень сильно не рекомендуется.
если все серьезно с потоками, то имеет смысл подумать над применением tomcat или jetty в embedded-режиме (jetty мне так доводилось применять, пусть и без изысков, tomcat — нет, но думаю, что это реально)

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, ENP, Вы писали:

ENP>>Может я еще чего забыл? Какие будут соображения у присутствующих?

C0s>ничего категоричного, но мне кажется, что если есть Delphi и без него никак, то лучше думать про .NET-технологии

Это еще почему? А если есть Java/Linux и без них никак в большей степени?

C0s>подозреваю, что если EJB развернут на Borland AppServer'е, то его удастся задействивать и в Delphi. правда, сам не делал, говорю из общих соображений
C0s>другое дело, что тогда вступают все те же соображения относительности стоимости, как и в п. 4 — сервер придется лицензировать

с Borland AppServer не хочется связываться по тем же причинам, что и .NET

ENP>>Но нет ли каких ограничений на создание внутри Tomcat или Jetty собственных потоков?

C0s>уже неоднократно обсуждалось (в поиск). формально, спецификация не препятствует созданию потоков внутри контейнера, но это очень сильно не рекомендуется.

Кстати, а ссылки на обсуждение можно? Или ключевые слова для поиска? По "tomcat thread" и "tomcat собственные потоки" не нашел

C0s>если все серьезно с потоками, то имеет смысл подумать над применением tomcat или jetty в embedded-режиме (jetty мне так доводилось применять, пусть и без изысков, tomcat — нет, но думаю, что это реально)

Я склоняюсь к Jetty, т.к. он проще и меньше и работал с ним больше. Но в чем, по большому счету, разница — embedded или нет, если для Jetty вся разница сводится к различию в синтаксисе: в embedded я описываю процедуру загрузки на Java, а в автономном — теми же словами, но на XML (а оно посредством reflection преобразуется в эквивалентный Java-код)?

Здравствуйте, ENP, Вы писали:

C0s>>ничего категоричного, но мне кажется, что если есть Delphi и без него никак, то лучше думать про .NET-технологии

ENP>Это еще почему? А если есть Java/Linux и без них никак в большей степени?

так а если есть Java/Linux, то зачем, спрашивается, Delphi?
мне не понятно как позиционирование Delphi в таком разе, так и то, что за его использование надо платить (в противопоставление Java/Linux)

Здравствуйте, Аноним, Вы писали:

А>с Borland AppServer не хочется связываться по тем же причинам, что и .NET

да это как нравится, но я бы на вашем месте более четко бы определился, использовать платные продукты, будь то развертывание (VisiBroker, BAS) или разработка (VisiBroker, Delphi) или нет.

ENP>>>Но нет ли каких ограничений на создание внутри Tomcat или Jetty собственных потоков?
А>Кстати, а ссылки на обсуждение можно? Или ключевые слова для поиска? По "tomcat thread" и "tomcat собственные потоки" не нашел

да что-то тоже не видно в упор, но вкратце я уже и так сказал: спецификация не против, но общие рекомендации не советуют

А>Я склоняюсь к Jetty, т.к. он проще и меньше и работал с ним больше. Но в чем, по большому счету, разница — embedded или нет, если для Jetty вся разница сводится к различию в синтаксисе: в embedded я описываю процедуру загрузки на Java, а в автономном — теми же словами, но на XML (а оно посредством reflection преобразуется в эквивалентный Java-код)?

под "embedded" я имел в виду, что сервер стартуется твоей функцией main, а не своим движком. детали вызовов api и проч. здесь являются, всего лишь, техническим моментом. как я понимаю, своя функция main позволяет идеологически правильно породить столько потоков, сколько нужно, не мешая их с потоками, используемыми контейнером

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, ENP, Вы писали:

C0s>>>ничего категоричного, но мне кажется, что если есть Delphi и без него никак, то лучше думать про .NET-технологии

ENP>>Это еще почему? А если есть Java/Linux и без них никак в большей степени?

C0s>так а если есть Java/Linux, то зачем, спрашивается, Delphi?
C0s>мне не понятно как позиционирование Delphi в таком разе, так и то, что за его использование надо платить (в противопоставление Java/Linux)

Delphi уже используется в системе, с которой придется (возможно, временно) взаимодействовать. В новой системе не планируется без крайней необходимости использовать закрытые технологии.

А>>Я склоняюсь к Jetty, т.к. он проще и меньше и работал с ним больше. Но в чем, по большому счету, разница — embedded или нет, если для Jetty вся разница сводится к различию в синтаксисе: в embedded я описываю процедуру загрузки на Java, а в автономном — теми же словами, но на XML (а оно посредством reflection преобразуется в эквивалентный Java-код)?

C0s>под "embedded" я имел в виду, что сервер стартуется твоей функцией main, а не своим движком. детали вызовов api и проч. здесь являются, всего лишь, техническим моментом. как я понимаю, своя функция main позволяет идеологически правильно породить столько потоков, сколько нужно, не мешая их с потоками, используемыми контейнером

Да, вы правы. jetty.xml гибок, но корень у него только один, т.е. экземпляры классов, отличных от org.mortbay.jetty.Server я в нем не создам

Еще одна мысль: если уж требуется доступ к удаленным объектам с авторизацией, то для pure java решения самым естественным выбором был бы EJB. Тот же JBoss, кажется, умеет предоставлять доступ к бинам как к вебсервисам извне — ну и пусть не-java клиенты им пользуются. Вопрос опять-таки в потоках внутри контейнера. А позволено ли их иметь в собственных JCA коннекторах?

Здравствуйте, ENP, Вы писали:

ENP>Вопрос опять-таки в потоках внутри контейнера. А позволено ли их иметь в собственных JCA коннекторах?

Сколько угодно. Только рекомендуется создавать и запускать их не самому, а "просить" из пула у WorkManager'а. Все это подробно описано в спеуификации jca 1.5