New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-Channel Support #2103

Open
naveensachdeva opened this Issue Sep 9, 2017 · 19 comments

Comments

Projects
None yet
@naveensachdeva

naveensachdeva commented Sep 9, 2017

Currently a composer connection profile is specific to a channel i.e. only one channel can be specified in the connection profile. This makes it difficult to build an app that has to access multiple channels. For example, if a Buyer has many Suppliers and there is one Channel per Supplier, then a Buyer app would require multiple connection profiles and multiple rest server instances, and it has to be aware of the Supplier-Channel/REST Server endpoint mapping and would need to switch from one REST server URL to another based on the Supplier.
It becomes more complex if the REST Server is Multi-User enabled because now the same Buyer participant has to be created and bound to the corresponding identity multiple times (once for each Channel that Buyer is part of), the buyer participant has to manage multiple wallets (one per REST server), and the buyer participant has to login multiple times (once per REST server).

As a user, I should be able to use one connection profile across multiple channels.

As a user, I should be able to use one REST server across multiple channels.

As a user, I should be able to create a Participant-Identity mapping that can be used across multiple channels.

As a user, I should be able to create, delete, and query Channel-Participants mappings.

@sstone1

This comment has been minimized.

Show comment
Hide comment
@sstone1

sstone1 Sep 11, 2017

Contributor

This is not just a matter of specifying a different channel. Each connection profile must contain a list of all of the peers that should be used during endorsement, including those in organisations. In a multiple channel configuration, it is highly likely that each channel will have a different set of endorsing peers, and so you will end up needing different connection profiles.

Contributor

sstone1 commented Sep 11, 2017

This is not just a matter of specifying a different channel. Each connection profile must contain a list of all of the peers that should be used during endorsement, including those in organisations. In a multiple channel configuration, it is highly likely that each channel will have a different set of endorsing peers, and so you will end up needing different connection profiles.

@naveensachdeva

This comment has been minimized.

Show comment
Hide comment
@naveensachdeva

naveensachdeva Sep 11, 2017

I agree that each channel can have different set of endorsing peers but that doesn't have to mean different connection profiles. A connection profile can contain a list of all the endorsing peers (across multiple channels) and the channels, and the channels can refer to the corresponding endorsing peers.

naveensachdeva commented Sep 11, 2017

I agree that each channel can have different set of endorsing peers but that doesn't have to mean different connection profiles. A connection profile can contain a list of all the endorsing peers (across multiple channels) and the channels, and the channels can refer to the corresponding endorsing peers.

@davidkel

This comment has been minimized.

Show comment
Hide comment
@davidkel

davidkel Oct 30, 2017

Contributor

The Common connection profile provides the required definition to allow a single profile to define more than 1 channel however work within the runtime, apis, cli and playground would be needed to allow the selection of which channel to interact with.

Contributor

davidkel commented Oct 30, 2017

The Common connection profile provides the required definition to allow a single profile to define more than 1 channel however work within the runtime, apis, cli and playground would be needed to allow the selection of which channel to interact with.

@chevdor

This comment has been minimized.

Show comment
Hide comment
@chevdor

chevdor Nov 24, 2017

Contributor

Channel support is for many the reason to use Hyperledger Fabric. This is a very important feature and supporting it in Composer will greatly extend the list of use cases where Composer can be used in production. Without channel support, it will be hard.

Contributor

chevdor commented Nov 24, 2017

Channel support is for many the reason to use Hyperledger Fabric. This is a very important feature and supporting it in Composer will greatly extend the list of use cases where Composer can be used in production. Without channel support, it will be hard.

@sherlyseptiani

This comment has been minimized.

Show comment
Hide comment
@sherlyseptiani

sherlyseptiani Mar 1, 2018

We do have the same need, it will be great to support multi channel capabilities on composer

sherlyseptiani commented Mar 1, 2018

We do have the same need, it will be great to support multi channel capabilities on composer

@michael-iglesias

This comment has been minimized.

Show comment
Hide comment
@michael-iglesias

michael-iglesias Apr 10, 2018

Have you come across anything on when Composer will be introducing multi Channel support?

@chevdor @sherlyseptiani

michael-iglesias commented Apr 10, 2018

