В чем разница между нисходящим веб-сервисом и нисходящим веб-сервисом?

Question

В Java, в чем разница между нисходящим веб-сервисом и нисходящим веб-сервисом?Кроме того, в чем разница между SOAP и веб-службой REST-ful?

Answer 1

Сверху вниз означает, что вы начинаете с WSDL, а затем полностью создаете все необходимые леса в Java.

Вниз означает, что вы начинаете с метода Java и генерируете из него WSDL.

SOAP означает, что URL-адрес один и тот же для всех вызовов, и отличаются только параметры метода Java. REST означает, что URL-адрес и вызванный на нем HTTP-метод отражают выполняемую операцию.

Answer 2

Первый контракт по сравнению с последним контрактом

Снизу вверх: подход использует определение проблемы высокого уровня и подразделяет его на подзадачи.

т.е. Договор-последний . Существуют следующие Преимущества для предпочтения стиля разработки Bottom-Up.

• Код первый
• Начальная стадия очень проста в освоении.

Недостатки:

• Обслуживание очень и очень сложное.
• Плотно связанные

Сверху вниз: Подумайте об основных функциях и необходимых деталях.

т.е. контрактного первый . Существуют следующие причины предпочтения стиля разработки сверху вниз.

1. Хрупкость Последний стиль разработки контракта приводит к тому, что ваш контракт веб-сервиса (WSDL и ваш XSD) генерируется из вашего контракта Java (обычно это интерфейс). Если вы используете этот подход, у вас не будет никаких гарантий того, что контракт будет оставаться неизменным в течение долгого времени. Каждый раз, когда вы изменяете свой Java-код и повторно развертываете его, в контракте веб-службы могут быть последующие изменения. Кроме того, не все стеки SOAP генерируют один и тот же контракт веб-службы из контракта Java. Это означает, что изменение текущего стека SOAP на другой (по какой-либо причине) также может изменить ваш контракт на веб-сервис. При изменении контракта на веб-сервисы, пользователи контракта должны будут получить инструкции для получения нового контракта и, возможно, изменить свой код, чтобы учесть любые изменения в контракте. Чтобы контракт был полезным, он должен оставаться постоянным как можно дольше. В случае изменения договора вам нужно будет связаться со всеми пользователями вашего сервиса и дать им указание получить новую версию договора.

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

3. Повторное использование Определение вашей схемы в отдельном файле позволяет вам повторно использовать этот файл в различных сценариях.

4. Versioning Даже если контракт должен оставаться постоянным как можно дольше, его иногда нужно менять. В Java это обычно приводит к появлению нового интерфейса Java, такого как AirlineService2, и (новой) реализации этого интерфейса. Конечно, старая служба должна быть сохранена, потому что могут быть клиенты, которые еще не мигрировали. Если использовать контракт сначала, у нас может быть более слабая связь между контрактом и реализацией. Такая более слабая связь позволяет нам реализовать обе версии контракта в одном классе.

Answer 3

@ mad_programmer - Вы имеете в виду создание веб-служб с подходом снизу вверх или сверху вниз.Во-первых, вы начинаете программировать классы и бизнес-логику как код Java, а затем генерируете из них контракт веб-службы (т. Е. WSDL).Последний подход означает противоположность (создание заглушек классов из WSDL).

Answer 4

Поддерживая ответ Андерсена, я хотел бы добавить пункт.В основном люди склонны использовать подход «снизу вверх», потому что в большинстве случаев мы уже начали бы процесс написания bean-компонентов, бизнес-логики и т. Д., А затем на уровне персистентности мы создаем веб-сервисы, wsdl и т. Д., Гдекак и в новом проекте, где вы создаете что-то с нуля, мы можем использовать нисходящий подход, где мы просто напишем wsdl, а построение каркаса даст вам компоненты, реализации, интерфейсы и т. д. Тем не менее, помните, что компьютер не может генерироватьлогика, которую вы хотите.Итак, вам все равно нужно пройти весь проект и заполнить пробелы.

Answer 5

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

Answer 6

Сверху вниз вы определяете, что вы собираетесь делать в первую очередь.т.е. твой wsdl.И тогда вы приступаете к реальному развитию.Хотя сначала трудно создать wsdl, рекомендуется (см. Eclipse) , поскольку в долгосрочной перспективе это упрощает вашу разработку.

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