[
https://issues.apache.org/jira/browse/DUBBO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albumen Kevin updated DUBBO-137:
--------------------------------
Description:
h2. Unified IDL control for multiple protocols
Client and Server layer APIs can support both IDL and Non-IDL modes.
For IDL mode(Triple + Protobuf), defining proto file and making use of
protoc-gen-go-triple to generate related code are straightforward. Generated
code(XXX.triple.go) would contain statements that invoking APIs provided by
Client and Server layers.
For Non-IDL mode, it needs users to write invoking code by themselves and is
not convenient. Take Dubbo+Hessian2 as example:
Client Side
{code:go}
Cli, err := client.NewClient()
cli, err := client.NewClient(
client.WithClientProtocolDubbo(), )
)
withClientProtocolDubbo(), ) if err ! = nil {
panic(err)
}
conn, err := cli.Dial("GreetProvider",
client.WithURL("127.0.0.1:20000"), )
)
if err ! = nil {
panic(err)
}
var resp string
if err := conn.CallUnary(context.Background(), []interface{}{"hello",
"new", "dubbo"}, &resp, "Greet"); err ! = nil {
logger.Errorf("GreetProvider.Greet err: %s", err)
errorf("GreetProvider.Greet err: %s", err)
}
{code}
Server Side
{code:go}
GreetProvider.
type GreetProvider struct {
}
func (*GreetProvider) Greet(req string, req1 string, req2 string) (string,
error) {
return req + req1 + req2, nil
}
srv, err := server.NewServer(
server.WithServerProtocol(
protocol.WithDubbo(), protocol.WithPort(20000))
protocol.WithPort(20000),
),
)
if err ! = nil {
panic(err)
}
if err := srv.Register(&GreetProvider{}, nil,
server.WithInterface("GreetProvider")); err ! = nil {
panic(err)
}
if err := srv.Serve(); err ! = nil {
panic(err)
}
{code}
h3. Proposal
Even in Non-IDL mode, code is generated using protobuf IDL. In this way,
whether you need schema (Protobuf) or not (Hessian2, Msgpack), it's all
uniformly used: Protobuf IDL + generated code.
h3.Details:
1. Generate Dubbo + Hessian2 related code with the help of Protobuf IDL.
Compared to XXX.pb.go, XXX.hessian2.go would have much less content (due to
Hessian2 schema-free), only structure definitions and the corresponding
registration function (hessian2.Register(POJO)).
2. Non-IDL (Hessian2) may not map perfectly to Protobuf IDL, and we need to
define our own dialect in a way that is compatible with the official semantics
of Protobuf IDL
3. XXX.dubbo.go content is basically similar to XXX.triple.go, generating code
that uses the APIs of Client layer and Server layer.
h3. Prerequisite:
1. Provide tools for Dubbo side users to automatically convert Dubbo interface
definitions into Protobuf IDL.
2. Protobuf IDL can support extensions (add Hessian2-specific tag extensions,
generate Hessian2-specific content)
h3. Results:
Not only Dubbo + Hessian2, but also Triple + Hessian2, Triple + Json and other
Non-IDLs can use the interface in a unified way.
h3. Mentor
* Mentor: Albumen Kevin, Apache Dubbo PMC, [email protected]
* Mailing List: [email protected]
h4.
was:
## Unified IDL control for multiple protocols
```Client``` and ```Server``` layer APIs can support both IDL and Non-IDL modes.
For IDL mode(Triple + Protobuf), defining proto file and making use of
protoc-gen-go-triple to generate related code are straightforward. Generated
code(XXX.triple.go) would contain statements that invoking APIs provided by
```Client``` and ```Server``` layers.
For Non-IDL mode, it needs users to write invoking code by themselves and is
not convenient. Take Dubbo+Hessian2 as example:
Client Side
```
Cli, err := client.NewClient()
cli, err := client.NewClient(
client.WithClientProtocolDubbo(), )
)
withClientProtocolDubbo(), ) if err ! = nil {
panic(err)
}
conn, err := cli.Dial("GreetProvider",
client.WithURL("127.0.0.1:20000"), )
)
if err ! = nil {
panic(err)
}
var resp string
if err := conn.CallUnary(context.Background(), []interface{}{"hello",
"new", "dubbo"}, &resp, "Greet"); err ! = nil {
logger.Errorf("GreetProvider.Greet err: %s", err)
errorf("GreetProvider.Greet err: %s", err)
}
```
Server Side
```
GreetProvider.
type GreetProvider struct {
}
func (*GreetProvider) Greet(req string, req1 string, req2 string) (string,
error) {
return req + req1 + req2, nil
}
srv, err := server.NewServer(
server.WithServerProtocol(
protocol.WithDubbo(), protocol.WithPort(20000))
protocol.WithPort(20000),
),
)
if err ! = nil {
panic(err)
}
if err := srv.Register(&GreetProvider{}, nil,
server.WithInterface("GreetProvider")); err ! = nil {
panic(err)
}
if err := srv.Serve(); err ! = nil {
panic(err)
}
```
### Proposal
Even in Non-IDL mode, code is generated using protobuf IDL. In this way,
whether you need schema (Protobuf) or not (Hessian2, Msgpack), it's all
uniformly used: Protobuf IDL + generated code.
### Details:
1. Generate Dubbo + Hessian2 related code with the help of Protobuf IDL.
Compared to XXX.pb.go, XXX.hessian2.go would have much less content (due to
Hessian2 schema-free), only structure definitions and the corresponding
registration function (hessian2.Register(POJO)).
2. Non-IDL (Hessian2) may not map perfectly to Protobuf IDL, and we need to
define our own dialect in a way that is compatible with the official semantics
of Protobuf IDL
3. XXX.dubbo.go content is basically similar to XXX.triple.go, generating code
that uses the APIs of ```Client``` layer and ```Server``` layer.
### Prerequisite:
1. Provide tools for Dubbo side users to automatically convert Dubbo interface
definitions into Protobuf IDL.
2. Protobuf IDL can support extensions (add Hessian2-specific tag extensions,
generate Hessian2-specific content)
### Results:
Not only Dubbo + Hessian2, but also Triple + Hessian2, Triple + Json and other
Non-IDLs can use the interface in a unified way.
h3. Mentor
* Mentor: Albumen Kevin, Apache Dubbo PMC, [email protected]
* Mailing List: [email protected]
h4.
> Unified IDL control for multiple protocols
> ------------------------------------------
>
> Key: DUBBO-137
> URL: https://issues.apache.org/jira/browse/DUBBO-137
> Project: Apache Dubbo
> Issue Type: New Feature
> Reporter: Albumen Kevin
> Priority: Major
> Labels: AI, Dubbo, full-time, gsoc2024
>
> h2. Unified IDL control for multiple protocols
> Client and Server layer APIs can support both IDL and Non-IDL modes.
> For IDL mode(Triple + Protobuf), defining proto file and making use of
> protoc-gen-go-triple to generate related code are straightforward. Generated
> code(XXX.triple.go) would contain statements that invoking APIs provided by
> Client and Server layers.
> For Non-IDL mode, it needs users to write invoking code by themselves and is
> not convenient. Take Dubbo+Hessian2 as example:
> Client Side
> {code:go}
> Cli, err := client.NewClient()
> cli, err := client.NewClient(
> client.WithClientProtocolDubbo(), )
> )
> withClientProtocolDubbo(), ) if err ! = nil {
> panic(err)
> }
> conn, err := cli.Dial("GreetProvider",
> client.WithURL("127.0.0.1:20000"), )
> )
> if err ! = nil {
> panic(err)
> }
> var resp string
> if err := conn.CallUnary(context.Background(), []interface{}{"hello",
> "new", "dubbo"}, &resp, "Greet"); err ! = nil {
> logger.Errorf("GreetProvider.Greet err: %s", err)
> errorf("GreetProvider.Greet err: %s", err)
> }
> {code}
> Server Side
> {code:go}
> GreetProvider.
> type GreetProvider struct {
> }
> func (*GreetProvider) Greet(req string, req1 string, req2 string) (string,
> error) {
> return req + req1 + req2, nil
> }
> srv, err := server.NewServer(
> server.WithServerProtocol(
> protocol.WithDubbo(), protocol.WithPort(20000))
> protocol.WithPort(20000),
> ),
> )
> if err ! = nil {
> panic(err)
> }
> if err := srv.Register(&GreetProvider{}, nil,
> server.WithInterface("GreetProvider")); err ! = nil {
> panic(err)
> }
> if err := srv.Serve(); err ! = nil {
> panic(err)
> }
> {code}
> h3. Proposal
> Even in Non-IDL mode, code is generated using protobuf IDL. In this way,
> whether you need schema (Protobuf) or not (Hessian2, Msgpack), it's all
> uniformly used: Protobuf IDL + generated code.
> h3.Details:
> 1. Generate Dubbo + Hessian2 related code with the help of Protobuf IDL.
> Compared to XXX.pb.go, XXX.hessian2.go would have much less content (due to
> Hessian2 schema-free), only structure definitions and the corresponding
> registration function (hessian2.Register(POJO)).
> 2. Non-IDL (Hessian2) may not map perfectly to Protobuf IDL, and we need to
> define our own dialect in a way that is compatible with the official
> semantics of Protobuf IDL
> 3. XXX.dubbo.go content is basically similar to XXX.triple.go, generating
> code that uses the APIs of Client layer and Server layer.
> h3. Prerequisite:
> 1. Provide tools for Dubbo side users to automatically convert Dubbo
> interface definitions into Protobuf IDL.
> 2. Protobuf IDL can support extensions (add Hessian2-specific tag extensions,
> generate Hessian2-specific content)
> h3. Results:
> Not only Dubbo + Hessian2, but also Triple + Hessian2, Triple + Json and
> other Non-IDLs can use the interface in a unified way.
> h3. Mentor
> * Mentor: Albumen Kevin, Apache Dubbo PMC, [email protected]
> * Mailing List: [email protected]
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
