You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Rob Slifka (JIRA)" <ji...@apache.org> on 2009/08/14 19:47:14 UTC
[jira] Created: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Support for Multiplexing Services on any Transport, Protocol and Server
-----------------------------------------------------------------------
Key: THRIFT-563
URL: https://issues.apache.org/jira/browse/THRIFT-563
Project: Thrift
Issue Type: New Feature
Components: Library (Java)
Reporter: Rob Slifka
*Motivation and Benefits*
We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
*Our Approach*
We pursued an approach with the following in mind:
- No modifications to existing Thrift code.
- No modification to the Thrift protocol as described in the whitepaper.
- No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
- No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
- Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
- Avoid language-specific features, to ease implementation in other languages.
*Additions to Thrift*
Convenience class:
- {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
For use by clients:
- {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
For use by the server:
- {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
*Sample Usage - Client*
In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
{code}
TSocket transport = new TSocket("localhost", 9090);
transport.open();
TBinaryProtocol protocol = new TBinaryProtocol(transport);
TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
Calculator.Client service = new Calculator.Client(mp);
TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
WeatherReport.Client service2 = new WeatherReport.Client(mp2);
System.out.println(service.add(2,2));
System.out.println(service2.getTemperature());
{code}
*Sample Usage - Server*
{code}
TMultiplexedProcessor processor = new TMultiplexedProcessor();
processor.registerProcessor(
"Calculator",
new Calculator.Processor(new CalculatorHandler()));
processor.registerProcessor(
"WeatherReport",
new WeatherReport.Processor(new WeatherReportHandler()));
TServerTransport t = new TServerSocket(9090);
TSimpleServer server = new TSimpleServer(processor, t);
server.serve();
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Posted by "Rob Slifka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743815#action_12743815 ]
Rob Slifka commented on THRIFT-563:
-----------------------------------
Yep, you nailed exactly why we chose the {{TProcessor}}-as-broker approach. We didn't want to limit multiplexing support to any specific {{TTransport}} (e.g. {{THttpClient}}).
Regarding your specific concern: {{THttpClient}} already allows setting custom headers via {{THttpClient::setCustomHeaders(...)}} and as our approach is {{TTransport}}-agnostic, setting those headers would work just fine.
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Posted by "Rob Slifka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Slifka updated THRIFT-563:
------------------------------
Attachment: THRIFT-563.patch
Patch file, for the three classes mentioned above taken from /trunk.
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (THRIFT-563) Support for Multiplexing
Services on any Transport, Protocol and Server
Posted by "Rob Slifka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743451#action_12743451 ]
Rob Slifka edited comment on THRIFT-563 at 8/16/09 12:53 AM:
-------------------------------------------------------------
At least a C++ server and a Python client. If there's enough interest, we'll contribute that as well. If you're interested, be sure to click the Vote and Watch links on the top left of this page!
was (Author: robslifka):
At least Python and C++ on the server side for our own use. If there's enough interest, we'll clean that up and contribute it as well. [THRIFT-66|http://issues.apache.org/jira/browse/THRIFT-66] never made it in, so there may not be enough interest.
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Posted by "Rob Slifka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743451#action_12743451 ]
Rob Slifka commented on THRIFT-563:
-----------------------------------
At least Python and C++ on the server side for our own use. If there's enough interest, we'll clean that up and contribute it as well. [THRIFT-66|http://issues.apache.org/jira/browse/THRIFT-66] never made it in, so there may not be enough interest.
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Posted by "Jarski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743787#action_12743787 ]
Jarski commented on THRIFT-563:
-------------------------------
This looks great - something my company will certainly try out if it is checked in.
Our team has in the past discussed approaches to dealing with exactly the issue you're trying to address, although we have been looking at it as something to build over the thrift http protocol -- specifically, each service would be served on its own http handler, e.g. server:port/Calculator, server:port/WeatherReport, etc. Your approach would be a good alternative, more widely applicable, and probably simpler (although one reason that our team still likes the http idea is that it supports out-of-band data, e.g. request ids or credentials passed with every method without having to add them explicitly to every method as args,).
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-563) Support for Multiplexing Services on
any Transport, Protocol and Server
Posted by "Ryan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743448#action_12743448 ]
Ryan commented on THRIFT-563:
-----------------------------
Are you planning on implementing other languages? I think this looks fantastic. I would love to use it.
> Support for Multiplexing Services on any Transport, Protocol and Server
> -----------------------------------------------------------------------
>
> Key: THRIFT-563
> URL: https://issues.apache.org/jira/browse/THRIFT-563
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Rob Slifka
> Attachments: THRIFT-563.patch
>
>
> *Motivation and Benefits*
> We plan to use Thrift with a large number of functions communicating among (at least) three languages. To keep maintainability high, we hope to avoid a single service defined with a large number of functions. This would require monolithic, unwieldy service implementations as the number of functions grows.
> Breaking up our API into multiple IDLs gives us multiple abstract base classes, which provides more flexibility in the object-oriented design of our server platform.
> Before our changes, the alternative was to open up additional ports with smaller service implementations on each. We'd rather not open additional ports.
> *Our Approach*
> We pursued an approach with the following in mind:
> - No modifications to existing Thrift code.
> - No modification to the Thrift protocol as described in the whitepaper.
> - No modification to any {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - No need for any new {{TServer}} implementation. Works with any {{TServer}} implementation.
> - Work with any combination of {{TServer}}, {{TProtocol}} or {{TTransport}}.
> - Avoid language-specific features, to ease implementation in other languages.
> *Additions to Thrift*
> Convenience class:
> - {{TProtocolDecorator}} (extends {{TProtocol}}). This is a no-op decorator around the {{TProtocol}} abstract class.
> For use by clients:
> - {{TMultiplexedProtocol}} (extends {{TProtocolDecorator}}). This decorates any {{TProtocol}} by modifying the behaviour of {{writeMessageBegin(TMessage)}} to change {{TMessage.name}} from {{function_name}} to {{service_name + separator + function_name}}.
> For use by the server:
> - {{TMultiplexedProcessor}} (implements {{TProcessor}}). It should be used to communicate with a client that was written using {{TMultiplexedProtocol}}. It removes {{service_name + separator}} from {{TMessage.name}}, turning it back into the standard message format. It then brokers the service request to the {{TProcessor}} which is registered to handle requests for that service.
> *Sample Usage - Client*
> In this example, we've chosen to use {{TBinaryProtocol}} with two services: {{Calculator}} and {{WeatherReport}}.
> {code}
> TSocket transport = new TSocket("localhost", 9090);
> transport.open();
> TBinaryProtocol protocol = new TBinaryProtocol(transport);
> TMultiplexedProtocol mp = new TMultiplexedProtocol(protocol, "Calculator");
> Calculator.Client service = new Calculator.Client(mp);
> TMultiplexedProtocol mp2 = new TMultiplexedProtocol(protocol, "WeatherReport");
> WeatherReport.Client service2 = new WeatherReport.Client(mp2);
> System.out.println(service.add(2,2));
> System.out.println(service2.getTemperature());
> {code}
> *Sample Usage - Server*
> {code}
> TMultiplexedProcessor processor = new TMultiplexedProcessor();
> processor.registerProcessor(
> "Calculator",
> new Calculator.Processor(new CalculatorHandler()));
> processor.registerProcessor(
> "WeatherReport",
> new WeatherReport.Processor(new WeatherReportHandler()));
> TServerTransport t = new TServerSocket(9090);
> TSimpleServer server = new TSimpleServer(processor, t);
> server.serve();
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.