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

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

3 голосов
/ 10 ноября 2009

Я пытаюсь предоставить некоторые веб-службы Java, чтобы я мог взаимодействовать с C # (см. Этот ТАК ). Приведенное ниже подтверждение концепции прекрасно работает с 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());
    }
}

Ответы [ 2 ]

4 голосов
/ 10 ноября 2009

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

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

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

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

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

2 голосов
/ 10 ноября 2009

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

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

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

...