Have you come across anything on when Composer will be introducing multi Channel support?

@chevdor @sherlyseptiani

@christseng89

This comment has been minimized.

Show comment
Hide comment
@christseng89

christseng89 Apr 24, 2018

Without the support of multi-channel, the Composer might be used for PoC ONLY. If the multi-channel API can be supported, then the Composer can fly to production.

It is rather tedious and impossible to set up and maintain different channels to support different groups of Participants (for example 10 Banks, 100 Buyers, and 200 Suppliers requires 10 x 100 x 200 channels = 200,000 channels) of the same business logic in the real production environments.

Hope the Composer team can make it up. Thanks,

christseng89 commented Apr 24, 2018

Without the support of multi-channel, the Composer might be used for PoC ONLY. If the multi-channel API can be supported, then the Composer can fly to production.

It is rather tedious and impossible to set up and maintain different channels to support different groups of Participants (for example 10 Banks, 100 Buyers, and 200 Suppliers requires 10 x 100 x 200 channels = 200,000 channels) of the same business logic in the real production environments.

Hope the Composer team can make it up. Thanks,

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Jun 23, 2018

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs in the next 14 days. Thank you for your contributions.

stale bot commented Jun 23, 2018

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs in the next 14 days. Thank you for your contributions.

@stale stale bot added the stale label Jun 23, 2018

@alexvicegrab

This comment has been minimized.

Show comment
Hide comment
@alexvicegrab

alexvicegrab Jun 23, 2018

Still relevant, we should keep this issue open

alexvicegrab commented Jun 23, 2018

Still relevant, we should keep this issue open

@stale stale bot removed the stale label Jun 23, 2018

@Weavor74

This comment has been minimized.

Show comment
Hide comment
@Weavor74

Weavor74 Jun 26, 2018

One of the reasons for the limited connection profile it seems is to keep this only as a POC system. This allows the maintainers to direct people too the paid product for hosting. I may be wrong but somehow it could probably be adjusted here

composer-playground/node_modules/composer-connector-hlfv1

Weavor74 commented Jun 26, 2018

One of the reasons for the limited connection profile it seems is to keep this only as a POC system. This allows the maintainers to direct people too the paid product for hosting. I may be wrong but somehow it could probably be adjusted here

composer-playground/node_modules/composer-connector-hlfv1

@sstone1

This comment has been minimized.

Show comment
Hide comment
@sstone1

sstone1 Jun 26, 2018

Contributor

@Weavor74 you're wrong, I'm afraid - nothing about any fantastic paid products will help you here ;-)

Each channel has its own set of instantiated chaincodes (deployed business networks), and each instantiated chaincode (deployed business network) on a channel has its own deployed world state.

For all intents and purposes, the chaincodes are two completely different chaincodes, can be at different versions, and can store completely different sets of data.

Chaincodes in different channels can share data via means of a chaincode to chaincode request, but this is read-only (for different channels), and so is of limited use.

The original user stories described are incredibly hard to implement, which is why we haven't done anything yet - everything with multiple channels is the same difficulty as base Fabric.

As a user, I should be able to use one connection profile across multiple channels.

Fair enough, you could have a massive connection profile which contains all channels, and all the endorsing peers for those channels. Sounds pretty horrible to manage which is why we're more interested in the Fabric service discovery feature for finding this information at runtime.

As a user, I should be able to use one REST server across multiple channels.

Which channel do the REST requests get routed to? If you have bilateral channels, then the channel is dependent on both the buyer and the seller (for a trade) in the incoming transaction. That's a significant amount of highly specific routing code that needs to be added somewhere.

As a user, I should be able to create a Participant-Identity mapping that can be used across multiple channels.

See point above about separated world state - you'd have to create participant-identity mappings in each instantiated chaincode's world state. Given one channel can't update another channel, for n channels that will result in n separate blockchain transactions to manage the mappings. How would you specify which channels you want to maintain mappings on?

As a user, I should be able to create, delete, and query Channel-Participants mappings.

See above.

Contributor

sstone1 commented Jun 26, 2018

@Weavor74 you're wrong, I'm afraid - nothing about any fantastic paid products will help you here ;-)

