Ограничения предоставления веб-служб Java с использованием javax.xml.ws.Endpoint?

Я пытаюсь представить некоторые веб-службы Java, чтобы я мог взаимодействовать с C # (см. Этот вопрос SO ). Код доказательства концепции, приведенный ниже, прекрасно работает с WCF!

Мой вопрос об использовании javax.xml.ws.Endpointкласса для публикации моего сервиса:

  1. Что я лишусь, пройдя этот путь вместо полноценного сервера приложений?
  2. Является ли это подходящим решением для длительной работы с низким объемом вызовов?

Следующее создает WSDL, чисто вызывается из .Net и работает хорошо. Почему бы мне не использовать это?

@javax.jws.WebService
public class TestSvc { 
    @javax.jws.WebMethod()
    public String sayHello() {
        return "Hello!";
    }
}

import javax.xml.ws.Endpoint;
public class Main  {
    public static void main(String[] args) throws Exception {
        Endpoint.publish("http://localhost:8181/Test", new TestSvc());
    }
}
3 .netjavajax-wsweb-services
10.11.2009 20:22:48
2 ОТВЕТА
РЕШЕНИЕ

Зачастую аргументы масштабируемости (пулы потоков и т. Д.) Достаточно убедительны, но вы уже обесценили их.

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

Простота администрирования, как правило, довольно удобна, так как количество ваших услуг растет.

Инфраструктуры безопасности и декларативные модели безопасности могут быть весьма важными.

Для меня вся модель программирования Java EE стоит того, чтобы ваша бизнес-логика стала нетривиальной. Теперь мы можем вступить во все споры между EJB и Spring v ... Но общее замечание, которое я хочу сделать, заключается в том, что по мере того, как ваша бизнес-логика становится более серьезной, вам необходимы такие средства, как управление потоками, постоянство, пул соединений, обмен сообщениями, кэширование и планирование; вещи, которые вы найдете в серверах приложений. Кое-что из этого происходит естественным образом в EJB3 + JPA или Spring, а некоторые в качестве естественного дополнения на серверах приложений. Если у вас есть перспективы заняться серьезной корпоративной Java-разработкой, может быть, лучше купить немного больше полноты сейчас, чтобы перейти к расширяемой основе в будущем.

4
30.06.2013 07:10:38
Я согласен с обменом некоторых функций сервера приложений, если мы не сталкиваемся со сложностями. Что вы подразумеваете под моделью программирования JEE? (Я парень C # - это Enterprise Java Beans?)
intoOrbit 10.11.2009 20:54:22
Добавлено немного более подробно,
djna 10.11.2009 21:31:47

Помимо потери преимуществ сервера приложений в целом, вы можете потерять способность управлять, администрировать и тестировать службу, если будете использовать сервер приложений.

На стороне взаимодействия вы не сможете извлечь WSDL без вызова Java. Если ваша новая служба выполнила что-то, когда она была опубликована, вам, возможно, придется придумать что-то подобное. Если вы планируете использовать WCF или что-то подобное для использования WSDL, в стороне VS есть некоторые причуды, с которыми вам придется работать при создании клиентов службы (причуды случаются не каждое поколение, но они случаются время от времени до время.)

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

2
10.11.2009 20:43:16
Не могли бы вы подробнее рассказать об этих причудах WSDL? Прерывистый? Звучит страшно. :)
intoOrbit 10.11.2009 20:49:36
Два из них, на которые следует обратить внимание: 1. Visual Studio часто зависает при повторной генерации клиента из WSDL. Конечный результат разочаровывает и отнимает много времени, потому что он требует, чтобы вы остановили процесс, немного демонтировали свое решение, а затем снова собрали его вместе. Это займет всего около 10 минут (или около того), но это случается достаточно часто, так что вы в конечном итоге съеживаетесь каждый раз, когда вам нужно перегенерировать. Проблема, безусловно, заключается в одной строке кода где-то, но поиск в Google покажет вам, что многие люди имеют одинаковую строку кода. 2. Клиент сгенерирует отдельный тип ... не хватило места
Steve 10.11.2009 20:56:59
Проблема № 2: Клиент будет сгенерирован с собственной копией объектов из WSDL. Если у вас есть две службы, каждая из которых возвращает один и тот же объект на стороне Java, сторона C # будет иметь два отдельных объекта, упакованных в разные пакеты. Итак, у вас будет какой-то дизайн на стороне C #, чтобы рационализировать, как использовать один и тот же объект в двух разных пакетах.
Steve 10.11.2009 20:58:46
Спасибо - пока у нас нет проблем с тем, как мы представляем веб-сервисы, я в порядке. Я никогда не видел, чтобы VS 2008 зависал на WSDL, но буду следить за этим. Способ обработки # 2 заключается в том, чтобы использовать IDE (или svcutil.exe) для генерации клиентских классов, а затем вручную интегрировать их в наш проект. Как только интерфейс веб-службы станет стабильным, это не будет большой работой.
intoOrbit 10.11.2009 21:16:45