Я пытаюсь представить некоторые веб-службы Java, чтобы я мог взаимодействовать с C # (см. Этот вопрос SO ). Код доказательства концепции, приведенный ниже, прекрасно работает с WCF!
Мой вопрос об использовании javax.xml.ws.Endpointкласса для публикации моего сервиса:
- Что я лишусь, пройдя этот путь вместо полноценного сервера приложений?
- Является ли это подходящим решением для длительной работы с низким объемом вызовов?
Следующее создает 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());
}
}Зачастую аргументы масштабируемости (пулы потоков и т. Д.) Достаточно убедительны, но вы уже обесценили их.
Далее надежность. Некоторые серверы приложений обладают хорошими возможностями кластеризации, очень легко добавлять новые экземпляры, что обеспечивает отказоустойчивость и консолидированное административное представление.
Простота администрирования, как правило, довольно удобна, так как количество ваших услуг растет.
Инфраструктуры безопасности и декларативные модели безопасности могут быть весьма важными.
Для меня вся модель программирования Java EE стоит того, чтобы ваша бизнес-логика стала нетривиальной. Теперь мы можем вступить во все споры между EJB и Spring v ... Но общее замечание, которое я хочу сделать, заключается в том, что по мере того, как ваша бизнес-логика становится более серьезной, вам необходимы такие средства, как управление потоками, постоянство, пул соединений, обмен сообщениями, кэширование и планирование; вещи, которые вы найдете в серверах приложений. Кое-что из этого происходит естественным образом в EJB3 + JPA или Spring, а некоторые в качестве естественного дополнения на серверах приложений. Если у вас есть перспективы заняться серьезной корпоративной Java-разработкой, может быть, лучше купить немного больше полноты сейчас, чтобы перейти к расширяемой основе в будущем.
Помимо потери преимуществ сервера приложений в целом, вы можете потерять способность управлять, администрировать и тестировать службу, если будете использовать сервер приложений.
На стороне взаимодействия вы не сможете извлечь WSDL без вызова Java. Если ваша новая служба выполнила что-то, когда она была опубликована, вам, возможно, придется придумать что-то подобное. Если вы планируете использовать WCF или что-то подобное для использования WSDL, в стороне VS есть некоторые причуды, с которыми вам придется работать при создании клиентов службы (причуды случаются не каждое поколение, но они случаются время от времени до время.)
Долгосрочный сервис (другими словами, вы подразумеваете, что сервис должен работать бесконечно) должен был управляться как процесс. В зависимости от вашего дизайна и требований вам придется подумать о запуске и остановке процесса, его приостановке и т. Д.