В чем смысл и назначение входящей конечной точки в WSO2 ESB?

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

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

В разделе «Загрузить лабораторный комплект» есть руководство о том, как настроить конечную точку входящего трафика. По сути, это просто объявление конечной точки входящего трафика в этом ранее реализованном учебном проекте:

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

но у меня много сомнений, там написано:

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

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

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

Затем в нем также указывается:

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

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

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

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

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

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

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


integration wso2 wso2esb wso2ei jakarta-ee
person AndreaNobili    schedule 04.09.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person simar    schedule 18.09.2018