Столкнулся тут с этой достаточно занятной проблемой. Проблемой, которую сам притом себе создал. Оказалось, что если мы делаем war в котором есть веб-сервис, то все хорошо, и ip получить можно классическим способом через WebServiceContext. А вот если это веб-сервис, обернутый вокруг EJB, лежащий в ejb-проектике, то так сделать нельзя. Как я не бился - не получилось. А многие узколобики сразу же эту невозможность объяснили антипаттерновостью.
Теперь надо будет переводить свои веб-сервисы в war. Зато решение классическое, и должно работать хотя бы под WASCE и Glassfish, а для меня это уже немало.
Показаны сообщения с ярлыком jax-ws. Показать все сообщения
Показаны сообщения с ярлыком jax-ws. Показать все сообщения
четверг, 29 июля 2010 г.
вторник, 24 ноября 2009 г.
Дружим java и python через web services
На первый взгляд, веб сервисы замечательное изобретение, которое должно обеспечить всех глобальным счастьем. На деле все не так радужно. Хорошо веб сервис зовется из того же языка и фрэймворка, на котором он написан сам, что основательно портит саму идею.
Мне потребовалось подружить java с python, для сервера мы используем jax-ws, а для клиента нашли сначала SOAPpy, но уперлись в то, что данная библиотека как-то плохо дружелюбна со сгенерированными jax-ws wsdl. Притом решать я начал проблему не с того конца. Я научился расширять генератор wsdl собственными классиками. Подцепился в самые нутри, добился таки смены targetNamespace... и налетел на ошибку через еще пару строчек SOAPpy.
Стало очевидно, что дальше с SOAPpy нам не по пути. Еще несколько минут поиска, и мы выходим на suds. Пока что моя кожа благодаря этой библиотеке - мягкая и шелковистая.
Про jax-ws выяснились откровенно говоря неприятные подробности: нутри страшные, индусско-японские, и совершенно дурацкие. Я вообще обычно тревожусь, когда для того, чтобы понять, куда надо ткнуться, мало прочитать статью автора, надо еще самолично проанализировать код, выругаться 10 раз, найти хак для того, чтобы сделать то, что надо нам, но что невозможно сделать тем механизмом, что поставил автор, и все это в первую неделю пользования либом. Зачем было пользоваться такими корявыми классами и так их коряво сращивать. И меня бы все это не волновало, если бы оно все работало. Так ведь нет, не работает еще вдобавок. Reference Implementation, называется.
Мне потребовалось подружить java с python, для сервера мы используем jax-ws, а для клиента нашли сначала SOAPpy, но уперлись в то, что данная библиотека как-то плохо дружелюбна со сгенерированными jax-ws wsdl. Притом решать я начал проблему не с того конца. Я научился расширять генератор wsdl собственными классиками. Подцепился в самые нутри, добился таки смены targetNamespace... и налетел на ошибку через еще пару строчек SOAPpy.
Стало очевидно, что дальше с SOAPpy нам не по пути. Еще несколько минут поиска, и мы выходим на suds. Пока что моя кожа благодаря этой библиотеке - мягкая и шелковистая.
Про jax-ws выяснились откровенно говоря неприятные подробности: нутри страшные, индусско-японские, и совершенно дурацкие. Я вообще обычно тревожусь, когда для того, чтобы понять, куда надо ткнуться, мало прочитать статью автора, надо еще самолично проанализировать код, выругаться 10 раз, найти хак для того, чтобы сделать то, что надо нам, но что невозможно сделать тем механизмом, что поставил автор, и все это в первую неделю пользования либом. Зачем было пользоваться такими корявыми классами и так их коряво сращивать. И меня бы все это не волновало, если бы оно все работало. Так ведь нет, не работает еще вдобавок. Reference Implementation, называется.
Подписаться на:
Сообщения (Atom)