Each channel has its own set of instantiated chaincodes (deployed business networks), and each instantiated chaincode (deployed business network) on a channel has its own deployed world state.

For all intents and purposes, the chaincodes are two completely different chaincodes, can be at different versions, and can store completely different sets of data.

Chaincodes in different channels can share data via means of a chaincode to chaincode request, but this is read-only (for different channels), and so is of limited use.

The original user stories described are incredibly hard to implement, which is why we haven't done anything yet - everything with multiple channels is the same difficulty as base Fabric.

As a user, I should be able to use one connection profile across multiple channels.

Fair enough, you could have a massive connection profile which contains all channels, and all the endorsing peers for those channels. Sounds pretty horrible to manage which is why we're more interested in the Fabric service discovery feature for finding this information at runtime.

As a user, I should be able to use one REST server across multiple channels.

Which channel do the REST requests get routed to? If you have bilateral channels, then the channel is dependent on both the buyer and the seller (for a trade) in the incoming transaction. That's a significant amount of highly specific routing code that needs to be added somewhere.

As a user, I should be able to create a Participant-Identity mapping that can be used across multiple channels.

See point above about separated world state - you'd have to create participant-identity mappings in each instantiated chaincode's world state. Given one channel can't update another channel, for n channels that will result in n separate blockchain transactions to manage the mappings. How would you specify which channels you want to maintain mappings on?

As a user, I should be able to create, delete, and query Channel-Participants mappings.

See above.

@TangoJLabs

This comment has been minimized.

Show comment
Hide comment
@TangoJLabs

TangoJLabs Jul 3, 2018

@sstone1 I understand your concern that a single connection profile would be too complex:

As a user, I should be able to use one connection profile across multiple channels.

Fair enough, you could have a massive connection profile which contains all channels, and all the endorsing peers for those channels.

However, when you say:

. . .which is why we're more interested in the Fabric service discovery feature for finding this information at runtime.

...it sounds like you're implying that Service Discovery would somehow make multiple channel authentication easier. From what I understand, however, service discovery merely makes the Peer Endorser assignment easier to update since it's not hard-coded (some other network structure info as well). Can you explain a bit more how that would help simplify multiple channel complexities?

TangoJLabs commented Jul 3, 2018

@sstone1 I understand your concern that a single connection profile would be too complex:

As a user, I should be able to use one connection profile across multiple channels.

Fair enough, you could have a massive connection profile which contains all channels, and all the endorsing peers for those channels.

However, when you say:

. . .which is why we're more interested in the Fabric service discovery feature for finding this information at runtime.

...it sounds like you're implying that Service Discovery would somehow make multiple channel authentication easier. From what I understand, however, service discovery merely makes the Peer Endorser assignment easier to update since it's not hard-coded (some other network structure info as well). Can you explain a bit more how that would help simplify multiple channel complexities?

@sstone1

This comment has been minimized.

Show comment
Hide comment
@sstone1

sstone1 Jul 3, 2018

Contributor

@TangoJLabs the "dream" for service discovery is that eventually you can use a minimal set of connection information (your peer, your CA, and an identity/certificate) and using that you can connect to a Fabric network, discover all of the channels in that Fabric network, discover all of the chaincodes in those channels, and all of the peers in those channels that you need to endorse transactions.

Contributor

sstone1 commented Jul 3, 2018

@TangoJLabs the "dream" for service discovery is that eventually you can use a minimal set of connection information (your peer, your CA, and an identity/certificate) and using that you can connect to a Fabric network, discover all of the channels in that Fabric network, discover all of the chaincodes in those channels, and all of the peers in those channels that you need to endorse transactions.

@TangoJLabs

This comment has been minimized.

Show comment
Hide comment
@TangoJLabs

TangoJLabs Jul 3, 2018

@sstone1 That would be very helpful. Thanks for your work.

TangoJLabs commented Jul 3, 2018

@sstone1 That would be very helpful. Thanks for your work.

@davidkel davidkel removed the investigation label Aug 12, 2018

@crazyman1979

This comment has been minimized.

Show comment
Hide comment
@crazyman1979

crazyman1979 Sep 11, 2018

