The JSDK 1.1 has features added since the 1.0 based release to match those added to the Fabric 1.1 release.
The SDK is mostly backward compatible with the v1.0 based Fabric with the following considerations
- The new Peer eventing service is the default for the SDK however, in v1.0 Fabric peer eventing service is not supported. To address in applications that are
connecting to Fabric 1.0 you must when adding or joining a peer to a channel provide a PeerRole option.
A role with
PeerRole.NO_EVENT_SOURCEhas been defined that has the equivalent functionality of a v1.0 peer. You can see an example of this in End2endIT.java#L732 and in End2endAndBackAgainIT.java#L597
The Fabric peer now implements eventing services on the same endpoint as proposal endorsements and it is no longer necessary to have an EventHub service. Using peer eventing is the preferred means for receiving events. Future releases of Fabric may not support Eventhubs. When joining or adding Peers to a channel the default is to have the peer provide the eventing service. Whether a peer is an eventing or non-eventing is controlled by the peer options when adding or joining a channel.You can see an example of this in End2endIT.java#L732 and in End2endAndBackAgainIT.java#L597
Peers may be added to a channel with specific roles to help with distributing the workload. PeerRoles are defined in Peer.java#L328 The default is for Peers to have all roles.
The new peer eventing services will by default just return the last block on the blockchain. Note this is not the next block that gets
added to the chain. The application can now specifiy both the starting and ending block number to be sent. Applications set these
options when adding or joining peers to the channel with the PeerOption methods startEvents, stopEvents and startEventsNewest which
is the default. End2endAndBackAgainIT.java#L234-L257
calls the method testPeerServiceEventingReplay which restarts the channel with different start and stop values.
Fabric supports on the new peer eventing service limits to what the events return thourgh ACLs. The block event may contain the full Block or a FilteredBlock. Applications requesting for a full Block without authority will get a permission failure. Application by default will get the full block. To request request a FiltedBlock when adding or joining peers applications can add via PeerOptions.registerEventsForFilteredBlocks. An example of this is seen in End2endAndBackAgainIT.java#L592-595
Application's that register block listeners need to be written to check for *isFiltered()" to know if the block is full or filtered.
Filtered blocks are limited to the following methods.
FilteredBlocks
- isFiltered should return true
- getChannelId the channel name
- getFilteredBlock the raw filtered block
- getBlockNumber blocknumber
- getEnvelopeCount number of envelopes
- getEnvelopeInfo index into envelopes.
- getEnvelopeInfos interator on envelopes
EnvelopeInfo
- getChannelId channel name
- getTransactionID the transaction id
- isValid was the transaction valid.
- getType the type of envelope
TransactionEnvelopeInfo all the methods on EnvelopeInfo
- getTransactionActionInfoCount number transactions
- getTransactionActionInfos an integrater over all the TransactionAction
TransactionActionInfo
- getEvent chaincode events
Changes made to make the Java SDK crypto primitives to use more JCA/JCE compliant methods. These changes are internal and not directly apparant to the application. This allows specifying other JCA/JCE provider.
Allow creating channels from a yaml or json specified document. Examples of this can be found in NetworkConfigIT.java#L65
Allow application to register for specific events triggered by chaincode. Example of this can be found in End2endIT.java#L303
The registerChaincodeEventListener method on the channel registers a call back that matches via a Java pattern on both the event name and the chaincodeId. When ledger block with an event that matches that criteria specified is found by event hub or new peer event service the callback is called to handle the event.
When installing chaincode, need to package CouchDB indexes in chaincode tar. See InstallProposalRequest.java#L35 Details for this can be found in the Fabric documentation Using CouchDB from Chaincode
Channels can be Java serialized and deserialized. Examples of this can be found throughout the integration tests. Example of serialization in End2endIT.java#L257 where the sample store stores channel bar. Later in End2endAndBackAgainIT.java#L562 it's restored. Applications using this serialziation means will be tasked with any migrating future changes. The SDK will not do this. It's advised to use a different persistene means for saving and restoring channels
The JSDK added support for installing deploying Node chaincode. Example of this integration tests show mostly overriding the GO chaincode EndendIT.java as they are mostly treated the same. See End2endNodeIT.java#L23
FAB-7949 fabric-sdk-java Utilize TLS binding information and timestamp in eventhub registration messages
Not directly exposed in the API, however when utilizing TLS mutual auth the client will add hashing of the client certificate in event registration for both peer eventing and Eventhub to prevent replay attacks.
Channel will now initialize without needing to connect to peers. There may still be warning and error messages. Even with the channel initialized however the lack of functioning Peers will possible prevent other operations from completing. If Peers come back online eventing services will reconnect.
On many APIs the addition of specifying a user context was added to allow thread safe invocation.
Many APIs where a peer was needed was enhanced to try all defined Peers till successful or all failed.
Enhanced application control over sending request to the orderer. Prior to this change all Java futures returned by sendTransation would only be completed when all channel defined Eventhubs and peer eventing services seen the block with the specific transaction. This is still the default, but now can be changed with TransactionOptions Example of this which mostly shows the defaults is in End2endIT.java#L517
Fabric CA API added APIs for managing identies and affiliations. Examples how this can be done with Java SDK on how to create, modify, read and delete are in HFCAClientIT.java#L514-L658 for identies and HFCAClientIT#L704 for affiliations.
Support for getting certificate revocation list from Fabric-ca was added to the HFCAClient's generateCRL method. Examples of this are in the integration tests that call HFCAClientIT.java getRevokes method