[jira] [Closed] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-17.
Resolution: Won't Fix
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-17.
Resolution: Fixed
has been removed to another repository
https://github.com/openmessaging/openmessaging
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