@sstone1
Can you clarify for me, if a connection profile currently contains a single channel - then there is some conflicting information here : https://hyperledger.github.io/composer/latest/tutorials/deploy-to-fabric-multi-org

The example shows a "channels" : [] array then in step 4 goes on to talk about place some client json between "version" and "channel": {} (singular)

Additionaly when hitting IBM cloud rest api /networks/networkId/connection_profile it does return multiple channels in "channels" : [] property, with this being the case how does the following work ?

Composer rest server uses a network card , this has a connection profile inside it right?- how does either the composer rest server or the card know which channel to use if the connection profile can be multiple?

Can you explain how multiple channels in a connection profile ends up being a single channel when rest server is started?
And how i might make this decision myself..

crazyman1979 commented Sep 11, 2018

@sstone1
Can you clarify for me, if a connection profile currently contains a single channel - then there is some conflicting information here : https://hyperledger.github.io/composer/latest/tutorials/deploy-to-fabric-multi-org

The example shows a "channels" : [] array then in step 4 goes on to talk about place some client json between "version" and "channel": {} (singular)

Additionaly when hitting IBM cloud rest api /networks/networkId/connection_profile it does return multiple channels in "channels" : [] property, with this being the case how does the following work ?

Composer rest server uses a network card , this has a connection profile inside it right?- how does either the composer rest server or the card know which channel to use if the connection profile can be multiple?

Can you explain how multiple channels in a connection profile ends up being a single channel when rest server is started?
And how i might make this decision myself..

@davidkel

This comment has been minimized.

Show comment
Hide comment
Contributor

davidkel commented Sep 11, 2018

@crazyman1979

This comment has been minimized.

Show comment
Hide comment
@crazyman1979

crazyman1979 Sep 11, 2018

@davidkel What i'm trying to understand is how composer-rest-server decides which channel to use when the connection profile contains multiple channels (which is what the ibm cloud rest api returns)

Am i to dump the connection profile to disk, remove channels i'm not interested in leaving my target channel only then create a card from the connection profile with the single channel and use that card for my composer rest server, seems very clunky...

crazyman1979 commented Sep 11, 2018

@davidkel What i'm trying to understand is how composer-rest-server decides which channel to use when the connection profile contains multiple channels (which is what the ibm cloud rest api returns)

Am i to dump the connection profile to disk, remove channels i'm not interested in leaving my target channel only then create a card from the connection profile with the single channel and use that card for my composer rest server, seems very clunky...

@davidkel

This comment has been minimized.

Show comment
Hide comment
@davidkel

davidkel Sep 11, 2018

Contributor

@crazyman1979 that's the best option. Composer doesn't decide which channel to use, it's all handled by the node-sdk as it owns and parses the connection profile. Composer asks for the first one (as it needs to know which channel to use) and the node-sdk presents one. Composer doesn't know if that is the first in the list, the last or some other order, so safest way is to make it deterministic by only having a single entry in the file. If you want to use the connection profile as is, and rely on the first one in the list being selected that's upto you. It's just that composer cannot guarantee the behaviour.

Contributor

davidkel commented Sep 11, 2018

@crazyman1979 that's the best option. Composer doesn't decide which channel to use, it's all handled by the node-sdk as it owns and parses the connection profile. Composer asks for the first one (as it needs to know which channel to use) and the node-sdk presents one. Composer doesn't know if that is the first in the list, the last or some other order, so safest way is to make it deterministic by only having a single entry in the file. If you want to use the connection profile as is, and rely on the first one in the list being selected that's upto you. It's just that composer cannot guarantee the behaviour.

@crazyman1979

This comment has been minimized.

Show comment
Hide comment
@crazyman1979

crazyman1979 commented Sep 11, 2018

@davidkel Thanks very much, after some digging i think ive found where this happens...

https://github.com/hyperledger/composer/blob/60261521cea0e714cc713967dee1aadd7a557dfe/packages/composer-connector-hlfv1/lib/hlfconnectionmanager.js

// this should return the first defined channel.
const channel = client.getChannel();

Which is in the SDK here :
https://github.com/hyperledger/fabric-sdk-node/blob/2cf701e87c1f4be8862f38cc4fca002c9c2a810d/fabric-client/lib/Client.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment