jakarta-ee - WSO2 ESB 中入站端点的含义和用途是什么？

Question

我正在学习此 Material 以获得 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>

我的疑问是:为什么我必须使用入站端点而不是 REST API 的经典 URL？有什么好处或可能的用例？

我尝试阅读有关此端点类型的官方文档页面: https://docs.wso2.com/display/ESB490/Working+with+Inbound+Endpoints

但我有很多疑问，它说:

An inbound endpoint is a message entry point that can inject messages directly from the transport layer to the mediation layer, without going through the Axis engine.

我的 API 是 REST 服务，为什么要通过 AXIS？ (据我所知，AXIS 是一种 SOAP WS 技术。)我错过了什么？不通过 Axis 引擎有什么好处？

另一个疑问是:中介层是我的包含中介的 API 序列，但是这个传输层是什么？

然后它还指定:

Out of the existing transports only the HTTP transport supports multi-tenancy, this is one limitation that is overcome with the introduction of the inbound architecture.

这是什么意思？我没有受到此限制。

最后还指定:

Another limitation when it comes to conventional Axis2 based transports is that the transports do not support dynamic configurations. With inbound endpoints, it is possible to create inbound messaging channels dynamically, and there is also built-in cluster coordination as well as multi-tenancy support for all transports.

这是什么意思？

在我看来，在本教程中，没有真正需要(除了演示目的)使用入站端点。不是吗？

某些入站端点使用真实案例场景是什么？

Answer 1

这不是一个完整的答案。这只是我从软件开发人员角度的猜测。使用单个 api 比使用多个不同的 api 更好。结果是更少的代码、更少的错误(代码已经经过测试)、在更短的时间内交付更多的功能。从历史上看，网络服务提供了比休息更好的选择，至少在一段时间内是这样。实际上，wso 是围绕轴引擎构建的，然后是时候引入休息功能了。将剩余请求转换为与轴引擎处理肥皂请求相同的对象并使用之前所做的所有内容听起来很合理。我认为缺点是比纯粹的休息服务慢得多。另一个问题是肥皂协议(protocol)和轴引擎有一定的断言和限制，对于休息很有值(value)。

例如，如果您希望使休息端点接受一些信息并以文件响应，您必须配置一组突触属性，例如内容类型，以非常棘手的方式编码文件内容。对于如此简单的事情，所有这些配置都会经过几层突触引擎。

我希望 wso 开发者能够分享更多有关该主题的信息。