Для начала раскажи какого рода автоматизации.

Самого простого: сделать sql-запрос, отправить отчёт, изменить формат загруженного файла, перекинуть файл с одного сервера на другой, запустить пару бинарников т. д.

cron? или сайтик процесс должен контролировать?

Не совсем понял вопроса. Сейчас да, cron+скрипты. Хотелось бы, чтобы «сайтик» управлял этим.

Да дело не столько в автоматизации, сколько в моём жгучем желании поковырять вебсервисы. Вот и спрашиваю, с чего начать.

ну стандартно tomcat, к нему можно прикрутить хоть свою реализация крона, хоть просто стату собирать.

http://docs.oracle.com/cd/E17802_01/webservices/webservices/docs/1.6/tutorial...

J2EE Tutorial.

О, это уже ближе, спасибо. А где покурить что-нибудь по tomcat API или как его правильно назвать?

Везде один и тот же дурацкий пример, про пересчёт валюты по заданному курсу или совсем уж примитивы, типа обработки GET запроса из формы с одной кнопкой и текстовым полем.

Спасибо, почитаю.

J2EE Tutorial

J2EE это примерно то, что мне нужно, правильно? В куче джавовских аббревиатур несложно запутаться.

J2EE - Java 2 Enterprise Edition. Там все есть, что связано с энтерпрайзом. Ну почти все. Но вебсервисы в Java - это часть энтерпрайза. Есть ряд стандартных технологий для них.

не пугайте людей

Кинуть новичку официальную оракловую доку - это чистой воды садизм. Ищи туториалы по Jersey (JAX-RS) + Tomcat, не связывайся ни с какими апликейшн серверами. Увидишь где-то слова JAX-WS и SOAP - закрой доку и не бери в голову. Тебе это не нужно. Реально, чувак.

Эм. А официальные оракловые доки такие страшные? И сложно тот же JAX-RS или JAX-WS прикрутить к Tomcat?

Кинуть новичку официальную оракловую доку - это чистой воды садизм.

ну это все равно что к мсдн-у послать
помимо проприетарного :-) оракла, можно найти кучу ссылок, например на хабре:
http://habrahabr.ru/post/150034/

А официальные оракловые доки такие страшные?

Они просто плохие. В качестве quick start guide - вообще ноль. В качестве reference - во многих местах просто неполные.

И сложно тот же JAX-RS или JAX-WS прикрутить к Tomcat?

Не сложно, если тёртый перец и каждая строчка web.xml тебе как родная. Людям не в теме лучше в начале копипастить с гайдов, иначе потеряются в доках.

Они просто плохие.

я бы еще сказал - устаревшие
оракл купил солярку в свое время, разработчиков разогнал, а документация осталась :-)

А где можно в общих словах почитать про JAX-RS, JAX-WS, Jersey, томкаты и иже с ними? Чтобы сложилось более-менее целостное впечатление о технологиях.

http://it-ebooks.info/book/390/

rest+js(jquery balal) or Spring MVC or Grails or Play

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

они для этого плохо подойдут, ибо трудноотлаживаемый пипец.

если все на одном языке - то используй кастомный текстовый протокол поверх HTTP, проще если соотв. REST идеям.

убогие веб-сервисвы с SOAP - пригодны для интеграции всякой интерпрайзной порнографи с дотнета на яву через ПХП, и то по факто оно в частностях начинает глючить

Spring MVC or Grails or Play

Решать сим задачи топикстартера - это как глушить рыбу метеоризмом - тяжело и прикольно, но потом задница будет болеть.

Spring MVC можно успешно использовать для написания Rest-сервисов. Если пляшешь от Spring'а, то никакие джерси не нужны.

Тут я не самый лучший помощник, гугл и опыт были мои главными учителями. Но один совет дам: перед тем как бросаться в гущи имплементаций стоит уяснить общую идеологию Rest, можно в сравнении с SOAP. Гуглишь Rest, Rest vs SOAP и просвещаешься. Удачию

Ключевые слова для поиска: SOA, ESB.

Начальные условия: неплохо знаю плюсы и питон, умею писать хеллоуворлды на яве.

кто мешает писать вебсервисы на пистоне?

Ну и enterprise integration patterns туда же.

если все на одном языке - то используй кастомный текстовый протокол поверх HTTP, проще если соотв. REST идеям.

В том то и дело, что не на одном языке. А кастомный протокол велосипедить не хочется.

Всем спасибо, буду читать про REST и Spring, пожалуй.

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

Питон, вроде как, не совсем для этих целей предназначен.

это же не шелл, на джанге вроде вполне успешно веб-проекты делают.

