Каково значение и назначение входящей конечной точки в ESB WSO2? - PullRequest
Новая
       44

Каково значение и назначение входящей конечной точки в ESB WSO2?

0 голосов
/ 04 сентября 2018

Я изучаю этот материал для сертификации WSO2 ESB:

https://wso2.com/training/enterprise-integrator-developer-fundamentals#request_training_enroll

В разделе "Download Lab kit" есть учебное пособие о том, как установить Входящую конечную точку . По сути, это просто объявление Входящая конечная точка для этого предыдущего реализованного учебного проекта:

https://docs.wso2.com/display/EI611/Sending+a+Simple+Message+to+a+Service

Я сделал это, и он отлично работает, в основном в моем проекте у меня есть этот REST API: 

<?xml version="1.0" encoding="UTF-8"?>
<api context="/healthcare" name="HealthcareAPI" xmlns="http://ws.apache.org/ns/synapse">
    <resource methods="GET" uri-template="/querydoctor/{category}">
        <inSequence>
            <log description="Request Log" level="custom">
                <property name="message" value="Welcome to HealthcareService"/>
            </log>
            <send>
                <endpoint key="QueryDoctorEP"/>
            </send>
        </inSequence>
        <outSequence>
            <send/>
        </outSequence>
        <faultSequence/>
    </resource>
</api>

, который можно напрямую вызвать этим утверждением: 

curl -v http://localhost:8280/healthcare/querydoctor/surgery

Затем я добавил Входящую конечную точку в проект: 

<?xml version="1.0" encoding="UTF-8"?>
<inboundEndpoint name="QueryDoctorInboundEndpoint" protocol="http" suspend="false" xmlns="http://ws.apache.org/ns/synapse">
    <parameters>
        <parameter name="inbound.http.port">8285</parameter>
        <parameter name="dispatch.filter.pattern">/healthcare/querydoctor/.*</parameter>
    </parameters>
</inboundEndpoint>

это означает, что я могу позвонить в эту службу, используя также этот новый сопоставленный URL: 

curl -v http://localhost:8285/healthcare/querydoctor/surgery

Я использую другой порт, потому что эта входящая конечная точка выполняет это сопоставление: 

<parameter name="dispatch.filter.pattern">/healthcare/querydoctor/.*</parameter>

Я сомневаюсь: почему я должен использовать Входящую конечную точку вместо классического URL моего REST API? Каковы преимущества или возможные варианты использования?

Я пытался прочитать официальную страницу документации об этом типе конечной точки: https://docs.wso2.com/display/ESB490/Working+with+Inbound+Endpoints

но у меня много сомнений, он говорит:

Входящая конечная точка - это точка входа сообщения, которая может вводить сообщения. непосредственно с транспортного уровня на уровень передачи без проходя через двигатель Оси.

Мой API - это служба REST, почему он должен проходить через AXIS? (Из того, что я знаю, AXIS - это технология SOAP WS.) Чего мне не хватает? И какая выгода от того, что не пройдете двигатель Axis?

Другое сомнение: посреднический уровень - это моя последовательность API, содержащая посредник, но что это за транспортный уровень?

Тогда также указывается:

Из существующих транспортов поддерживается только транспорт HTTP мультитенантность, это одно ограничение, которое преодолевается внедрение входящей архитектуры.

Что это значит? Я не получаю это ограничение.

В конце также указывается:

Еще одно ограничение, когда речь заходит об обычной базе Axis2 транспорты в том, что транспорты не поддерживают динамический конфигурации. С входящими конечными точками можно создать каналы входящих сообщений динамически, а также есть встроенный координация кластера, а также поддержка нескольких арендаторов для всех транспортирует.

Что это значит?

Мне кажется, что в этом руководстве нет реальной необходимости (кроме демонстрационных целей) использовать входящую конечную точку. Не так ли?

В случае, если какая-то входящая конечная точка использует сценарий реального случая?

1 Ответ

0 голосов
/ 18 сентября 2018

Это не полный ответ. Это всего лишь мои догадки со стороны разработчика программного обеспечения. Использование одного API лучше, чем использование нескольких различных API. Результаты - меньше кода, меньше ошибок (код уже протестирован), больше функций предоставляется в более короткие сроки. Исторически веб-сервисы предоставляют лучшие возможности, чем отдых, по крайней мере, некоторое время назад. На самом деле WSO построен вокруг двигателя оси, а затем пришло время представить возможности покоя. Представляется разумным просто преобразовать запрос покоя в тот же объект, что и движок оси с запросом мыла, и использовать все, что было сделано ранее. Недостатки, я полагаю, гораздо медленнее, чем чистый отдых. Еще одна проблема заключается в том, что мыльный протокол и осевой движок имеют определенные утверждения и ограничения, полезные для отдыха.

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

Надеюсь, wso разработчики поделятся дополнительной информацией по теме.

...