[ 
https://issues.apache.org/jira/browse/STRATOS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Imesh Gunaratne updated STRATOS-659:
------------------------------------

    Description: 
In current Domain Mappings implementation Stratos allows to add domain mappings 
to service subscriptions with following parameters: cartridgeType, 
subscriptionAlias, list of <domainName, appContext>. 

Stratos Manager sends this information to load balancers via the message 
broker. Load balancer keeps domainName in a hash map against its cluster, once 
a request is received, the cluster is fetched and request is delegated to the 
next available member in that cluster without touching the request path. In the 
member a Tomcat virtual host could be created with the appContext to map the 
incoming request path to actual application path.

However this design might not work with different types of services which may 
not be able to use Tomcat virtual hosts. More importantly URL mapping 
functionality needed to be implemented in each and every service.

Therefore we could overcome this problem by introducing a new functionality in 
load balancer to map URLs and directly delegate the incoming requests to the 
member application context path.

Incoming request: 
https://foo.org/some/file/path?someQueryParam=value

Application Context: 
/tenant/foo.org/app-name/version

LB re-writes it to: 
https://member-ip:port/tenant/tenant-identifier/app-name/version/some/file/path/?someQueryParam=value

  was:
In current Domain Mappings implementation Stratos allows to add domain mappings 
to service subscriptions with following parameters: cartridgeType, 
subscriptionAlias, list of <domainName, appContext>. 

Stratos Manager sends this information to load balancers via the message 
broker. Load balancer keeps domainName in a hash map against its cluster, once 
a request is received, the cluster is fetched and request is delegated to the 
next available member in that cluster without touching the request path. In the 
member a Tomcat virtual host could be created with the appContext to map the 
incoming request path to actual application path.

However this design might not work with different types of services which may 
not be able to use Tomcat virtual hosts. More importantly URL mapping 
functionality needed to be implemented in each and every service.

Therefore we could overcome this problem by introducing a new functionality in 
load balancer to map URLs and directly delegate the incoming requests to the 
member application context path.

Incoming request: 
https://foo.org/some/file/path?someQueryParam=value

Application Context: 
/tenant/foo.org/app-name/version

LB re-writes it to: 
https://member-ip:port/tenant/foo.org/app-name/version/some/file/path/?someQueryParam=value


> Improve Domain Mappings Functionality to Re-Write URLs in Load Balancer
> -----------------------------------------------------------------------
>
>                 Key: STRATOS-659
>                 URL: https://issues.apache.org/jira/browse/STRATOS-659
>             Project: Stratos
>          Issue Type: Improvement
>          Components: Load Balancer
>            Reporter: Imesh Gunaratne
>            Assignee: Imesh Gunaratne
>             Fix For: 4.1.0
>
>
> In current Domain Mappings implementation Stratos allows to add domain 
> mappings to service subscriptions with following parameters: cartridgeType, 
> subscriptionAlias, list of <domainName, appContext>. 
> Stratos Manager sends this information to load balancers via the message 
> broker. Load balancer keeps domainName in a hash map against its cluster, 
> once a request is received, the cluster is fetched and request is delegated 
> to the next available member in that cluster without touching the request 
> path. In the member a Tomcat virtual host could be created with the 
> appContext to map the incoming request path to actual application path.
> However this design might not work with different types of services which may 
> not be able to use Tomcat virtual hosts. More importantly URL mapping 
> functionality needed to be implemented in each and every service.
> Therefore we could overcome this problem by introducing a new functionality 
> in load balancer to map URLs and directly delegate the incoming requests to 
> the member application context path.
> Incoming request: 
> https://foo.org/some/file/path?someQueryParam=value
> Application Context: 
> /tenant/foo.org/app-name/version
> LB re-writes it to: 
> https://member-ip:port/tenant/tenant-identifier/app-name/version/some/file/path/?someQueryParam=value



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to