Влюбом случае, для явы больше возможностей, куча фреймворков, различные технологии, как мне видится.

для того чтобы начать использовать яву придется сначала её изучить, а питон ты уже знаешь.

я вообще не люблю питон и работаю ява-программистом, но не считаю, что стоит бросать один язык и изучать новый из-за какой-то ерунды в башке (в данном случае «питон не для этих целей предназначен» - не больше чем тараканы).

я вообще не люблю питон и работаю ява-программистом, но не считаю, что стоит бросать один язык и изучать новый из-за какой-то ерунды в башке (в данном случае «питон не для этих целей предназначен» - не больше чем тараканы).

имхо, чтобы бросить вот конкретно питон, любая причина хороша.

ESB во все поля. Из опенсорцных могу посоветовать ред хатовский Fuse ESB.

это про любую технологию можно сказать и найти 100500 причин думать так.

Ну если речь зашла о создании RESTful-сервисов, то почему бы и не питон? На прошлой работе например я писал RESTful-сервисы на pylons.

Spring MVC можно успешно использовать для написания Rest-сервисов. Если пляшешь от Spring'а, то никакие джерси не нужны.

Не JAX-RS же. Разве не становится тепло и лампово от javax.* классов? =)

И сложно тот же JAX-RS или JAX-WS прикрутить к Tomcat?

Каждый java-рыцарь должен быть посвящен ритуалом написания горы boilerplate для этого, чтобы потом копипастить ее в каждый свой проект за пару минут

Безполезно, новичек прочитает доку по кошерному Java EE, потом нацепит одну единственную аннотацию на класс и будет удивляться почему в томкате это не работает, а написано что должно же.

Я ещё один совсем нубский вопрос задам. Какое отношение JAX-RS имеет к Tomcat. Ведь последнее это контейнер сервлетов, а сервлет API и JAX-RS API это не одно и тоже?

Есть стандарт Java EE. В него входит контейнер сервлетов + еще много чего, включая JAX-RS. Тоесть в Java EE контейнере ты просто пишешь аннотацию и веб-сервис готов.

Томкат - только контейнер сервлетов. Но путем подключения библиотеки реализующей стандарт JAX-RS можно и в нем пользоваться JAX-RS. Пример такой библиотеки - Jersey.

По большому счету в Java EE контенерах абсолютно то же самое просто сделано за тебя, встроенно в контейнер, но все еще на основе той же библиотеки. Например в Glassfish - Jersey. В JBoss - Resteasy если не ошибаюсь

если хочется J2EE и томкат - есть tomEE

А еще им можно оклеивать стены, Вы когда отвыкнете затыкать носки подлодками и использовать инструменты по назначению?

Может я чего не знаю: что даёт JAX-RS, чего нет в Spring MVC?

ты не знаешь что аббревиатура MVC никакоми боком не относится к RPC который по сути и нужен топикстартеру?

что даёт JAX-RS, чего нет в Spring MVC?

vendor lock-in free

Имплементации JAX-RS не настолько взаимозаменяемы, как кажется. Я сам напарывался на проблемы при переходе Jersey->RESTEasy. Так что vendor lock-in будет в любом случае. Похожая ситуация, например, с JPA-имплементациями. Вроде как бы реализуют один стандарт, а везде свои грабли. В итоге, для большого проекта, который со старта разрабатывался с Hibernate, например, никто в здравом уме не затеит переезд на EclipseLink.

Почитайте книгу по питону.

Ваш вопрос звучит примерно так:
Мне в наследство достался таксопарк, в нем легковые машины - рено, пежо, etc.
Хочу увеличить объем пассажироперевозок.
Какой модели Камаз брать?

Примерно так и звучит, но разве это плохо, увеличить объём перевозок?

Или вы намекаете на то, что Камазы не очень подходят именно к перевозке пассариров?

Или вы намекаете на то, что Камазы не очень подходят именно к перевозке пассариров?

Бинго!!

Нет ну есть конечно модификации с тентом и т.п., но, учитывая что у вас уже «по большей части на Python» - то использование явы выглядит по меньшей мере неуместным.

Мне кажется, что если проводить аналогию с таксопарком, то вместо Камаза уместно будет что-то другое, микроавтобус, например.

Почему не на джанго, кстати?

Решение принимали заказчики. Но если попытаться поставить себя на их место, то думаю из-за того, что это по сути конструктор. Т.е. нету ORM, авторизации и шаблонизаторов из коробки. Сам выбираешь и прикручиваешь что по душе. Нам это было удобно в том плане, что у нас не было общения с БД и веб-приложение не занималось отрисовкой UI.