时间戳

首页 > 解决方案 > WSO2 ESB 中入站端点的含义和目的是什么？

jakarta-ee - 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>

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

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

但我有很多疑问，它说：

入站端点是一个消息入口点，它可以将消息直接从传输层注入到中介层，而无需通过 Axis 引擎。

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

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

然后它还指定：

在现有的传输中，只有 HTTP 传输支持多租户，这是通过引入入站架构克服的一个限制。

这是什么意思？我没有得到这个限制。

最后它还指定：

当涉及到传统的基于 Axis2 的传输时，另一个限制是传输不支持动态配置。使用入站端点，可以动态创建入站消息通道，并且还有内置的集群协调以及对所有传输的多租户支持。

这是什么意思？

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

如果有一些入站端点使用真实案例场景？

标签： jakarta-eewso2integrationwso2esbwso2ei

解决方案

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

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

我希望，wso 开发人员将分享有关主题的更多信息。

推荐阅读