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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

Контракт-первый и Контракт-последний

Bottom-Up: требует высокого уровня определения проблемы и подразделяет ее на подзадачи.

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

• Сначала код
• Начальный этап очень прост в разработке.

Недостатки:

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

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

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

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

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

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

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

TL;DR;

Верхняя и нижняя иерархия

image credit: google images

Ответ 4

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

Ответ 5

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

Ответ 6

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

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