What is the meaning and the purpose of an inbound endpoint in WSO2 ESB?

Question

I am studying this material for the WSO2 ESB certification:

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

Into the "Download Lab kit" section there is a tutorial about how to set an Inbound endpoint. Basically it simply ad an Inbound endpoint to this previous implemented tutorial project:

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

I have done it and it works fine, basically in my project I have this 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>

that can be directly called by this statement:

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

Then I added this Inbound endpoint to the project:

<?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>

that means that I can call this service using also this new mapped URL:

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

I am using another port because this inbound endpoint is performing this mapping:

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

My doubt is: why have I to use an Inbound endpoint instead the classic URL of my REST API? What are the benefits or the possible use cases?

I tried to read the official documentation page about this endpoint type: https://docs.wso2.com/display/ESB490/Working+with+Inbound+Endpoints

but I have a lot of doubts, it says:

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.

My API is a REST service, why should it go through AXIS? (From what I know AXIS is a SOAP WS technology.) What am I missing? And what is the benefit to not going through the Axis engine?

Another doubt is: the mediation layer is my API sequence containing the mediator but what is this transport layer?

Then it also specifies:

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.

What it means? I am not getting this limitation.

At the end it also specifies:

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.

What it means?

It seems to me that, in this tutorial, there is no real need (except for demonstration purposes) to use an inbound endpoint. Isn't it?

In case what are some inbound endpoint use real case scenario?

Answer 1

This is not a complete answer. It is just my guesses, from software developer side view. Usage of single api is better then usage of several different api. Results are less code, less errors (code is tested already), more features are delivered in shorter time. Historically web services provide better options then rest, at least some time ago. Actually wso is build around axis engine and then time to introduce rest capabilities came up. It sounds reasonable just to transform rest request into same object as axis engine does with soap request and use everything made before. Drawbacks, I assume, much slower then pure rest service might work. Another issues are soap protocol and axis engine have certain assertions and limitations, valuable for rest.

For example if you wish to make rest endpoint to accept some information and respond with file you have to configure set of synapse properties like content-type, encode file content in really tricky way. All this configuration will pass over several layers of synapse engine for such simple thing.

I hope, wso developers will share more info about subject.