The Composer's model consists of javascript code, entities, query definitions, and access rules. As I understand, everything becomes some kind of executable code after deployment, since Fabric doesn't have anything like that.
What exactly is happening during the deployment process? Is everything compiled into a sort of bytecode? For example, Composer's transaction functions are somehow becoming a part of the Fabric's Invoke method, but how exactly one maps onto the other?
I am asking because I want to add a capability to Composer to run js-based queries, and they need to be somehow mapped to the Fabric's Query method.
You need to study the architecture of Hyperledger Composer.
What you are looking for is the composer-runtime which interact with the underlaying Fabric.
Check out these slides :
link
Related
I am currently trying to learn Hyperledger Fabric , I managed to understand how to setup the network (Orderers, Peers, etc.) but now comes the part of the chaincode.
But, I found two different git repos for (what I understand) can be used to create chaincodes.
The first One being the fabric-contract-api-go, I followed their tutorials a while ago.
And the second one being the fabric-chaincode-go.
So my question is, what is the difference between these two packages, and which one should I use for writing chaincodes? Do you have resources or good examples? (other than the ones in the fabric-samples git)
I followed the fabric-contract-api tutorial and wrote a chaincode a while ago, but now I see people using the fabric-chaincode-go package, and I am a bit lost.
I am sorry, this question might sound stupid, but I don't have a Developer background. I have a SysAdmin background, and not used to GOLANG (but I am a fast learner, given to good resources).
You can think of fabric-contract-api-go as a high-level api that builds on/requires the low-level api fabric-chaincode-go.
It's possible to write golang chaincode using only the low-level api - in fact, this was the only option before Fabric 2.0, when the contract api was also added for golang. Previously, it only existed for node and java chaincode.
If you have the option to use the contract api, doing so will e.g. save you some boiler plate code.
To see the difference, you can e.g. compare the fabcar example: in the 1.4 branch, it used the low-level api (shim). In the master branch however it uses the new contract-api.
Hyperledger Composer is a platform for accelerating the development process of Business Network Application. Why is it deprecated and what are the alternatives to composer for development of BNAs?
According to IBM, there are following three problems with Hyperledger Composer:
Composer has been designed from the start to support multiple blockchain platforms, not just Fabric - but this design has come at a cost. This design has meant that there are two completely different programming models - the Fabric programming model (chaincode) and the Composer programming model (business networks). This has caused significant confusion to users, with them needing to make a "choice" between the two programming models, with very few similarities between the two. In this particular case choice has been a bad thing, with many users opting not to use the "optional" part past the initial exploration or POC stage.
This design has also made it a lot harder for us to adopt and expose the latest Fabric features. For example, one of the questions we are constantly getting at the moment is "when can I use the Fabric v1.2 private data feature with Composer?". Whilst we've taken some steps (getNativeAPI) to assist with this problem, it is extremely difficult for us to keep up with and aligned with the latest features in Fabric when we are trying to maintain a design that keeps us blockchain platform independent. This has meant that users have understandably stopped using Composer and instead have reverted to developing with Fabric.
Finally, those of you that have used Composer will likely be fans of our simple, easy-to-use APIs (JavaScript and REST) for building applications that interact with a blockchain network. There is a lot of code behind the scenes to enable these APIs that doesn't really belong in Composer. What we have ended up doing is glossing over the underlying, low-level Fabric APIs instead of pushing improvements directly into these Fabric APIs. Today it takes ~50 lines of code to submit a transaction using the Fabric APIs, whilst in Composer it takes ~5 lines of code, and that's wrong - Composer's value should not come from just making Fabric easier to use.
Please read this for details.
The only problem with Composer is that IBM, et al abandoned it. Composer was (to an extent kind of still is) an effective way for users of Fabric to proof of concept (POC) business solutions for prospective customers -- and for users wanting to justify internal budgets to attempt to deploy projects internally. Using real-world business logic.
Composer should be the business logic stack that sits on top of Fabric and allows users to deploy without having to get down into the weeds.
I don't need to know that I need an orderer or CA for every org -- but I do need to know that I have 6 orgs who will participate in my network, two of them need to communicate using private data on a separate channel from the others and I do need to know what my business use cases rules are. An automated tool or script should allow me to launch an internal network **locally* and go from there. Yes, I will need to know fabric details or have someone on hand that does to be able to tweak my networks -- but Composer let me POC these.
There is no -- as in zero -- equivalent for Fabric -- in fact there is no tool to allow one to easily clone fabric samples for their own use and easily plug in their own network / org settings.
And the IBM VS Code plugin tool is garbage if you're wanting to setup an internal, standalone network without going to the IBM cloud. Really? Seriously?
Without Composer -- or a tool like it -- investing in Hyperledger Fabric is a huge financial & resource gamble and time sink. Period. The code changes almost weekly, there are significant bugs, the community is reticent to fix what at times are glaring documentation issues and address hardware sizing issues. Not to mention the cost to assign engineers and software architects to test what is not-yet-ready-for-prime-time software. Forget the amount of time that is needed to just get familiar with the documentation and fabric components to be able to architect business-grade networks.
Regarding the points made in the answer above:
There should be two distinct programming models because the BNA approach works from a business deployment point of view. To say that having a Composer stack with it's API on top of Fabric "confuses" users is like the old saying "if the customer is too stupid to know how to use the deeply technical product the customer is too stupid" -- that's fundamentally wrong.
I shouldn't have to refresh my knowledge of combustion engines every time I get into a vehicle and press the start button -- I know where I have to go, how I will get there and know how to operate the vehicle to do so. And if I want to tweak or otherwise modify the vehicle, its engine, electrical system, etc. I get out the equivalent of fabric documentation and learn to use those tools or hire a mechanic that already knows how to use them.
And the design did not make it harder to adopt and expose the latest features of Fabric -- what the development team failed to do was to implement those features in Composer in lock step with releases of Fabric. This was a dev team deployment issue and not an end user issue. And to say -- not imply, say -- that the community didn't step up to the plate was a load of crap. If IBM wanted to support it, it could have - it has the personnel, financial and global resources to do so.
Within real-world settings the business perspective of blockchain / distributed ledger viability for enterprise applications is less than enthusiastic -- in fact it's doubtful at best. The number one compliant we get from prospects globally (NA, EMEA) is no one can adequately demo this. No kidding -- showing a prospect via a terminal window that car ownership can move from one user to another is going to solve their business needs? Really? Via a terminal window no less.
For us to POC a complex use case and be able to back of the napkin demo it we now have to write entire fabric apps or hope we can cobble through fixing a fabric samples example -- and in the process work through the bugs in samples.
We've spent hundreds upon hundreds of hours building out POC use cases only to have Composer go by the way side, Fabric version x not work with the just released Fabric version xx, have prerequisite software versions change or issues with god forbid Raft or Kafka that haven't been fully tested prior to "alpha" next greatest thing Fabric release. etc., etc, etc.
And to the writers last point above -- the value of Composer should absolutely be making Fabric easier to use for basic network stand up and POCs. No one is suggesting that getting into the weeds with Fabric is a bad thing -- but from a BUSINESS point of view having something like Composer to POC before committing to projects it's essential.
Will we continue to work with Fabric and hope that the development team catches up with real-world business needs -- probably. All those IBM and other training sessions for composer we've put employees through for the most part have been a waste.
So, from a team who is trying so very hard to justify what is good about Hyperledger and Fabric -- please don't just sack something like Composer in the future. Because we're not going to invest in personnel and train them if this is just the next big thing to go by the wayside. I have 15 teams deployed with prospects globally working prospective use cases and implementations -- trying to tweak and push customer-centric use case demos to them has been Hyperledger Fabric hell.
One persons rather small opinion. GR
I think the reasons are clear from the previous comments, but for your last question one option hundreds of devs are taking is using Convector. Convector is a Hyperledger Labs project that was created before Hyperledger Composer was deprecated but that looks similar to developers. It follows a model controller pattern (similar to Composer assets and transactions) however it compiles natively to Fabric code and does not create a runtime.
Code created with Convector can be taken to production and include all sorts of helpers like an API generator, a development environment bootstrapper (one command to create a local network), decorators for making models more predictable, unit tests by default (CI/CD friendly), tens of code samples and real-life projects to use as reference.
Convector has a community of hundreds of devs, some of them migrated from Composer rather easily, others it is the first tool they get to know for Fabric. The main difference about why Convector won't go away anytime soon even if it looks and feels similar to Composer is its decoupled architecture and capability to use and run natively with Fabric.
If you'd like to join the community there people will help you migrate from Composer to Convector. You can join here.
Here's a blog post mapping concepts from Hyperledger Composer to Convector.
Small recap about Convector:
Looks familiar to Hyperledger Composer.
Same code can be taken to production.
Run natively and scales natively with Fabric.
An ecosystem of tools: unit tests, developer environment, API generator, etc.
Great and friendly community in Discord.
--
Disclaimer: I work with Covalent, the developers of Convector. Convector is a free open source Apache 2.0 group of projects.
I am developing a business network with hyperledger composer. I have followed the tutorial on composer web site at composer playground and have made the tutorial-network as well. Now I am facing one issue. after finishing defining your business network, how is it possible to get the underlying Fabric code that is generated? I can't think of a reason why it should be necessary to have it directly, but lets say if for any reason, like having to give Fabric code to your customer for whom you have developed a poc, you need to have that. Is Fabric code being saved somewhere? I have looked into the business network folder; there are only subfolders for models, test, the business network itself, and after you generate the archive file there is only one file with .bna extension. Nothing related to Fabric there!
I appreciate your help.
As part of the deployment of your business network, an associated Composer runtime is included that can parse model files, query file and acl files, it is also capable of executing your transaction processor functions. In 0.16.x this was achieved by including a JavaScript VM implementation using Go Chaincode to execute the Composer runtime (written in JavaScript) and the transaction processor functions. In Fabric 1.1, chaincode can be written natively as it now supports Node.js chaincode so with Composer beyond 0.16.x (currently 0.19.x at the time of writing) Composer utilizes this and all Go chaincode it used to contain was removed, along with the Javascript VM. It's the composer runtime that parses the model, query and acl files, and the transaction processor functions run natively inside the node.js fabric chaincode container. Nothing is ever compiled to Go.
The smart contract will be saved in different manner in fabric, as composer is just an abstraction over it. You need to search for the location where the chaincode is present inside the peer. There are some chaincode related commands which can help you in finding out where the chain code is installed. And to the client you can give the .bna file if you are using composer for the development because I am not sure whether the code will be easily readable at fabric level if you are using composer.
I have just started working with Hyperledger Fabric. I was looking for a tool that would demonstrate graphically the entire network and its operations.
Is there any existing project that does that?
If not, I intend to create one. Would anyone like to collaborate?
As a starting point, I am looking at using http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html . I understand that it will be worth including the following:
Organizations
MSPs
CAs
Peers
Channels
(please add to this list)
Looking through the APIs, I am trying to figure out the starting point. I was hoping to find something like Client.getOrganisations() to get a list of all organisations on the network, but it doesnt seem to exist. Any ideas how to discover all Organisations using the Node SDK?
Entities in Hyperledger Fabric usually executed with Docker,Docker Swarm or Kubernetes environments, hence I'd suggest to take a look on Weave Scope project which could provide quite good visualization for your docker containers deployment.
I have been working on hyperledger fabric for some time. But I don’t understand where hyperledger composer comes in place . I do understand that it helps in visualizing the logic and transaction. But what I don’t get is how do you integrate it with fabric network? what does it create? Is it chaincode if not then what?
The Compose runtime is chain code that executes the business network archive artefacts created by the end-user.
Perhaps this will help?
https://blog.selman.org/2017/07/08/getting-started-with-blockchain-development/
The tech answer is that Hyperledger Composer is an abstraction layer over Hyperledger Fabric.
The practical answer is that it is awesome. Think how Angular and hundreds of other frameworks make web programming easier.
It is a framework where you can write your blockchain in Javascript and specify your data objects in an easy to understand text file. Throw in some querying, ACL stuff and pathways to use some nice opensource tools that let you do things like generate a Web API automatically and play around in a web environment without installing anything.
We are using it for the Integra Ledger Legal blockchain. (www.integraledger.com). I just spent the day working in it.