Необходимо сделать промежуточный уровень, между клиенским приложением и сервером БД (Sybase ASE), через сервер приложений, как я понимаю это реализуется на веб сервисах. Хотелось бы узнать, что в данном случае оптимальный использовать, промежуточном уровне не предпологается никакая аглоритмическая обработка. Взаимодествие между клиентом и сервером приложений предпологается взаимодейсвие по SOAP. Также необходимо предусмотреть сессионость между клиентом и сервером приложений.

Хотелось бы узнать, что использовать в данной задачи (AXIS, AXIS2,  Burlap, и др)  и вообще при разработке веб сервисов по состоянию на настоящее время. Как подходят Sun-овские технологии для разработки веб сервисов, в том числе и в SE6

А еще чтобы можно было пересылать сложные объекты, ResulSet, например

Это сообщение отредактировал(а) VSergeyV - 22.2.2007, 09:21

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

Просто требование, чтобы не пускать внешних клиентов напрямую к БД, не открывать для них внешний порт, вроде все пока, ну может еще как одно дополнительное средство идентификации клиентских приложений, вообщем дана такая постанова задачи  

Ну т.е. я так понял что вам нужно просто сделать приложение для доступа к БД? Ну тогда лучше использовать EJB на сервере приложений для реализации логики доступа к БД. Клиентом в данном случае может быть как веб-приложение, так и обычная GUI-программа.
Кстати можно использовать Stateful Session Bean для хранения информации в течении сессии.

Ох не знаю... EJB - тяжёлая кувалда и забивать ей каждый гвоздь...
Да и стэйтфул - тяжёлая вещь....
У нас вся логика в EJB, но сессионность - вэб средствами. Все фасады - стэйтлесс... Хотя, если вэб-клиентов будет мало...

Кстати... Mikamj, я просто не работал с вебсервисами... неужели они медленнее еджиби? Имхо, на маршаллинг и сложные финты ушами еджиби-контейнера времени должно уходить не меньше... но вот вместе производительность не тестил...

Надо чтоб тонкий ценитель вебсервисов Stampede заглянул... хотя тогда он одеяло на них потянет. 


VSergeyV, главная цель - изоляция уровней приложения с оглядкой на дальнейшую возможную модернизацию?

да и это в том числе, если не не одно из главных

Сервисы медленнее, ведь для взаимодействия с ними используется текстовый протокол SOAP. А с веб-сервисами практически тоже самое происходит, что и с EJB, тот же например маршаллинг. Просто за счет независимого протокола SOAP появляется возможность создать оболочки над двумя приложениями, написанными например на дотнете и Java и эти приложения спокойно смогут взаимодействовать между собой посредством вызова нужных сервисов. Именно для этого и была создана технология веб-сервисов, в первую очередь для интеграции.

Это таки да...


Гм.. надо будет протестить как-то... В еджибях служебная обработка, насколько помню, потяжелее всего остального.. 

VSergeyV, усли уж вводить промежуточный слой (что, положа руку на сердце, сразу делает прогу на порядок сложнее), то тогда уж и задействовать все те (очень немалые) преимущества, которые предоставляет трехзвенка. В первую очередь - вынести бизнес-логики на сторону сервера приложения. А то я так понял, ты собрался ResultSet'ы по сети гонять 

Что касается взаимодействия между сервером и клиентом. Я думаю, никто не будет спорить, что лучше текста (XML, хотя и не обязательно) по HTTP тут ничего пока не придумано. Тут тебе и кроссплатформенность, и интероперабельность, и максимальная прокси-проходимость 

Но вот на чем это сделать - тут есть варианты. Самое распространенное решение - это AXIS(AXIS2). Но я не считаю, что оно самое удачное. Я вообще категорически против любых решений, котрые за тебя генерят какой-то код - будь то SQL-скрипты, оконные Java-классы или описатели WSDL с классами-заглушками впридачу. Концептуально Burlap в этом отношении в тысячу раз сильнее: ему безразлично, что ты хочешь ремоутить. Дай ему только внешний контракт (интерфейс) компонента, и предоставь класс-реализацию - и фсе! Не надо никаких чудовищных WSDL файлов, не надо всяких стабов - все сразу начинает работать, тут же, на глазах.

Другая приятная особенность Burlap'а - это несравненная простота его XML формата. В частности, это позволяет запросто накидать парсер к нему практически на любом языке программирования. Например, я в своих прогах вызываю удаленные ("забурлапленные") методы напрямую из ... браузера, посредством объекта XmlHttpRequest и маленькой библиотечки, которая запаковывает и распаковывает объекты JavaScript в бурлапный XML-формат и обратно.

У Бурлапа, конечно, тоже есть свои недостатки, но тут уж ничего не поделаешь. Я вообще считаю, это позор для Java-комьюнити, что у нас до сих пор нет единого, независимого, многофункционального, гибкого и расширяемого средства ремоутинга, особенно принимая во внимание, что сделать-то его, собственно, не так уж и сложно. Чай, не бином Ньютона 

Ну а пока, за неимением лучшего, рекомендую все-таки Burlap.

ResultSet у вас врядли получится отослать. Здесь когда-то уже обсуждали. 

вообщемто это и не оптимально

хотелось бы узнать как оптимальней серелизовать результат вызова удаленной процедуры? C помощью ORM (Hibernate, iBatis), кстати что из них лучше? или вручную писать XML  

И еще вопрос про AXIS2 (хоть и Burlap мне очень понравилсь, но решили заюзать AXIS2 чтобы набудующее гарантировать позможность взаимодействия с разношерстными клиентами, хотя и по Burlapy есть либы для С, С шарп, хотя может и Burlap оставим  ), так вот

вообще для реализации данной задачи у мне нужно предусмотреть
1) Вызов чистого SQL - хранимых процедур с параметрами, название функции и параметры передает клиет
2) Возврат клиенту результата выполнения хранилки, благо в хранилках никогда не бывает нескольких возвращаемых результатов SELECT
3) Возврат клиенту исключений уровня сервера БД
4) Возврат клиенту исключений уровня JDBC

По поводу передачи исключений, AXIS2 позволяет возбуждать исключения на сервисе и перехватывать их на клиенте (пример faulthandling из samples), хотел бы вот узнать, для того чтобы их ловить клиент должен обязательно заюывать AXIS2 или это в SOAP предусмотрено, и вообще значит и на С++ и на С шапр можно будет поймать искючение и его обработать