Как я уже говорил ранее, мы используем реализация веб сервисов от Sun, под названием Jax-WS. Хочу в этом посте рассказать о проблемах связанных с использованием веб сервисов.
Но для этого небольшое отступление требуется. В котором нам надо вспомнить что же такое веб сервисы и как они работают.
Итак давайте взглянем на .Net, в сторону Asp.Net WebServices. Для создания веб-сервиса нам требуется следующее:
1. Создать класс веб сервиса.
2. Пометить его и его методы атрибутами [WebService],[WebMethod].
3. Использовать в качестве передаваемых типов, те типы которые могут сериализоваться, т.е. помеченные либо атрибутом [Serializable], либо использовать значимые типы.
А теперь давайте посмотрим что же мы можем передавать через веб сервисы в .net. Да почти что все типы самого фреймворка. В частности мы спокойно можем передать DataSet. Это удобно, т.е. используя Ado.Net, мы получаем данные, запихиваем их в DataSet и спокойно передаем через веб-сервисы. Почему так? Потому что реализация веб-сервисов одна, и разработчики .Net, знали что у них во фреймворке есть реализация веб-сервисов, и они знали что некоторые типы им потребуется передавать, вот они их при разработке и пометили атрибутом Serializable. Все здорово, мы спокойно живем и используем типы .Net в веб-сервисах.
Я понимаю, что сделать типы сериализуемыми сподвигло разработчиков не сопровождение веб сервисов, а другие цели. Но идея все в том, что веб сервисы реализуемые в .net используют именно этот атрибут.
А теперь взглянем на джаву. Реализаций веб-сервисов много. Каждая реализация веб-сервисов использует свои принципы сериализации. Т.е. для одного надо написать например метод сериализации типа, для другого надо тип пометить каким нибудь атрибутом. Чувствуете где начинается головная боль? Правильно! Если мы используем реализацию веб-сервисов от Sun, пожалуй нам надо забыть о передачи типов через веб-сервисы, которые реализованы не Sun, и в которых возможность передачи объекта типа, не заложена в тип.
Для того что бы включить сериализацию объекта на уровне веб-сервиса Jax-WS (т.е. позволить передавать объект через веб-сервис), тип объекта требуется пометить атрибутом @XmlAccessorType. Здорово, но! В нашем продукте для работы с БД используется тип от IBM, под названием DBSelect. Он внутри себя инкапсулирует работу с БД, позволяет делать запросы и после этого в себе содержит полученный результат. Для работы с результатом используется интерфейс TableModel. Но как вы уже догадались я не могу передать через веб сервис Jax-WS, экземпляр типа DBSelect. Потому что при создании этого типа, разработчики не пометили его требуемыми атрибутами, потому что разработчики и не думали о том, что этот тип будет передаваться через веб-сервисы.
Как мы будем выходить из сложившейся ситуации? Мы либо перелопатим код DBSelect. Либо будем использовать реализацию подобного класса от Sun. Который можно будет передавать через веб-сервисы.
Вот на таких вещах и начинает убивать разнородность джавы, порождаемая самими разработчиками, которые разрабатывают свои линейки типов. Зачем так сделали, постоянно я себя спрашиваю? И тут же понимаю, OpenSource, так его и так. Мы с моими коллегами сравниваем это все дело с линейками nix-овых систем. Там все точно также. Трагично это все. И теперь я понимаю почему будущего у джавы нет. Хотя чувствую вы можете сказать иначе. Послушаю...
Дальше я вам расскажу как я работал с экселем и посмотрим на WSSecurity. Очень много всего тут есть интересного.
странно, но на developers.org.ua вакансий джавы куча,а .нет почти 0. с чем это может быть связано?
ОтветитьУдалитьДело все в том что на Java пишут чаще всего маленькие конторки, которые не могут себе позволить .Net. Все таки та же VS стоит денег, и не маленьких. Маленьких компаний много, поэтому и предложений много. Вот как то так.
ОтветитьУдалить> "Вот как то так."
ОтветитьУдалитьВообще-то всё как-то наоборот ))
"Дальше я вам расскажу как я работал с экселем и посмотрим на WSSecurity. Очень много всего тут есть интересного."
ОтветитьУдалитьЖдём ))
> "Вот как то так."
ОтветитьУдалить> "Вообще-то всё как-то наоборот ))"
Готов поспорить. :-)
Ну, не спора ради...
ОтветитьУдалитьВообще, бесплатность JavaEE (бесплатные сервера приложений, средства разработки) - это появилось относительно недавно. Раньше, в начале 2000-ых, рулили дико платные IBM WebSphere, BEA WebLogic, Orcale AS, Sun Enterprise AS. Естественно, что позволить платить за них огромные деньги (и запускать их на крутом оборудовании) могли себе позволить лишь крутые ентерпрайзы.
У майкрософт же сравнимых технологий не было ни тогда, ни сейчас.
Сегодняший всплеск интереса к JavaEE, по моему мнению, стал возможным благодаря уменьшению стоимости оборудования, которое может тянуть сервера приложений и т.п.
Т.е. благодаря доступному железу и благодаря развитию бесплатного ПО (это очень качественные и бесплатные сервера приложений JBoss и GlassFish, поддержка компонентов JavaEE в NetBeans и т.п.) Java вырвалась из enterprise-сектора на оперативный простор.
Вот как-то так ))
Хм. Да, вы правы.
ОтветитьУдалитьНо, я бы сказал что Enterprise приложения отлично пишутся на .Net. И я бы сказал что с точки зрения промышленной разработки .Net опережает Java. Но у Java есть свои неоспоримые преимущества:
- "это очень качественные и бесплатные сервера приложений JBoss и GlassFish, поддержка компонентов JavaEE в NetBeans и т.п."
- Кроссплатформенность
Что заставляет Java жить.
И вот еще раскройте пожалуйста что вы подразумеваете под оперативным простором. :-) Какие именно направления? :-) Спасибо.
«Но, я бы сказал что Enterprise приложения отлично пишутся на .Net.»
ОтветитьУдалитьПишуться, да. Но отсутствие технологий аналогичных EJB напрягает.
«И я бы сказал что с точки зрения промышленной разработки .Net опережает Java.»
Ну, у .Net есть преимущества в виде стандартных компонентов типа DataSet, которые интегрированы с интерфейсными компонентами. У Java в этом отношении несколько сложнее, как вы прошлых записях и описали. Но эти проблемы решаемы.
«что вы подразумеваете под оперативным простором»
Я имел в виду, что теперь JavaEE юзается не только в крупных ентерпрайзах, но и в конторах рангом поменьше, которые раньше были вотчиной майкрософта.
Пишуться, да. Но отсутствие технологий аналогичных EJB напрягает.
ОтветитьУдалитьВот тут смею с вами не согласится!
Что такое EJB?
1. Это EntityBean - по сути ORM
2. SessionBean - по сути своей удаленный объект
Что есть в .Net сопоставимое с EntityBean? Да все что угодно. Самый простой Linq2Sql, али посложнее который Ado.Net EntityFramework, в конце концов всем знакомы Hibernate, который есть и у .Net.
А что касается SessionBean то их просто рвет своим функционалом, интеграцией, простотой и вообще рюшечками - WCF. Что же такое WCF? Это технология позволяющая создавать тот же SessionBean. Но! С этим SessionBean'ом можно будет общаться через Remoting, Web-services, или даже !MSMQ!. Реализовано все в духе MS очень просто, высоко интегрировано со средой, компонентами и т.п.
Так что не могу я сказать по своему опыту что EJB, это НЕ то чего не хватает в .Net. Чего не хватает .Net я написал в прошлом топике.
У Java в этом отношении несколько сложнее, как вы прошлых записях и описали. Но эти проблемы решаемы.
Да, конечно решаемы. Но в плюс джаве это не поставишь.
Я имел в виду, что теперь JavaEE юзается не только в крупных ентерпрайзах, но и в конторах рангом поменьше, которые раньше были вотчиной майкрософта.
Мне кажется мы с этого и начали.
Дело все в том что на Java пишут чаще всего маленькие конторки, которые не могут себе позволить .Net. Все таки та же VS стоит денег, и не маленьких. Маленьких компаний много, поэтому и предложений много. Вот как то так.
Так что не могу я сказать по своему опыту что EJB, это НЕ то чего не хватает в .Net. Чего не хватает .Net я написал в прошлом топике.
ОтветитьУдалитьПрошу прощения. Надо читать как:
Так что не могу я сказать по своему опыту что EJB, это то чего НЕ хватает в .Net. Чего не хватает .Net я написал в прошлом топике.
Возможно вы правы, с WCF я не знаком, поэтому ничего не могу сказать о том что он умеет.
ОтветитьУдалитьС другой стороны, WCF появился относительно недавно, а первая версия EJB ещё в прошлом веке.
У нас на работе двое дотнетчиков разбирались с WCF и собирались сделать обзор возможностей, но (вы наверное будете смеяться) за несколько дней разобраться и запустить его так и не смогли и забили на него, поэтому я про него знаю только понаслышке.
Да, WCF конечно моложе чем EJB. В этом его плюсы и минусы.
ОтветитьУдалитьНу может быть как появится время напишу обзор про WCF (не в укор вашим программистам, хотя должны были все таки разобраться).
Спасибо за дискуссию, многое у меня разложилось по полочкам. :-)