As Solidity is used to create Smart Contracts in Ethereum, Which language is used to create a smart contract in Hyperledger Composer?
For business networks, ecmascript (commonly referred to as javascript) is the language supported by composer. It supports ecmascript 6 and also includes support for async/await. Node v8 is used as the runtime.
For client side there is a client SDK again for ecmascript, but also a rest server and so you can develop client applications in whatever language you prefer when interacting with the composer rest server.
Related
Both Hyperledger Aries and Hyperledger Indy are platforms for building distributed ledger applications
for identities.
What are the main differences between them? When to choose one over the other to implement a blockchain solution?
Aries is the agent (client) part of a decentralized identity (ledger, DIDs, verifiable credentials) application that is intended to be agnostic to the underlying ledger/DIDs/verifiable credentials layer.
Indy is a decentralized identity implementation including support for a ledger, DIDs and verifiable credentials.
Initial Aries work was to move the agent work in Indy to Aries, and so the first working versions of Aries use Indy underneath for the decentralized identity components. Over time, those components will become pluggable, and additional decentralized identity components will be supported. Thus, major parts of the indy-sdk will be deprecated, as they are implemented in Aries.
For building solutions, you should always be looking at Aries to start. You will need to know what Indy does, but not the details. The only time you would need to dive into Indy is if you what to extend its capabilities to support your use case.
The question is clear, what choice to make between Aries and Indy, we could also rephrase as follows: where to start from?
Indy represents, certainly, a base layer, Aries, at the moment, is the better choice for building identity app. Indy, infact, provides: Blockchain network, DID’s implementation, and all features related to verifiable credentials. Aries, on top of it, helps to build apps which can communicate over peer to peer network through secured communication channel: DIDComm. From the user interaction point of view, Aries is integrated with identity apps and internally talks to Indy. Aim of Aries, obviousely, is to build an interoperable communication layer that can be connected not only to Indy but also others blockchains framework.
Indy, as the first project in the Hyperledger family to build a decentralized identity, offers a real-time view of the transactions and its architecture is based on self-sovereign identity which enables users to have complete control over their identity. At the very beginning Indy was good to build an identity solution but, clearly, it lacks a peer to peer communication which is the heart of identity solution. Aries has filled this part. For building solutions there are lots of things that need to be considered but you should look at Aries to start
For building a decentralized identity solution, Hyperledger Indy project was started. Evernym has donated the codebase to Hyperledger community and thus Indy was born.
In initial architecture, Indy was supposed to provide governance (Consensus), Verifiable Credentials, DID, and DID Communication between different entities and Hyperledger Indy has provided all the above except DID Communication which later gave birth to Hyperledger Aries.
Indy Journey
Now the question is why don't Indy itself provide DID comm feature rather than relying on Aries
1: Hyperledger projects support plug and play architecture, detaching DID communication is a good decision for Indy to focus more on core identity party and Hyperledger Ursa was created for same reason to detach all cryptographic features from Indy.
2: Identity is a fundamental right of citizens, so in later times there would be thousands of service providers who offer Identity solutions and Interoperability would be a key factor. Keeping in mind, building a Ledger agnostic based clients is a good idea where Aries not only support Indy but it will support other Blockchain ledgers too.
So putting all pieces together, Indy is providing a core identity feature where Aries is just one of the clients who is availing those services. It is the same as the relation between Ethereum (Indy) and Web3 (Aries). For a development perspective, we need to be more focused on Aries to develop client apps.
in layman's:
Aries is for communication between agents
Indy is for cryptographic
transactions (issuance/proofing/etc)
Aries primarily covers the agent part of Hyperledger Indy, which has been initially cevered by Indy-Sdk. It supports connections to other Blockchains (For now it's only for Indy ledger).
Whereas Indy covers the blockchain part as of now.
I'm evaluating the use of Spring-Cloud-DataFlow. I'm wondering why do it supports the use of Kafka and RabitMQ but does not support JMS? Is there a technical reasons? or is it just a mater of contributing and add the JMS support?
There is a variety of JMS-spec implementation from different vendors. In fact, we have an implementation for IBM MQ, Solace and ActiveMQ.
As for the support, since JMS is a spec and there is a variety of vendor-specific investments in the enterprise, we (spring) didn't want to ship binaries that involve vendor-specific licensing terms, so we have opened it up with the partners to support them instead. Example: Solace built a supported version of Solace PubSub+ implementation, and that's hosted in their GitHub, too.
Google PubSub and Azure Event Hubs are the other binder implementations, and they are supported and maintained by them directly. More details here.
Lastly, from SCDF point-of-view, if the Spring Cloud Stream applications are bundled with the particular binder implementation, there's nothing extra required for SCDF. The SCDF-server orchestrates the deployment of the Spring Cloud Stream applications on the targeted platform.
I am familiar with the Concept of amazon SWF . I can see many SDK in different languages to use SWF services. Also, amazon Flow Framework is a set of library to implement distributed applications . Currently this Flow Framework is available in Java and Ruby . Then how can we write distributed applications using SWF in other languages like python , php etc. Does this mean amazon provides the framework in Java and Ruby only , rest of the languages have other vendor's libraries ? Please explain .
You are right that AWS currently only provides high-level frameworks for Ruby and Java ("Flow" frameworks). Low-level access to SWF is available in most (all?) official SDKs though: boto2/3 for Python, go-sdk, etc.
When using SWF, you'll find yourself implementing mainly two types of programs: "activity workers" and "deciders" (http://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-dev-actors.html).
Using the Flow framework is not mandatory, but it helps implementing deciders by providing high-level abstractions for describing synchronisation points, defining which tasks can be run in parallel, retries, etc. There are also non-official libraries (I'm personally maintaining one for my company, "simpleflow").
If you want to use other languages for deciders, I recommend you try to use an existing framework first, then see if you want to implement this yourself (it's not trivial from my experience).
If you want to implement activities in other languages, I recommend you start using the Flow framework end-to-end, and then you can either 1/ fork and use your favorite language as a subprocess of Ruby/Java Flow workers, or 2/ mimic the serialisation logic of the Flow framework and implement workers directly yourself with low-level APIs (which is simple: poll for an activity, do work, then respond to SWF with the result).
I have previous experience in using Ethereum and Solidity, but now I want to try writing smart contracts for Hyperledger.
I have few considerations:
First one is regarding supported databases. According to their documentation (http://hyperledger-fabric.readthedocs.io/en/latest/ledger.html) they use LevelDB for storing contract data and CouchDB support is still in beta. Does anyone have any experience using CouchDB in Hyperledger?
Second, I see that Go is mostly used for the specification of smart contracts, but they have support for Java too. Is Java still in beta too, and is there support for any other programming language?
Also, what operating system do you suggest for production server running Hyperledger?
Thank you for the answers.
Is Java still in beta too, and is there support for any other
programming language?
Hyperledger V1.0 doesn't support Java Chaincode.
There will be support for it in the future.
You can ask around in https://chat.hyperledger.org/channel/fabric for ETAs.
There is also a work in progress to have node.js support.
Also, what operating system do you suggest for production server
running Hyperledger?
Ubuntu 16.04 LTS works well
Does anyone have any experience using CouchDB in Hyperledger?
Yes, CouchDB works well if your data is modeled as JSON and you would like to query the content of the data. The default goleveldb state database only supports key-based queries.
You should take a look at Hyperleger Composer that helps you create blockchain applications on Hyperledger Fabric quite easy. (It works better with Ubuntu).
It has is own Modeling Language.
Hyperledger initially was build using Go language.
the aim of the hyperledger team is to support as many languages as possible. currently the hyperledger composer( tool for developing blockchain application) supports javascript for defining the assets, transactions and chaincode.
the transactions log, state data and backed by Level DB and Couch DB
Note :
LevelDB and CouchDB are fully integrated in fabric framework,
currently you can't replace them with other database
Chaincode runs in a secured Docker container, the chaincode (aka smart-contract)can be programmed in Go,Node,Java currently Go is stable and fully supported language.
considering the operating system i have tested the fabric network running on Microsoft Azure platform where created a image of ubuntu 16.04 and installed Fabric framework.till now got no issue on it.
How does AppDynamics and similar problems retrieve data from apps ? I read somewhere here on SO that it is based on bytecode injection, but is there some official or reliable source to this information ?
Data retrieval by APM tools is done in several ways, each one with its pros and cons
Bytecode injection (for both Java and .NET) is one technique, which is somewhat intrusive but allows you to get data from places the application owner (or even 3rd party frameworks) did not intend to allow.
Native function interception is similar to bytecode injection, but allows you to intercept unmanaged code
Application plugins - some applications (e.g. Apache, IIS) give access to monitoring and application information via a well-documented APIs and plugin architecture
Network sniffing allows you to see all the communication to/from the monitored machine
OS specific un/documented APIs - just like application plugins, but for the Windows/*nix
Disclaimer : I work for Correlsense, provider of APM software SharePath, which uses all of the above methods to give you complete end-to-end transaction visibility.