mirror of
https://github.com/corda/corda.git
synced 2025-01-21 03:55:00 +00:00
Unix vs Windows demo instructions. Duplicate SIMM page. Typos. Bad nesting.
This commit is contained in:
Joel Dudley
GitHub
parent
592ac07af0
commit
b5c319aeca
@ -1,19 +1,19 @@
|
||||
CLI vs IDE
|
||||
==========
|
||||
|
||||
We have tried to make every demo, example, tutorial and sample to be both usuable via the command line and also the IntelliJ IDE.
|
||||
Most developers will find writing, editing and debugging code more easily done via tools such as an IDE, but when code needs
|
||||
to be deployed to run as nodes, control must be done via the command line - no organisations allow their systems to be running via
|
||||
We have tried to make every demo, example, tutorial and sample usable via both the command line and the IntelliJ IDE.
|
||||
Most developers will find writing, editing and debugging code more easy with tools such as an IDE. But when a production node
|
||||
is deployed, it will be controlled via the command line - no organisation allows their systems to be running via
|
||||
a developer environment.
|
||||
|
||||
IDE - IntelliJ
|
||||
--------------
|
||||
|
||||
IntelliJ (the preferred IDE in R3) integrates well with gradle (our chosed build, deploy and CLI tool). IntelliJ understands gradle
|
||||
tasks and dependencies, automatically loading them in the background when a project is first loaded or the gradle
|
||||
IntelliJ (R3's preferred IDE) integrates well with gradle (our chosen build, deployment and CLI tool). IntelliJ understands gradle
|
||||
tasks and dependencies, automatically loading them in the background when a project is first opened or the gradle
|
||||
project changes. Occasionally, however, you may need to refresh the gradle project manually - but this is hinted to you
|
||||
by the IDE. It's a good idea to do this before carrying on with other work (and in fact you may find it is essential to pick
|
||||
up new libraries etc).
|
||||
up new libraries, etc.).
|
||||
|
||||
There are some great resources about how to get started using IntelliJ. As opposed to trying to repeat them here, we advise
|
||||
you to go to the `IntelliJ docs here <https://www.jetbrains.com/idea/documentation/>`_.
|
||||
@ -32,22 +32,22 @@ As well as including the most significant run and build configurations in the ID
|
||||
and run significant parts of Corda demos and tools. Gradle is highly extensible and we use it for downloading required resources,
|
||||
building components, installing those built components into shared areas, configuring the scripts that run nodes, starting
|
||||
up demonstration API calls amongst other things. It is exceptionally good at deriving dependency maps and therefore performing
|
||||
the preceeding tasks required in order to do the requested task. However, when confusing build errors manifest, then sometimes
|
||||
the preceding tasks required in order to do the requested task. However, when confusing build errors manifest, then sometimes
|
||||
a ``gradle clean`` may be required in order to clear out any build areas that have an inconsistent state. The total build time
|
||||
from downloading / cloaning the repo to a complete build should be only a few minutes, obviously slightly longer if the
|
||||
from downloading / cloning the repo to a complete build should be only a few minutes, obviously slightly longer if the
|
||||
unit tests are run.
|
||||
|
||||
Frequently Used Gradle Tasks
|
||||
****************************
|
||||
|
||||
Note that the list of tasks can be ran for any gradle project can be displayed by running the task ``tasks``. Also note that
|
||||
gradle is hierachical and therefore tasks in child directories can be run using a colon seperator - ie if you want to run
|
||||
the sample attachment-demo ``runSender`` you would use the command ``gradle samples:attachment-demo:runSender``
|
||||
Note that the list of tasks can be ran for any gradle project can be displayed by running the task ``tasks``. Also, note that
|
||||
gradle is hierarchical and therefore tasks in child directories can be run using a colon separator. For example, if you want to run
|
||||
the sample attachment demo run configuration ``runSender``, you would use the command ``gradle samples:attachment-demo:runSender``
|
||||
|
||||
The most frequent gradle tasks you will probably be running are ``build`` and ``install``. The ``build`` command also executes the
|
||||
unit tests as well. If you want to build without this level of verification, then use the ``assemble`` command - but we do
|
||||
not recommend this. After running build, the ``install`` tasks copies over the built jars into the local maven repository
|
||||
which will then makes these available for either the sample code or use with the CorDapp template.
|
||||
which will then make these available for either the sample code or use with the CorDapp template.
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
||||
@ -94,7 +94,7 @@ specifying each of the three ports above in different windows, e.g.
|
||||
|
||||
You will be able to view the basic web interface identifying the different banks.
|
||||
|
||||
Now lets take a look at a transaction between Bank A and B which is not visible to Bank C. This illustrates the restricted data sharing feature of Corda, i.e. data is shared on a need-to-know basis. Nodes provide the dependency graph of a transaction they are sending to another node on demand, but there is no global broadcast of all transactions.
|
||||
Now let's take a look at a transaction between Bank A and B which is not visible to Bank C. This illustrates the restricted data sharing feature of Corda, i.e. data is shared on a need-to-know basis. Nodes provide the dependency graph of a transaction they are sending to another node on demand, but there is no global broadcast of all transactions.
|
||||
|
||||
1. In the browser tab for Bank A (the top right hand corner shows which bank you are administering) click 'Create New Trade' from the top navigation bar
|
||||
2. Select to trade with Bank B
|
||||
@ -121,12 +121,12 @@ Open two browser tabs and direct one to each of the following:
|
||||
http://localhost:11005/web/irsdemo
|
||||
http://localhost:11007/web/irsdemo
|
||||
|
||||
You will be able to see the the nodes' view of the ledger.
|
||||
You will be able to see the nodes' view of the ledger.
|
||||
|
||||
.. image:: resources/azure_vm_10_52.png
|
||||
:width: 300px
|
||||
|
||||
Now lets take a look at how the interest rates oracle provides interest rates for a deal with a semi-annual payment frequency, and how the two counterparties to the trade see the same deal information on their own nodes, i.e. you see what I see.
|
||||
Now let's take a look at how the interest rates oracle provides interest rates for a deal with a semi-annual payment frequency, and how the two counterparties to the trade see the same deal information on their own nodes, i.e. you see what I see.
|
||||
|
||||
1. In the browser tab for Bank A click 'Create Deal' from the top navigation bar
|
||||
2. Modify the terms of the IRS deal, or leave as default
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Clauses key concepts
|
||||
====================
|
||||
Clauses
|
||||
=======
|
||||
|
||||
Basic clause structure
|
||||
----------------------
|
||||
@ -34,7 +34,7 @@ is no different than normal contract verification but using clauses it's split i
|
||||
When writing a contract you need to override the contract's ``verify`` function which should call ``verifyClause``. See: :ref:`verify_ref`.
|
||||
|
||||
.. note:: A clause ``verify`` function returns the set of processed commands, at the end of ``verifyClause`` execution
|
||||
there is a check if all of transaction's commands were matched. If not then an exception is raised. This is done to
|
||||
there is a check if all of transaction's commands were matched. If not, then an exception is raised. This is done to
|
||||
enforce that spurious commands cannot be included in a transaction, ensuring that the transaction is as clear as
|
||||
possible. As an example imagine a transaction with two commands: ``Move`` and ``Issue`` included, with verification written
|
||||
using ``FirstComposition`` on clauses that require single command set. Thus only one of transaction's commands will match
|
||||
|
||||
@ -77,7 +77,7 @@ When writing code, imagine that you have an intelligent colleague looking over y
|
||||
as you go. Think about what they might ask, and then put your answers in the code.
|
||||
|
||||
Don’t be afraid of redundancy, many people will start reading your code in the middle with little or no idea of what
|
||||
it’s about, eg, due to a bug or a need to introduce a new feature. It’s OK to repeat basic facts or descriptions in
|
||||
it’s about (e.g. due to a bug or a need to introduce a new feature). It’s OK to repeat basic facts or descriptions in
|
||||
different places if that increases the chance developers will see something important.
|
||||
|
||||
API docs: all public methods, constants and classes should have doc comments in either JavaDoc or KDoc. API docs should:
|
||||
@ -151,7 +151,7 @@ trivial. If the synchronisation in your code is getting more complex, consider t
|
||||
Immutable data structures can be very useful for making it easier to reason about multi-threaded code. Kotlin makes it
|
||||
easy to define these via the "data" attribute, which auto-generates a copy() method. That lets you create clones of
|
||||
an immutable object with arbitrary fields adjusted in the clone. But if you can't use the data attribute for some
|
||||
reason, for instance, you are working in Java or because you need an inheritance heirarchy, then consider that making
|
||||
reason, for instance, you are working in Java or because you need an inheritance hierarchy, then consider that making
|
||||
a class fully immutable may result in very awkward code if there's ever a need to make complex changes to it. If in
|
||||
doubt, ask. Remember, never apply any design pattern religiously.
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@ As a result, we need to ensure that the notary either has to also sign the trans
|
||||
or perform timestamping *and* notarisation at the same time, which is the chosen behaviour for this model.
|
||||
|
||||
There will never be exact clock synchronisation between the party creating the transaction and the notary.
|
||||
This is not only due to physics, network latencies etc but because between inserting the command and getting the
|
||||
This is not only due to physics, network latencies, etc., but because between inserting the command and getting the
|
||||
notary to sign there may be many other steps, like sending the transaction to other parties involved in the trade
|
||||
as well, or even requesting human signoff. Thus the time observed by the notary may be quite different to the
|
||||
time observed in step 1.
|
||||
|
||||
@ -63,7 +63,7 @@ other obligation commands in the same transaction, as it applies to state object
|
||||
as such applies across multiple terms.
|
||||
|
||||
All other obligation contract commands specify obligation terms (what is to be delivered, by whom and by when)
|
||||
which are used as a grouping key for input/output states and commands. Issuance and lifecyle commands are mutually
|
||||
which are used as a grouping key for input/output states and commands. Issuance and lifecycle commands are mutually
|
||||
exclusive of other commands (move/exit) which apply to the same obligation terms, but multiple commands can be present
|
||||
in a single transaction if they apply to different terms. For example, a contract can have two different ``Issue``
|
||||
commands as long as they apply to different terms, but could not have an ``Issue`` and a ``Net``, or an ``Issue`` and
|
||||
|
||||
@ -35,8 +35,8 @@ rate value becoming available and then the curved arrow indicates to which perio
|
||||
|
||||
.. image:: contract-irs.png
|
||||
|
||||
Two days (by convention, although this can be modified), before the value date (ie the start of the swap) in the red
|
||||
period the reference rate is observed from an oracle and fixed in the instance at 1.1%. At the end of the accrual period,
|
||||
Two days (by convention, although this can be modified) before the value date (i.e. at the start of the swap) in the red
|
||||
period, the reference rate is observed from an oracle and fixed - in this instance, at 1.1%. At the end of the accrual period,
|
||||
there is an obligation from the floating leg payer of 1.1% * notional amount * days in the accrual period / 360.
|
||||
(Also note that the result of "days in the accrual period / 360" is also known as the day count factor, although other
|
||||
conventions are allowed and will be supported). This amount is then paid at a determined time at the end of the accrual period.
|
||||
@ -57,7 +57,7 @@ To see the minimum dataset required for the creation of an IRS, refer to ``IRSTe
|
||||
function ``IRSTests.createDummyIRS()``. Implicitly, when the agree function is called, the floating leg and fixed
|
||||
leg payment schedules are created (more details below) and can be queried.
|
||||
|
||||
Once an IRS hase been agreed, then the the only valid operation is to apply a fixing on one of the entries in the
|
||||
Once an IRS has been agreed, then the only valid operation is to apply a fixing on one of the entries in the
|
||||
``Calculation.floatingLegPaymentSchedule`` map. Fixes do not have to be applied in order (although it does make most
|
||||
sense to do them so).
|
||||
|
||||
@ -86,7 +86,7 @@ option), a termination date (and optional adjustment), the day count basis for d
|
||||
and calendar for the payment as well as the accrual adjustment options.
|
||||
|
||||
The ``FixedLeg`` contains all the details for the ``CommonLeg`` as well as payer details, the rate the leg is fixed at
|
||||
and the date roll convention (ie what to do if the calculated date lands on a bank holiday or weekend).
|
||||
and the date roll convention (i.e. what to do if the calculated date lands on a bank holiday or weekend).
|
||||
|
||||
The ``FloatingLeg`` contains all the details for the CommonLeg and payer details, roll convention, the fixing roll
|
||||
convention, which day of the month the reset is calculated, the frequency period of the fixing, the fixing calendar and
|
||||
|
||||
@ -47,8 +47,8 @@ NetworkMapService plus Simple Notary configuration file.
|
||||
Fields
|
||||
------
|
||||
|
||||
:basedir: This specifies the node workspace folder either as an absolute path, or relative to the current working directory.
|
||||
It can be overidden by the ``--base-directory`` command line option, in which case the the value in the file is ignored
|
||||
:basedir: This specifies the node workspace folder either as an absolute path, or relative to the current working directory.
|
||||
It can be overridden by the ``--base-directory`` command line option, in which case the value in the file is ignored
|
||||
and a ``node.conf`` file is expected in that workspace directory as the configuration source.
|
||||
|
||||
:myLegalName: The legal identity of the node acts as a human readable alias to the node's public key and several demos use
|
||||
@ -98,8 +98,8 @@ Fields
|
||||
joining them to the same cluster to replicate the committed state log. Note that the Raft cluster uses a separate transport
|
||||
layer for communication that does not integrate with ArtemisMQ messaging services.
|
||||
|
||||
:notaryClusterAddresses: List of Raft cluster member addresses used to joining the cluster. At least one of the specified
|
||||
members must be active and be able to communicate with the cluster leader for joining. If empty, a new cluster will be
|
||||
:notaryClusterAddresses: List of Raft cluster member addresses used to join the cluster. At least one of the specified
|
||||
members must be active and be able to communicate with the cluster leader for joining. If empty, a new cluster will be
|
||||
bootstrapped. Required only when running a distributed notary service.
|
||||
|
||||
:networkMapService: If `null`, or missing the node is declaring itself as the NetworkMapService host. Otherwise this is
|
||||
|
||||
@ -36,12 +36,12 @@ extensions to be created, or registered at startup. In particular:
|
||||
a. The ``webApis`` property is a list of JAX-RS annotated REST access
|
||||
classes. These classes will be constructed by the embedded web server
|
||||
and must have a single argument constructor taking a ``ServiceHub``
|
||||
reference. This reference provides acccess to functions such as querying
|
||||
reference. This reference provides access to functions such as querying
|
||||
for states through the ``VaultService`` interface, or access to the
|
||||
``NetworkMapCache`` to identify services on remote nodes. The framework will
|
||||
provide a database transaction in scope during the lifetime of the web
|
||||
call, so full access to database data is valid. Unlike
|
||||
``servicePlugins`` the ``webApis`` cannnot register new protocols, or
|
||||
``servicePlugins`` the ``webApis`` cannot register new protocols, or
|
||||
initiate threads. (N.B. The intent is to move the Web support into a
|
||||
separate helper process using the RPC mechanism to control access.)
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
CorDapps Background
|
||||
===================
|
||||
CorDapp basics
|
||||
==============
|
||||
|
||||
A Cordapp is an application that runs on the Corda platform using the platform APIs and plugin system. They are self
|
||||
A CorDapp is an application that runs on the Corda platform using the platform APIs and plugin system. They are self
|
||||
contained in separate JARs from the node server JAR that are created and distributed.
|
||||
|
||||
App plugins
|
||||
@ -112,15 +112,15 @@ This will publish corda-$version.jar, finance-$version.jar, core-$version.jar an
|
||||
group net.corda. You can now depend on these as you normally would a Maven dependency.
|
||||
|
||||
Gradle plugins for CorDapps
|
||||
===========================
|
||||
---------------------------
|
||||
|
||||
There are several Gradle plugins that reduce your build.gradle boilerplate and make development of Cordapps easier.
|
||||
There are several Gradle plugins that reduce your build.gradle boilerplate and make development of CorDapps easier.
|
||||
The available plugins are in the gradle-plugins directory of the Corda repository.
|
||||
|
||||
Building Gradle plugins
|
||||
-----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To install to your local Maven repository the plugins that Cordapp gradle files require, run the following from the
|
||||
To install to your local Maven repository the plugins that CorDapp gradle files require, run the following from the
|
||||
root of the Corda project:
|
||||
|
||||
.. code-block:: text
|
||||
@ -130,15 +130,15 @@ root of the Corda project:
|
||||
The plugins will now be installed to your local Maven repository in ~/.m2 on Unix and %HOMEPATH%\.m2 on Windows.
|
||||
|
||||
Using Gradle plugins
|
||||
--------------------
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To use the plugins, if you are not already using the Cordapp template project, you must modify your build.gradle. Add
|
||||
To use the plugins, if you are not already using the CorDapp template project, you must modify your build.gradle. Add
|
||||
the following segments to the relevant part of your build.gradle.
|
||||
|
||||
Template build.gradle
|
||||
---------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To build against Corda and the plugins that cordapps use, update your build.gradle to contain the following:
|
||||
To build against Corda and the plugins that CorDapps use, update your build.gradle to contain the following:
|
||||
|
||||
.. code-block:: groovy
|
||||
|
||||
@ -179,7 +179,7 @@ To build against Corda and the plugins that cordapps use, update your build.grad
|
||||
|
||||
... your tasks ...
|
||||
|
||||
// Standard way to publish Cordapps to maven local with the maven-publish and publish-utils plugin.
|
||||
// Standard way to publish CorDapps to maven local with the maven-publish and publish-utils plugin.
|
||||
publishing {
|
||||
publications {
|
||||
jarAndSources(MavenPublication) {
|
||||
@ -194,9 +194,9 @@ To build against Corda and the plugins that cordapps use, update your build.grad
|
||||
|
||||
|
||||
Cordformation
|
||||
-------------
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Cordformation is the local node deployment system for Cordapps, the nodes generated are intended to be used for
|
||||
Cordformation is the local node deployment system for CorDapps, the nodes generated are intended to be used for
|
||||
experimenting, debugging, and testing node configurations and setups but not intended for production or testnet
|
||||
deployment.
|
||||
|
||||
@ -247,5 +247,5 @@ at present) to run the nodes with one command (``runnodes``). On MacOS X this sc
|
||||
terminal tab, and on Linux it will open up a new XTerm for each node. On Windows the (``runnodes.bat``) script will run
|
||||
one node per window.
|
||||
|
||||
Other cordapps can also be specified if they are already specified as classpath or compile dependencies in your
|
||||
Other CorDapps can also be specified if they are already specified as classpath or compile dependencies in your
|
||||
``build.gradle``.
|
||||
|
||||
@ -52,7 +52,7 @@ There are two main steps to implementing scheduled events:
|
||||
performed by the contract, using ``ZonedDateTime``.
|
||||
|
||||
In the short term, until we have automatic flow session set up, you will also likely need to install a network
|
||||
handler to help with obtaining a unqiue and secure random session. An example is described below.
|
||||
handler to help with obtaining a unique and secure random session. An example is described below.
|
||||
|
||||
The production and consumption of ``ContractStates`` is observed by the scheduler and the activities associated with
|
||||
any consumed states are unscheduled. Any newly produced states are then queried via the ``nextScheduledActivity``
|
||||
|
||||
@ -49,7 +49,7 @@ Java and took over a month of full time work to develop. Most of that code is co
|
||||
message passing, lifecycle management, error handling and callback management. Because the business logic is quite
|
||||
spread out the code can be difficult to read and debug.
|
||||
|
||||
As small contract-specific trading flows are a common occurence in finance, we provide a framework for the
|
||||
As small contract-specific trading flows are a common occurrence in finance, we provide a framework for the
|
||||
construction of them that automatically handles many of the concerns outlined above.
|
||||
|
||||
Theory
|
||||
@ -93,7 +93,7 @@ Our flow has two parties (B and S for buyer and seller) and will proceed as foll
|
||||
|
||||
You can find the implementation of this flow in the file ``finance/src/main/kotlin/net/corda/flows/TwoPartyTradeFlow.kt``.
|
||||
|
||||
Assuming no malicious termination, they both end the flow being in posession of a valid, signed transaction that
|
||||
Assuming no malicious termination, they both end the flow being in possession of a valid, signed transaction that
|
||||
represents an atomic asset swap.
|
||||
|
||||
Note that it's the *seller* who initiates contact with the buyer, not vice-versa as you might imagine.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Getting set up: troubleshooting
|
||||
===============================
|
||||
Troubleshooting
|
||||
===============
|
||||
|
||||
IntelliJ issues
|
||||
---------------
|
||||
@ -22,7 +22,7 @@ If on attempting to open the project (including importing Gradle project), Intel
|
||||
you may need to fix the project structure. Do this by following `these instructions <https://www.jetbrains.com/help/idea/2016.2/configuring-global-project-and-module-sdks.html>`_. The correct JDK is often found at a path such as ``jdk1.8.0_xx…/Contents/Home``
|
||||
|
||||
Ensure that you have the Project language level set at as 8. If you are having trouble selecting the correct JDK, the
|
||||
Jetbrains website offers the `following guidelines <https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under>`_.
|
||||
JetBrains website offers the `following guidelines <https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under>`_.
|
||||
|
||||
Kotlin issues
|
||||
-------------
|
||||
@ -62,14 +62,12 @@ Wait for it to think and download the dependencies. After that you might have an
|
||||
|
||||
The code should build, the unit tests should show as all green.
|
||||
|
||||
If still have problems, the Jetbrains website has more information on `gradle here <https://www.jetbrains.com/help/idea/2016.2/working-with-gradle-projects.html>`_.
|
||||
If still have problems, the JetBrains website has more information on `gradle here <https://www.jetbrains.com/help/idea/2016.2/working-with-gradle-projects.html>`_.
|
||||
|
||||
Gradle via the CLI
|
||||
******************
|
||||
|
||||
Gradle commands can also be run in the command line - further details of command line gradle can be found in
|
||||
|
||||
.. TODO: add gradle cmd line doc link here
|
||||
Gradle commands can also be run from the command line - further details of command line gradle can be found `here <https://docs.gradle.org/current/userguide/gradle_command_line.html>`_.
|
||||
|
||||
Doing it without IntelliJ
|
||||
-------------------------
|
||||
|
||||
@ -9,12 +9,12 @@ A JVM
|
||||
-----
|
||||
|
||||
Corda runs in a JVM and is written predominantly in Kotlin with some example use cases demonstrated in Java that we have
|
||||
incorporated to demonstrate that Kotlin and Java can work seemlessly together. We recommend the most recent production
|
||||
incorporated to demonstrate that Kotlin and Java can work seamlessly together. We recommend the most recent production
|
||||
version of Java 8. The JDK can be obtained `from Oracle <http://www.oracle.com/technetwork/java/javase/downloads/index.html>`_.
|
||||
Other implementations of the JVM are not actively supported, but as mentioned, we are interested in finding out any issues you
|
||||
do have with them.
|
||||
|
||||
.. note:: If you are using a JVM implementation other than Oracle's you may get errors similiar to ``Unresolved reference: javafx``.
|
||||
.. note:: If you are using a JVM implementation other than Oracle's you may get errors similar to ``Unresolved reference: javafx``.
|
||||
This means JavaFX is not bundled with the JVM and you will need to install it separately (e.g. OpenJFX is needed
|
||||
with OpenJDK).
|
||||
|
||||
@ -22,7 +22,7 @@ IntelliJ
|
||||
--------
|
||||
We strongly recommend the use of IntelliJ's Development Environment known as IDEA. Download it for free from
|
||||
`JetBrains <https://www.jetbrains.com/idea/download/>`_. The primary reason we recommend this particular IDE is that it integrates
|
||||
very well with our choice of language for Corda, "Kotlin", as Jetbrains also support the development of Kotlin.
|
||||
very well with our choice of language for Corda, "Kotlin", as JetBrains also support the development of Kotlin.
|
||||
|
||||
.. warning:: When opening the Corda project for the first time from the IntelliJ splash screen, please use "Open"
|
||||
and then agree to import the Gradle project from the popup bubble. Don't pick "Import" on the splash screen,
|
||||
@ -42,14 +42,14 @@ of the tutorials (known as "koans") as well. Also see our :doc:`further-notes-on
|
||||
Version control via Git
|
||||
-----------------------
|
||||
|
||||
We use git to version control Corda. The authorative place to obtain git is from the main `git website <https://git-scm.com/downloads>`_
|
||||
We use git to version control Corda. The authoritative place to obtain git is from the main `git website <https://git-scm.com/downloads>`_
|
||||
but it may be the case that your operating system provides git with a supported utility (e.g. for Apple, git is provided along
|
||||
with XCode - their free development environment). If this is the case, we would recommend you obtain git via that
|
||||
supported route.
|
||||
|
||||
You will need the command line package installed which you can then use natively (via the command line) or via IntelliJ
|
||||
(in which case you may need to configure IntelliJ to recognise where git has been installed on your system). IntelliJ and
|
||||
git configuration are quite seemless although the first time you use it, you will have to configure IntelliJ the location
|
||||
git configuration are quite seamless although the first time you use it, you will have to configure IntelliJ the location
|
||||
of your git command installation. More details regarding this can be found
|
||||
on the `JetBrains website <https://www.jetbrains.com/help/idea/2016.2/using-git-integration.html>`_
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ SIMM
|
||||
Service Hub
|
||||
A hub in each Corda node that manages the services upon which other components of the node depend. Services may include facilities for identity management, storage management, network map management etc.
|
||||
Signed Transaction
|
||||
A signed transaction is a transaction that has been agreed by all parties relevant to that transacation as well as optionally a notary if relevant.
|
||||
A signed transaction is a transaction that has been agreed by all parties relevant to that transaction as well as optionally a notary if relevant.
|
||||
State
|
||||
An element of data that is output from one transaction and then used / consumed in another transaction. States can only be consumed once and this confirmation is performed by the Notary service.
|
||||
Transaction
|
||||
|
||||
@ -87,7 +87,6 @@ Read on to learn:
|
||||
:caption: Other
|
||||
|
||||
network-simulator
|
||||
initial-margin-agreement
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@ -1,73 +0,0 @@
|
||||
Initial margin agreements
|
||||
=========================
|
||||
|
||||
This app is a demonstration of how Corda can be used for the real world requirement of initial margin calculation and
|
||||
agreement; featuring the integration of complex and industry proven third party libraries into Corda nodes.
|
||||
|
||||
SIMM introduction
|
||||
-----------------
|
||||
|
||||
SIMM is an acronym for "Standard Initial Margin Model". It is effectively the calculation of a "margin" that is paid
|
||||
by one party to another when they agree a trade on certain types of transaction. This margin is
|
||||
paid such that, in the event of one of the counterparties suffering a credit event
|
||||
(a financial term and a polite way to say defaulting, not paying the debts that are due, or potentially even bankruptcy),
|
||||
then the party that is owed any sum already has some of the amount that it should have been paid. This payment to the
|
||||
receiving party is a preventative measure in order to reduce the risk of a potentially catastrophic default domino
|
||||
effect that caused the `Great Financial Crisis <https://en.wikipedia.org/wiki/Financial_crisis_of_2007%E2%80%932008>`_,
|
||||
as it means that they can be assured that if they need to pay another party, they will have a proportion of the funds
|
||||
that they have been relying on.
|
||||
|
||||
To enact this, in September 2016, the ISDA committee - with full backing from various governing bodies -
|
||||
`issued a ruling on what is known as the ISDA SIMM ™ model <http://www2.isda.org/news/isda-simm-deployed-today-new-industry-standard-for-calculating-initial-margin-widely-adopted-by-market-participants>`_,
|
||||
a way of fairly and consistently calculating this margin. Any parties wishing to trade a financial product that is
|
||||
covered under this ruling would, independently, use this model and calculate their margin payment requirement,
|
||||
agree it with their trading counterparty and then pay (or receive, depending on the results of this calculation)
|
||||
this amount. In the case of disagreement that is not resolved in a timely fashion, this payment would increase
|
||||
and so therefore it is in the parties interest to reach agreement in a short as time frame as possible.
|
||||
|
||||
To be more accurate, the SIMM calculation is not performed on just one trade - it is calculated on an aggregate of
|
||||
intermediary values (which in this model are sensitivities to risk factors) from a portfolio of trades; therefore
|
||||
the input to a SIMM is actually this data, not the individual trades itself.
|
||||
|
||||
Also note that implementations of the SIMM are actually protected and subject to license restrictions by ISDA
|
||||
(this is due to the model itself being protected). We were fortunate enough to technically partner with
|
||||
`OpenGamma <http://www.opengamma.com>`_ who allowed us to demonstrate the SIMM process using their proprietary model.
|
||||
In the source code released, we have replaced their analytics engine with very simple stub functions that allow
|
||||
the process to run and can easily be swapped out in place for their real libraries.
|
||||
|
||||
Process steps
|
||||
-------------
|
||||
|
||||
Preliminaries
|
||||
- Ensure that there are a number of live trades with another party financial products that are covered under the
|
||||
ISDA SIMM agreement (if none, then use the demo to enter some simple trades as described below).
|
||||
|
||||
Initial Margin Agreement Process
|
||||
- Agree that one will be performing the margining calculation against a portfolio of trades with another party, and agree the trades in that portfolio. In practice, one node will start the flow but it does not matter which node does.
|
||||
- Individually (at the node level), identify the data (static, reference etc) one will need in order to be able to calculate the metrics on those trades
|
||||
- Confirm with the other counterparty the dataset from the above set
|
||||
- Calculate any intermediary steps and values needed for the margin calculation (ie sensitivities to risk factors)
|
||||
- Agree on the results of these steps
|
||||
- Calculate the initial margin
|
||||
- Agree on the calculation of the above with the other party
|
||||
- In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)
|
||||
|
||||
|
||||
Running the app
|
||||
---------------
|
||||
|
||||
The demonstration can be run in two ways - via IntelliJ (which will allow you to add breakpoints, debug, etc), or via gradle and the command line.
|
||||
|
||||
Run with IntelliJ::
|
||||
|
||||
1. Open the `cordapp-samples` project with IntelliJ
|
||||
2. Run the shared run configuration "SIMM Valuation Demo"
|
||||
3. Browse to http://localhost:10005/web/simmvaluationdemo
|
||||
|
||||
Run via CLI::
|
||||
|
||||
1. Navigate to the `cordapp-samples` directory in your shell
|
||||
2. Run the gradle target `deployNodes` (ie; ./gradlew deployNodes for Unix or gradlew.bat on Windows)
|
||||
1. Unix: `cd simm-valuation-demo/build/nodes && ./runnodes`.
|
||||
2. Windows: `cd simm-valuation-demo/build/nodes & runnodes.bat`
|
||||
4. Browse to http://localhost:10005/web/simmvaluationdemo
|
||||
@ -111,4 +111,4 @@ The ``gatherRemoteState`` function should check the actual remote nodes' states
|
||||
|
||||
The reason it gets the previous state boils down to allowing non-deterministic predictions about the nodes' remote states. Say some piece of work triggers an asynchronous notification of a node. We need to account both for the case when the node hasn't received the notification and for the case when it has. In these cases ``S`` should somehow represent a collection of possible states, and ``gatherRemoteState`` should "collapse" the collection based on the observations it makes. Of course we don't need this for the simple case of the Self Issue test.
|
||||
|
||||
The last parameter ``isConsistent`` is used to poll for eventual consistency at the end of a load test. This is not needed for Self Issue.
|
||||
The last parameter ``isConsistent`` is used to poll for eventual consistency at the end of a load test. This is not needed for self-issuance.
|
||||
|
||||
@ -5,7 +5,7 @@ One of the basic data structures in our platform is a transaction. It can be pas
|
||||
also by third parties. The construction of transactions assumes that they form a whole entity with input and output states,
|
||||
commands and attachments inside. However all sensitive data shouldn’t be revealed to other nodes that take part in
|
||||
the creation of transaction on validation level (a good example of this situation is the Oracle which validates only
|
||||
embedded commands). How to achive it in a way that convinces the other party the data they got for signing really did form
|
||||
embedded commands). How to achieve it in a way that convinces the other party the data they got for signing really did form
|
||||
a part of the transaction?
|
||||
|
||||
We decided to use well known and described cryptographic scheme to provide proofs of inclusion and data integrity.
|
||||
@ -107,5 +107,5 @@ If you want to verify obtained ``FilteredTransaction`` all you need is the root
|
||||
|
||||
.. note:: The way the ``FilteredTransaction`` is constructed ensures that after signing of the root hash it's impossible to add or remove
|
||||
leaves. However, it can happen that having transaction with multiple commands one party reveals only subset of them to the Oracle.
|
||||
As signing is done now over the merkle root hash, the service signs all commands of given type, even though it didn't see
|
||||
As signing is done now over the Merkle root hash, the service signs all commands of given type, even though it didn't see
|
||||
all of them. This issue will be handled after implementing partial signatures.
|
||||
|
||||
@ -38,7 +38,7 @@ The network map currently supports:
|
||||
* Looking up nodes by service
|
||||
* Looking up node for a party
|
||||
* Suggesting a node providing a specific service, based on suitability for a contract and parties, for example suggesting
|
||||
an appropriate interest rates oracle for a interest rate swap contract. Currently no recommendation logic is in place.
|
||||
an appropriate interest rates oracle for an interest rate swap contract. Currently no recommendation logic is in place.
|
||||
|
||||
Message queues
|
||||
--------------
|
||||
|
||||
@ -20,7 +20,7 @@ whatever the current Corda version is.
|
||||
What it is and is not
|
||||
---------------------
|
||||
|
||||
The simulator currenty exists as an illustrative tool to help with explaining how Corda works in an example scenario.
|
||||
The simulator currently exists as an illustrative tool to help with explaining how Corda works in an example scenario.
|
||||
It utilises the ``Simulator`` tools that support creating a simulated Corda network and the nodes running in it within
|
||||
a single JVM, as an extension of the ``MockNetwork`` testing framework. See more about the ``MockNetwork`` and
|
||||
testing flows here: :doc:`flow-testing`.
|
||||
|
||||
@ -92,7 +92,7 @@ Login
|
||||
Dashboard
|
||||
The dashboard shows the top level state of node and vault.
|
||||
Currently, it shows your cash balance and the numbers of transaction executed.
|
||||
The dashboard is intended to house widgets from different CordApp's and provide useful information to system admin at a glance.
|
||||
The dashboard is intended to house widgets from different CordApps and provide useful information to system admin at a glance.
|
||||
|
||||
.. image:: resources/explorer/dashboard.png
|
||||
|
||||
@ -126,7 +126,7 @@ Transactions
|
||||
Network
|
||||
The network view shows the network information on the world map. Currently only the user's node is rendered on the map.
|
||||
This will be extended to other peers in a future release.
|
||||
The map provides a intuitive way of visualizing the Corda network and the participants.
|
||||
The map provides an intuitive way of visualizing the Corda network and the participants.
|
||||
|
||||
.. image:: resources/explorer/network.png
|
||||
|
||||
|
||||
@ -53,7 +53,7 @@ and remote ``Parties``. It is automatically populated from the
|
||||
``NetworkMapCache`` updates and is used when translating ``CompositeKey``
|
||||
exposed in transactions into fully populated ``Party`` identities. This
|
||||
service is also used in the default JSON mapping of parties in the web
|
||||
server, thus allowing the party names to be used to refer to other node
|
||||
server, thus allowing the party names to be used to refer to other nodes'
|
||||
legal identities. In the future the Identity service will be made
|
||||
persistent and extended to allow anonymised session keys to be used in
|
||||
flows where the well-known ``CompositeKey`` of nodes need to be hidden
|
||||
|
||||
@ -13,15 +13,15 @@ affect the validity of transactions.
|
||||
The current prototype includes an example oracle that provides an interest rate fixing service. It is used by the
|
||||
IRS trading demo app.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
Introduction to oracles
|
||||
-----------------------
|
||||
|
||||
Oracles are a key concept in the block chain/decentralised ledger space. They can be essential for many kinds of
|
||||
application, because we often wish to condition a transaction on some fact being true or false, but the ledger itself
|
||||
has a design that is essentially functional: all transactions are *pure* and *immutable*. Phrased another way, a
|
||||
smart contract cannot perform any input/output or depend on any state outside of the transaction itself. There is no
|
||||
way to download a web page or interact with the user, in a smart contract. It must be this way because everyone must
|
||||
be able to independently check a transaction and arrive at an identical conclusion for the ledger to maintan its
|
||||
be able to independently check a transaction and arrive at an identical conclusion for the ledger to maintain its
|
||||
integrity: if a transaction could evaluate to "valid" on one computer and then "invalid" a few minutes later on a
|
||||
different computer, the entire shared ledger concept wouldn't work.
|
||||
|
||||
@ -38,7 +38,7 @@ could do an HTTP request: it's possible that an answer would change after being
|
||||
consensus (breaks).
|
||||
|
||||
The two basic approaches
|
||||
------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The architecture provides two ways of implementing oracles with different tradeoffs:
|
||||
|
||||
@ -73,7 +73,7 @@ Here's a quick way to decide which approach makes more sense for your data sourc
|
||||
attachment.
|
||||
|
||||
Asserting continuously varying data
|
||||
-----------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Let's look at the interest rates oracle that can be found in the ``NodeInterestRates`` file. This is an example of
|
||||
an oracle that uses a command because the current interest rate fix is a constantly changing fact.
|
||||
@ -127,7 +127,7 @@ We can schedule for the expected announcement (or publish) time and give a suita
|
||||
information being available and the delay to processing becomes significant and may need to be escalated.
|
||||
|
||||
Hiding transaction data from the oracle
|
||||
---------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Because the transaction is sent to the oracle for signing, ordinarily the oracle would be able to see the entire contents
|
||||
of that transaction including the inputs, output contract states and all the commands, not just the one (in this case)
|
||||
@ -137,7 +137,7 @@ oracle but still allow it to sign it by providing the Merkle hashes for the rema
|
||||
more details.
|
||||
|
||||
Pay-per-play oracles
|
||||
--------------------
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Because the signature covers the transaction, and transactions may end up being forwarded anywhere, the fact itself
|
||||
is independently checkable. However, this approach can still be useful when the data itself costs money, because the act
|
||||
@ -150,10 +150,10 @@ where parties are legally identifiable, usage of such a contract would by itself
|
||||
punishment.
|
||||
|
||||
Implementing an oracle with continuously varying data
|
||||
=====================================================
|
||||
-----------------------------------------------------
|
||||
|
||||
Implement the core classes
|
||||
--------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The key is to implement your oracle in a similar way to the ``NodeInterestRates.Oracle`` outline we gave above with
|
||||
both ``query`` and ``sign`` methods. Typically you would want one class that encapsulates the parameters to the ``query``
|
||||
@ -194,8 +194,8 @@ Here we can see that there are several steps:
|
||||
exactly our data source. The final step, assuming we have got this far, is to generate a signature for the
|
||||
transaction and return it.
|
||||
|
||||
Binding to the network via CorDapp plugin
|
||||
-----------------------------------------
|
||||
Binding to the network via a CorDapp plugin
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. note:: Before reading any further, we advise that you understand the concept of flows and how to write them and use
|
||||
them. See :doc:`flow-state-machines`. Likewise some understanding of Cordapps, plugins and services will be helpful.
|
||||
@ -228,7 +228,7 @@ implementing a plugin. Don't forget the resources file to register it with the
|
||||
}
|
||||
|
||||
Providing client sub-flows for querying and signing
|
||||
---------------------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We mentioned the client sub-flow briefly above. They are the mechanism that clients, in the form of other flows, will
|
||||
interact with your oracle. Typically there will be one for querying and one for signing. Let's take a look at
|
||||
@ -243,10 +243,10 @@ You'll note that the ``FixSignFlow`` requires a ``FilterFuns`` instance with the
|
||||
the ``Fix`` commands. You can find a further explanation of this in :doc:`merkle-trees`.
|
||||
|
||||
Using an oracle
|
||||
===============
|
||||
---------------
|
||||
|
||||
The oracle is invoked through sub-flows to query for values, add them to the transaction as commands and then get
|
||||
the transaction signed by the the oracle. Following on from the above examples, this is all encapsulated in a sub-flow
|
||||
the transaction signed by the oracle. Following on from the above examples, this is all encapsulated in a sub-flow
|
||||
called ``RatesFixFlow``. Here's the ``call`` method of that flow.
|
||||
|
||||
.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/flows/RatesFixFlow.kt
|
||||
|
||||
@ -22,7 +22,7 @@ The following information from the node configuration file is needed to generate
|
||||
has already been permissioned with this name then the permissioning server will automatically reject the request. The
|
||||
request will also be rejected if the name contains a ``=`` or ``,``.
|
||||
|
||||
.. note:: In a future version the uniquess requirement will be relaxed to a X.500 name. This will allow differentiation
|
||||
.. note:: In a future version the uniqueness requirement will be relaxed to a X.500 name. This will allow differentiation
|
||||
between entities with the same name.
|
||||
|
||||
:nearestCity: e.g. "London"
|
||||
@ -37,7 +37,7 @@ A new pair of private and public keys will be generated by the utility and will
|
||||
The utility will submit the request to the network permissioning server and poll for a result periodically to retrieve the certificates.
|
||||
Once the request has been approved and the certificates downloaded from the server, the utility will create the key store and trust store using the certificates and the generated private key.
|
||||
|
||||
.. note:: You can exit the utility at anytime if the approval process is taking longer then expected. The request process will resume on restart.
|
||||
.. note:: You can exit the utility at any time if the approval process is taking longer than expected. The request process will resume on restart.
|
||||
|
||||
This process only needs to be done once when the node connects to the network for the first time, or when the certificate expires.
|
||||
|
||||
|
||||
@ -63,7 +63,7 @@ The ``SchemaService`` is also responsible for the ``SchemaOptions`` that can be
|
||||
which allow the configuration of a database schema or table name prefixes to avoid any clash with other ``MappedSchema``.
|
||||
|
||||
.. note:: It is intended that there should be plugin support for the ``SchemaService`` to offer the version upgrading and
|
||||
additional schemas as part of Cordapps, and that the active schemas be confgurable. However the present implementation
|
||||
additional schemas as part of Cordapps, and that the active schemas be configurable. However the present implementation
|
||||
offers none of this and simply results in all versions of all schemas supported by a ``QueryableState`` being persisted.
|
||||
This will change in due course. Similarly, it does not currently support configuring ``SchemaOptions`` but will do so in
|
||||
the future.
|
||||
|
||||
@ -24,11 +24,11 @@ To publish the codebase locally to Maven Local you must run:
|
||||
Publishing to Jcenter
|
||||
---------------------
|
||||
|
||||
.. note:: The module you wish to publish must be linked to jcenter in bintray. Only the founding account can do this.
|
||||
.. note:: The module you wish to publish must be linked to jcenter in Bintray. Only the founding account can do this.
|
||||
|
||||
To publish to Jcenter you must first have the following;
|
||||
|
||||
1. An account on bintray in the R3 organisation
|
||||
1. An account on Bintray in the R3 organisation
|
||||
2. Our GPG key's passphrase for signing the binaries to publish
|
||||
|
||||
Getting Setup
|
||||
@ -37,7 +37,7 @@ Getting Setup
|
||||
You must now set the following environment variables:
|
||||
|
||||
* CORDA_BINTRAY_USER your Bintray username
|
||||
* CORDA_BINTRAY_KEY to your bintray API key (found at: https://bintray.com/profile/edit)
|
||||
* CORDA_BINTRAY_KEY to your Bintray API key (found at: https://bintray.com/profile/edit)
|
||||
* CORDA_BINTRAY_GPG_PASSPHRASE to our GPG passphrase
|
||||
|
||||
Publishing
|
||||
|
||||
@ -30,7 +30,7 @@ Milestone 6
|
||||
|
||||
* Node console output now displays concise startup information, such as startup time or web address. All logging to
|
||||
the console is suppressed apart from errors and flow progress tracker steps. It can be re-enabled by passing
|
||||
``--log-to-console`` command line parameter. Note that the log file remains unchanged an will still contain all
|
||||
``--log-to-console`` command line parameter. Note that the log file remains unchanged and will still contain all
|
||||
log entries.
|
||||
|
||||
* The ``runnodes`` scripts generated by the Gradle plugins now open each node in separate terminal windows or (on macOS) tabs.
|
||||
@ -261,7 +261,7 @@ Milestone 2
|
||||
|
||||
* Thanks to the prolific Sofus Mortensen @ Nordea Bank, an experimental generic contract DSL that is based on the famous
|
||||
2001 "Composing contracts" paper has been added. We thank Sofus for this great and promising research, which is so
|
||||
relevant in the wake of TheDAO hack.
|
||||
relevant in the wake of the DAO hack.
|
||||
* The contract code from the recent trade finance demos is now in experimental. This code comes thanks to a
|
||||
collaboration of the members; all credit to:
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ Our goal is to cut a new milestone roughly once a month. There are no fixed date
|
||||
a few days to ensure the code is sufficiently usable. Usually the release will happen around the end of the month.
|
||||
|
||||
Steps to cut a release
|
||||
======================
|
||||
----------------------
|
||||
|
||||
1. Pick a commit that is stable and do basic QA: run all the tests, run the demos.
|
||||
2. Review the commits between this release and the last looking for new features, API changes, etc. Make sure the
|
||||
|
||||
@ -19,7 +19,7 @@ For ``SimpleNotaryService``, simply add the following service id to the list of
|
||||
|
||||
extraAdvertisedServiceIds: "net.corda.notary.simple"
|
||||
|
||||
For ``ValidatingNotaryService`` it is:
|
||||
For ``ValidatingNotaryService``, it is:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
@ -1,151 +1,178 @@
|
||||
Running the demos
|
||||
=================
|
||||
|
||||
The repository contains a small number of demo programs that run two-node networks, demonstrating functionality developed
|
||||
so far. We have:
|
||||
The Corda repository contains a number of demo programs demonstrating the functionality developed so far:
|
||||
|
||||
1. The trader demo, which shows a delivery-vs-payment atomic swap of commercial paper for cash. You can learn more about
|
||||
how this works in :doc:`flow-state-machines`.
|
||||
2. The IRS demo, which shows two nodes establishing an interest rate swap between them and performing fixings with a
|
||||
rates oracle, all driven via the HTTP API.
|
||||
3. The IRS demo web interface - a web interface to the IRS demo.
|
||||
4. The attachment demo, which demonstrates uploading attachments to nodes.
|
||||
5. The SIMM valuation demo, a large demo which shows two nodes agreeing on a portfolio and valuing the initial margin
|
||||
using the Standard Initial Margin Model.
|
||||
6. The raft notary demo, which demonstrates a single node getting multiple transactions notarised by a distributed (Raft-based) notary.
|
||||
7. The Bank of Corda demo, which demonstrates a node acting as an issuer of assets (the Bank of Corda) and remote client
|
||||
applications requesting issuance (via RPC, HTTP) of some cash on behalf of a node called Big Corporation.
|
||||
|
||||
.. note:: If any demos don't work please jump on our mailing list and let us know.
|
||||
|
||||
|
||||
Important : Common Instructions for all demos
|
||||
---------------------------------------------
|
||||
1. The Trader Demo, which shows a delivery-vs-payment atomic swap of commercial paper for cash
|
||||
2. The IRS Demo, which shows two nodes establishing an interest rate swap and performing fixings with a
|
||||
rates oracle
|
||||
3. The Attachment Demo, which demonstrates uploading attachments to nodes
|
||||
4. The SIMM Valuation Demo, which shows two nodes agreeing on a portfolio and valuing the initial margin
|
||||
using the Standard Initial Margin Model
|
||||
5. The Distributed Notary Demo, which shows a single node getting multiple transactions notarised by a distributed (Raft-based) notary
|
||||
6. The Bank of Corda Demo, which shows a node acting as an issuer of assets (the Bank of Corda) while remote client
|
||||
applications request issuance of some cash on behalf of a node called Big Corporation
|
||||
|
||||
The demos can be run either from the command line, or from inside IntelliJ. Running from the command line is
|
||||
recommended if you are just wanting to see them run, using IntelliJ can be helpful if you want to debug or
|
||||
develop the demos themselves. For more details about running via the command line or within IntelliJ - see :doc:`CLI-vs-IDE`.
|
||||
recommended if you just want to see the demos run, whereas using IntelliJ can be helpful if you want to debug or
|
||||
extend the demos. For more details about running via the command line or from within IntelliJ, see :doc:`CLI-vs-IDE`.
|
||||
|
||||
*For all demos:* The ``install`` gradle task is automatically ran if required; this no longer needs to be run independently.
|
||||
.. note:: If any of the demos don't work, please raise an issue on GitHub.
|
||||
|
||||
Trader demo
|
||||
-----------
|
||||
|
||||
This demo brings up four nodes: Bank A, Bank B, Bank Of Corda and a notary/network map node that they both use. Bank A will
|
||||
This demo brings up four nodes: Bank A, Bank B, Bank Of Corda, and a notary/network map node that they all use. Bank A will
|
||||
be the buyer, and requests some cash from the Bank of Corda in order to acquire commercial paper from Bank B, the seller.
|
||||
|
||||
To run from the command line:
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Run ``./gradlew samples:trader-demo:deployNodes`` to create a set of configs and installs under ``samples/trader-demo/build/nodes``
|
||||
2. Run ``./samples/trader-demo/build/nodes/runnodes`` (or ``runnodes.bat`` on Windows) to open up four new terminals with the four nodes.
|
||||
2. Run ``./samples/trader-demo/build/nodes/runnodes`` to open up four new terminals with the four nodes
|
||||
3. Run ``./gradlew samples:trader-demo:runBuyer`` to instruct the buyer node to request issuance of some cash from the Bank of Corda node.
|
||||
This step will display progress information related to the cash issuance process (in the bank of corda node log output).
|
||||
This step will display progress information related to the cash issuance process (in the bank of corda node log output)
|
||||
4. Run ``./gradlew samples:trader-demo:runSeller`` to trigger the transaction. You can see both sides of the
|
||||
trade print their progress and final transaction state in the bank node tabs/windows.
|
||||
trade print their progress and final transaction state in the bank node tabs/windows
|
||||
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Run ``gradlew samples:trader-demo:deployNodes`` to create a set of configs and installs under ``samples\trader-demo\build\nodes``
|
||||
2. Run ``samples\trader-demo\build\nodes\runnodes`` to open up four new terminals with the four nodes
|
||||
3. Run ``gradlew samples:trader-demo:runBuyer`` to instruct the buyer node to request issuance of some cash from the Bank of Corda node.
|
||||
This step will display progress information related to the cash issuance process (in the Bank of Corda node log output)
|
||||
4. Run ``gradlew samples:trader-demo:runSeller`` to trigger the transaction. You can see both sides of the
|
||||
trade print their progress and final transaction state in the bank node tabs/windows
|
||||
|
||||
To run from IntelliJ:
|
||||
|
||||
1. Open the Corda project in IntelliJ and run the "Install" configuration
|
||||
2. Open the Corda samples project in IntelliJ and run the "Trader Demo: Run Nodes" configuration
|
||||
3. Run "Trader Demo: Run Buyer"
|
||||
4. Run "Trader Demo: Run Seller"
|
||||
|
||||
In the "Trader Demo: Run Nodes" windows you should see some log lines scroll past, and within a few seconds the messages
|
||||
"Purchase complete - we are a happy customer!" and "Sale completed - we have a happy customer!" should be printed.
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``Trader Demo: Run Nodes`` configuration, which will start four nodes. Once all nodes are started you will see several
|
||||
"Node started up and registered in ..." messages
|
||||
3. Run ``Trader Demo: Run Buyer`` to instruct the buyer node to request issuance of some cash from the Bank of Corda node
|
||||
4. Run ``Trader Demo: Run Seller`` to trigger the transaction
|
||||
5. In the "Trader Demo: Run Nodes" run configuration window, you should see some log lines scroll past. Within a few seconds, the message
|
||||
"Purchase complete - we are a happy customer!" should be printed.
|
||||
|
||||
IRS demo
|
||||
--------
|
||||
|
||||
This demo brings up three nodes: Bank A, Bank B and a node that runs a notary, a network map and an interest rates
|
||||
oracle together. The two banks agree on an interest rate swap, and then do regular fixings of the deal as the time
|
||||
This demo brings up three nodes: Bank A, Bank B and a node that simultaneously runs a notary, a network map and an interest rates
|
||||
oracle. The two banks agree on an interest rate swap, and then do regular fixings of the deal as the time
|
||||
on a simulated clock passes.
|
||||
|
||||
To run from the command line:
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Run ``./gradlew samples:irs-demo:deployNodes`` to install configs and a command line tool under ``samples/irs-demo/build``.
|
||||
2. Change to the ``samples/irs-demo/build`` directory.
|
||||
3. Run ``./nodes/runnodes`` (or ``runnodes.bat`` on Windows) to open up three new terminals with the three nodes.
|
||||
4. Run ``./install/irs-demo/bin/irs-demo --role UploadRates`` (or use ``irs-demo.bat`` on Windows). You should see a
|
||||
message be printed to the first node (the notary/oracle/network map node) saying that it has accepted some new
|
||||
interest rates.
|
||||
5. Now run ``irs-demo`` as in step 4, but this time with ``--role Trade 1``. The number is a trade ID. You should
|
||||
see lots of activity as the nodes set up the deal, notarise it, get it signed by the oracle and so on.
|
||||
6. Now run ``irs-demo --role Date 2016-12-12`` to roll the simulated clock forward and see some fixings take place.
|
||||
2. Move to the ``samples/irs-demo/build`` directory
|
||||
3. Run ``./nodes/runnodes`` to open up three new terminals with the three nodes
|
||||
4. Run ``./install/irs-demo/bin/irs-demo --role UploadRates``. You should see a
|
||||
message be printed to the first node (the notary/oracle/network map node) saying that it has accepted the new
|
||||
interest rates
|
||||
5. Now run ``./install/irs-demo/bin/irs-demo --role Trade 1``. The number is a trade ID. You should
|
||||
see lots of activity as the nodes set up the deal, notarise it, get it signed by the oracle, and so on
|
||||
6. Now run ``./install/irs-demo/bin/irs-demo --role Date 2016-12-12`` to roll the simulated clock forward and see some fixings take place
|
||||
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Run ``gradlew samples:irs-demo:deployNodes`` to install configs and a command line tool under ``samples\irs-demo\build``
|
||||
2. Move to the ``samples\irs-demo\build`` directory
|
||||
3. Run ``nodes\runnodes`` to open up three new terminals with the three nodes.
|
||||
4. Run ``install\irs-demo\bin\irs-demo --role UploadRates``. You should see a
|
||||
message be printed to the first node (the notary/oracle/network map node) saying that it has accepted the new
|
||||
interest rates
|
||||
5. Now run ``install\irs-demo\bin\irs-demo --role Trade 1``. The number is a trade ID. You should
|
||||
see lots of activity as the nodes set up the deal, notarise it, get it signed by the oracle, and so on
|
||||
6. Now run ``install\irs-demo\bin\irs-demo --role Date 2016-12-12`` to roll the simulated clock forward and see some fixings take place
|
||||
|
||||
To run from IntelliJ:
|
||||
|
||||
1. Open the Corda project in IntelliJ and run the "Install" configuration
|
||||
2. Open the Corda samples project in IntelliJ and run the "IRS Demo: Run Nodes" configuration
|
||||
3. Run "IRS Demo: Run Upload Rates" to upload rates to the oracle.
|
||||
4. Run "IRS Demo: Run Trade" to have nodes agree on a trade.
|
||||
5. Run "IRS Demo: Run Date Change" to run the fixings.
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``IRS Demo: Run Nodes`` configuration to start three nodes. Once all nodes are started you will see several
|
||||
"Node started up and registered in ..." messages
|
||||
3. Run ``IRS Demo: Run Upload Rates`` to upload the new interest rates to the oracle
|
||||
4. Run ``IRS Demo: Run Trade`` to have the nodes agree on a trade
|
||||
5. Run ``IRS Demo: Run Date Change`` to roll the simulated clock forward and see some fixings take place
|
||||
6. In the "IRS Demo: Run Nodes" window you'll see a lot of activity when you run the trade and when you change the date.
|
||||
The date change rolls the clock forwards and causes the nodes to agree on the fixings over a period.
|
||||
|
||||
In the "IRS Demo: Run Nodes" window you'll see a lot of activity when you run the trade and when you run the date change.
|
||||
The date change rolls the clock forwards and causes the nodes to agree on the fixings over a period.
|
||||
This demo also has a web app. To use this, set up the trades and then navigate to
|
||||
http://localhost:10005/web/irsdemo and http://localhost:10007/web/irsdemo to see each node's view of the ledger.
|
||||
|
||||
There is also an web app as part of this demo. To use this set up the trades and then navigate to
|
||||
http://localhost:10005/web/irsdemo and http://localhost:10007/web/irsdemo to see both node's view of the ledger.
|
||||
|
||||
To use the demos click the "Create Deal" button, fill in the form, then click the "Submit" button. Now you will be
|
||||
able to use the time controls at the top left of the home page to run the fixings. Click any individual trade in the
|
||||
blotter to view it.
|
||||
To use the web app, click the "Create Deal" button, fill in the form, then click the "Submit" button. You can then
|
||||
use the time controls at the top left of the home page to run the fixings. Click any individual trade in the blotter to view it.
|
||||
|
||||
Attachment demo
|
||||
---------------
|
||||
|
||||
This demo brings up three nodes, and sends a transaction containing an attachment from one to the other. To run
|
||||
it from the command line (recommended for Mac/UNIX users!):
|
||||
This demo brings up three nodes, and sends a transaction containing an attachment from one to the other.
|
||||
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Run ``./gradlew samples:attachment-demo:deployNodes`` to create a set of configs and installs under ``samples/attachment-demo/build/nodes``
|
||||
2. Run ``./samples/attachment-demo/build/nodes/runnodes`` to open up three new terminal tabs/windows with the three nodes.
|
||||
3. Run ``./gradlew samples:attachment-demo:runRecipient``, which will block waiting for something to happen.
|
||||
4. Run ``./gradlew samples:attachment-demo:runSender`` in another terminal window to trigger the transaction.
|
||||
Now look at the other windows to see the output of the demo.
|
||||
2. Run ``./samples/attachment-demo/build/nodes/runnodes`` to open up three new terminal tabs/windows with the three nodes
|
||||
3. Run ``./gradlew samples:attachment-demo:runRecipient``, which will block waiting for a trade to start
|
||||
4. Run ``./gradlew samples:attachment-demo:runSender`` in another terminal window to send the attachment. Now look at the other windows to
|
||||
see the output of the demo
|
||||
|
||||
Or you can run them from inside IntelliJ, but when done this way, all the node output is printed to a single console.
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Open the Corda project in IntelliJ and run the "Install" configuration
|
||||
2. Open the Corda samples project in IntelliJ and run the "Attachment Demo: Run Nodes" configuration
|
||||
3. Run "Attachment Demo: Run Recipient" - this waits for a trade to start
|
||||
4. Run "Attachment Demo: Run Sender" - sends the attachment
|
||||
1. Run ``gradlew samples:attachment-demo:deployNodes`` to create a set of configs and installs under ``samples\attachment-demo\build\nodes``
|
||||
2. Run ``samples\attachment-demo\build\nodes\runnodes`` to open up three new terminal tabs/windows with the three nodes
|
||||
3. Run ``gradlew samples:attachment-demo:runRecipient``, which will block waiting for a trade to start
|
||||
4. Run ``gradlew samples:attachment-demo:runSender`` in another terminal window to send the attachment. Now look at the other windows to
|
||||
see the output of the demo
|
||||
|
||||
In the "Attachment Demo: Run Nodes" window you should see some log lines scroll past, and within a few seconds the
|
||||
message "File received - we're happy!" should be printed.
|
||||
To run from IntelliJ:
|
||||
|
||||
.. _notary-demo:
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``Attachment Demo: Run Nodes`` configuration to start three nodes. Once all nodes are started you will see several
|
||||
"Node started up and registered in ..." messages
|
||||
3. Run ``Attachment Demo: Run Recipient``, which will wait for a trade to start
|
||||
4. Run ``Attachment Demo: Run Sender`` to send the attachment
|
||||
5. In the "Attachment Demo: Run Nodes" window you should see some log lines scroll past. Within a few seconds, the
|
||||
message "File received - we're happy!" should be printed.
|
||||
|
||||
Raft Notary demo
|
||||
----------------
|
||||
|
||||
This is a simple demonstration showing a party getting transactions notarised by a distributed `Raft <https://raft.github.io/>`_-based notary service.
|
||||
The demo will start three distributed notary nodes, and two counterparty nodes. One of the parties will generate transactions
|
||||
that move a self-issued asset to the other party, and submit them for notarisation.
|
||||
This demo shows a party getting transactions notarised by a distributed `Raft <https://raft.github.io/>`_-based notary service.
|
||||
The demo will start three distributed notary nodes, and two counterparty nodes. One of the counterparties will generate transactions
|
||||
that transfer a self-issued asset to the other party and submit them for notarisation.
|
||||
|
||||
The output will display a list of notarised transaction ids and corresponding signer public keys. In the Raft distributed notary
|
||||
every node in the cluster services client requests, and one signature is sufficient to satisfy the notary composite key requirement.
|
||||
You will notice that subsequent transactions get signed by different members of the cluster (usually allocated in a random order).
|
||||
The output will display a list of notarised transaction IDs and corresponding signer public keys. In the Raft distributed notary,
|
||||
every node in the cluster can service client requests, and one signature is sufficient to satisfy the notary composite key requirement.
|
||||
You will notice that successive transactions get signed by different members of the cluster (usually allocated in a random order).
|
||||
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Run ``./gradlew samples:raft-notary-demo:deployNodes``, which will create node directories with configs under ``samples/raft-notary-demo/build/nodes``.
|
||||
2. Run ``./samples/raft-notary-demo/build/nodes/runnodes``, which will start the nodes in separate terminal windows/tabs
|
||||
Wait until a "Node started up and registered in ..." appears on each of the terminals
|
||||
3. Run ``./gradlew samples:raft-notary-demo:notarise`` to make a call to the "Party" node to initiate notarisation requests
|
||||
In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys
|
||||
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Run ``gradlew samples:raft-notary-demo:deployNodes``, which will create node directories with configs under ``samples\raft-notary-demo\build\nodes``.
|
||||
2. Run ``samples\raft-notary-demo\build\nodes\runnodes``, which will start the nodes in separate terminal windows/tabs
|
||||
Wait until a "Node started up and registered in ..." appears on each of the terminals
|
||||
3. Run ``gradlew samples:raft-notary-demo:notarise`` to make a call to the "Party" node to initiate notarisation requests
|
||||
In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys
|
||||
|
||||
To run from IntelliJ:
|
||||
|
||||
1. Open the Corda samples project in IntelliJ and run the ``Raft Notary Demo: Run Nodes`` configuration to start the nodes.
|
||||
Once all nodes are started you will see several "Node started up and registered in ..." messages.
|
||||
2. Run ``Raft Notary Demo: Run Notarisation`` to make a call to the "Party" node to initiate notarisation requests.
|
||||
In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys.
|
||||
|
||||
To run from the command line:
|
||||
|
||||
1. Run ``./gradlew samples:raft-notary-demo:deployNodes``, which will create node directories with configs under ``samples/raft-notary-demo/build/nodes``.
|
||||
2. Run ``./samples/raft-notary-demo/build/nodes/runnodes``, which will start the nodes in separate terminal windows/tabs.
|
||||
Wait until a "Node started up and registered in ..." appears on each of the terminals.
|
||||
3. Run ``./gradlew samples:raft-notary-demo:notarise`` to make a call to the "Party" node to initiate notarisation requests.
|
||||
In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys.
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``Notary Demo: Run Nodes`` configuration to start the nodes. Once all nodes are started you will see several
|
||||
"Node started up and registered in ..." messages
|
||||
3. Run the ``Notary Demo: Run Notarisation`` configuration to make a call to the "Party" node to initiate notarisation requests
|
||||
In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys
|
||||
|
||||
Notary nodes store consumed states in a replicated commit log, which is backed by a H2 database on each node.
|
||||
To ascertain that the commit log is synchronised across the cluster you access and compare each of the nodes' backing stores
|
||||
You can ascertain that the commit log is synchronised across the cluster by accessing and comparing each of the nodes' backing stores
|
||||
by using the H2 web console:
|
||||
|
||||
- Firstly, download `H2 web console <http://www.h2database.com/html/download.html>`_ (download the "platform-independent zip"),
|
||||
and start it using a script in the extracted folder: ``h2/bin/h2.sh`` (or ``h2.bat`` for Windows)
|
||||
and start it using a script in the extracted folder: ``h2/bin/h2.sh`` (or ``h2\bin\h2`` for Windows)
|
||||
|
||||
- The H2 web console should start up in a web browser tab. To connect we first need to obtain a JDBC connection string.
|
||||
Each node outputs its connection string in the terminal window as it starts up. In a terminal window where a node is running,
|
||||
@ -153,65 +180,75 @@ by using the H2 web console:
|
||||
|
||||
``Database connection url is : jdbc:h2:tcp://10.18.0.150:56736/node``
|
||||
|
||||
You can use the string on the right to connect to the h2 database: just paste it in to the `JDBC URL` field and click *Connect*.
|
||||
You will be presented with a web application that enumerates all the available tables and provides an interface for you to query them using SQL.
|
||||
You can use the string on the right to connect to the h2 database: just paste it into the `JDBC URL` field and click *Connect*.
|
||||
You will be presented with a web application that enumerates all the available tables and provides an interface for you to query them using SQL
|
||||
|
||||
- The committed states are stored in the ``NOTARY_COMMITTED_STATES`` table. Note that the raw data is not human-readable,
|
||||
but we're only interested in the row count for this demo.
|
||||
but we're only interested in the row count for this demo
|
||||
|
||||
Bank Of Corda demo
|
||||
------------------
|
||||
|
||||
This demo brings up three nodes: a notary, a node acting as the Bank of Corda that accepts requests for issuance of some asset
|
||||
and a node acting as Big Corporation which requests issuance of an asset (cash in this example).
|
||||
|
||||
Upon receipt of a request the Bank of Corda node self-issues the asset and then transfers ownership to the requester
|
||||
after successful notarisation and recording of the issue transaction on the ledger.
|
||||
|
||||
.. note:: The Bank of Corda is somewhat like the "Bitcoin faucet", that used to dispense free bitcoins to developers for
|
||||
.. note:: The Bank of Corda is somewhat like a "Bitcoin faucet" that dispenses free bitcoins to developers for
|
||||
testing and experimentation purposes.
|
||||
|
||||
To run from the command line (recommended for Mac/UNIX users!):
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Run ``./gradlew samples:bank-of-corda-demo:deployNodes`` to create a set of configs and installs under ``samples/bank-of-corda-demo/build/nodes``
|
||||
2. Run ``./samples/bank-of-corda-demo/build/nodes/runnodes`` to open up three new terminal tabs/windows with the three nodes.
|
||||
2. Run ``./samples/bank-of-corda-demo/build/nodes/runnodes`` to open up three new terminal tabs/windows with the three nodes
|
||||
3. Run ``./gradlew samples:bank-of-corda-demo:runRPCCashIssue`` in another terminal window to trigger a cash issuance request
|
||||
4. Run ``./gradlew samples:bank-of-corda-demo:runWebCashIssue`` in another terminal window to trigger another cash issuance request
|
||||
Now look at the other windows to see the output of the demo
|
||||
|
||||
.. note:: to verify the Bank of Corda node is alive and running navigate to the following URL
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Run ``gradlew samples:bank-of-corda-demo:deployNodes`` to create a set of configs and installs under ``samples\bank-of-corda-demo\build\nodes``
|
||||
2. Run ``samples\bank-of-corda-demo\build\nodes\runnodes`` to open up three new terminal tabs/windows with the three nodes
|
||||
3. Run ``gradlew samples:bank-of-corda-demo:runRPCCashIssue`` in another terminal window to trigger a cash issuance request
|
||||
4. Run ``gradlew samples:bank-of-corda-demo:runWebCashIssue`` in another terminal window to trigger another cash issuance request
|
||||
Now look at the other windows to see the output of the demo
|
||||
|
||||
To run from IntelliJ:
|
||||
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``Bank Of Corda Demo: Run Issuer`` configuration to start three nodes. Once all nodes are started you will see several
|
||||
"Node started up and registered in ..." messages
|
||||
3. Run ``Bank Of Corda Demo: Run RPC Cash Issue`` to request issuance of some cash on behalf of Big Corporation via RPC
|
||||
4. Run ``Bank Of Corda Demo: Run Web Cash Issue`` to request issuance of some cash on behalf of Big Corporation via HTTP
|
||||
|
||||
.. note:: To verify that the Bank of Corda node is alive and running, navigate to the following URL:
|
||||
http://localhost:10005/api/bank/date
|
||||
|
||||
.. note:: the Bank of Corda node explicitly advertises with a node service type as follows:
|
||||
.. note:: The Bank of Corda node explicitly advertises with a node service type as follows:
|
||||
``advertisedServices = setOf(ServiceInfo(ServiceType.corda.getSubType("issuer"))))``
|
||||
This allows for 3rd party applications to perform actions based on Node Type.
|
||||
For example, the Explorer tool only allows nodes of this type to issue and exit cash.
|
||||
|
||||
3. Run ``./gradlew samples:bank-of-corda-demo:runRPCCashIssue`` in another terminal window to trigger a cash issuance request
|
||||
4. Run ``./gradlew samples:bank-of-corda-demo:runWebCashIssue`` in another terminal window to trigger another cash issuance request
|
||||
Now look at the other windows to see the output of the demo.
|
||||
|
||||
Or you can run them from inside IntelliJ as follows:
|
||||
|
||||
1. Open the Corda project in IntelliJ and run the "Install" configuration
|
||||
2. Open the Corda samples project in IntelliJ and run the "Bank Of Corda Demo: Run Issuer" configuration
|
||||
3. Run "Bank Of Corda Demo: Run RPC Cash Issue" - requests issuance of some cash on behalf of Big Corporation via RPC
|
||||
4. Run "Bank Of Corda Demo: Run Web Cash Issue" - requests issuance of some cash on behalf of Big Corporation via HTTP
|
||||
|
||||
In the "Bank Of Corda Demo: Run Issuer" window you should see the following information lines displayed:
|
||||
In the "Bank Of Corda Demo: Run Issuer" window, you should see the following progress steps displayed:
|
||||
|
||||
- Awaiting issuance request
|
||||
- Self issuing asset
|
||||
- Transferring asset to issuance requester
|
||||
- Confirming asset issuance to requester
|
||||
|
||||
In the the client issue request window you should see the following printed:
|
||||
In the client issue request window, you should see the following printed:
|
||||
|
||||
- Successfully processed Cash Issue request
|
||||
|
||||
Launch the Explorer application to visualize the issuance and transfer of cash on each node:
|
||||
Launch the Explorer application to visualize the issuance and transfer of cash for each node:
|
||||
|
||||
``./gradlew tools:explorer:run``
|
||||
``./gradlew tools:explorer:run`` (on Unix) or ``gradlew tools:explorer:run`` (on Windows)
|
||||
|
||||
And use the following logon details:
|
||||
Using the following login details:
|
||||
|
||||
- for the Bank of Corda node specify localhost, port 10004, username user1, password test
|
||||
- for the Big Corporation node specify localhost, port 10006, username user1, password test
|
||||
- For the Bank of Corda node: localhost / port 10004 / username user1 / password test
|
||||
- For the Big Corporation node: localhost / port 10006 / username user1 / password test
|
||||
|
||||
See https://docs.corda.net/node-explorer.html for further details on usage.
|
||||
|
||||
@ -252,14 +289,6 @@ Also note that implementations of the SIMM are actually protected and subject to
|
||||
In the source code released, we have replaced their analytics engine with very simple stub functions that allow
|
||||
the process to run without actually calculating correct values, and can easily be swapped out in place for their real libraries.
|
||||
|
||||
|
||||
Open the Corda samples project in IntelliJ and run the "Simm Valuation Demo" configuration
|
||||
|
||||
Now open http://localhost:10005/web/simmvaluationdemo and http://localhost:10007/web/simmvaluationdemo to view the two
|
||||
nodes that this will have started respectively. You can now use the demo by creating trades and agreeing the valuations.
|
||||
Also see the README located in samples/simm-valuation-demo.
|
||||
|
||||
|
||||
What happens in the demo (notionally)
|
||||
*************************************
|
||||
|
||||
@ -277,32 +306,31 @@ Initial Margin Agreement Process
|
||||
- Agree on the calculation of the above with the other party
|
||||
- In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)
|
||||
|
||||
|
||||
Demo execution (step by step)
|
||||
*****************************
|
||||
|
||||
The demonstration can be run in two ways - via IntelliJ (which will allow you to add breakpoints, debug, etc), or via gradle and the command line.
|
||||
To run from the command line in Unix:
|
||||
|
||||
1. Deploy the nodes using ``./gradlew samples:simm-valuation-demo:deployNodes``
|
||||
2. Run the nodes using ``cd samples/simm-valuation-demo/build/nodes && ./runnodes``
|
||||
|
||||
Run with IntelliJ
|
||||
To run from the command line in Windows:
|
||||
|
||||
1. Open the ``corda`` project with IntelliJ
|
||||
2. Run the shared run configuration "SIMM Valuation Demo"
|
||||
1. Deploy the nodes using ``gradlew samples:simm-valuation-demo:deployNodes``
|
||||
2. Run the nodes using ``cd samples\simm-valuation-demo\build\nodes && runnodes``
|
||||
|
||||
Run via CLI
|
||||
To run from IntelliJ:
|
||||
|
||||
1. Navigate to the ``samples/simm-valuation-demo`` directory in your shell
|
||||
2. Run the gradle target ``deployNodes`` (ie; ``./gradlew deployNodes`` for Unix or ``gradlew.bat`` on Windows)
|
||||
1. Open the Corda project in IntelliJ and import the Gradle project
|
||||
2. Run the ``SIMM Valuation Demo`` configuration
|
||||
|
||||
a. Unix: ``cd simm-valuation-demo/build/nodes && ./runnodes``
|
||||
b. Windows: ``cd simm-valuation-demo/build/nodes & runnodes.bat``
|
||||
|
||||
Then (for both)
|
||||
3. Browse to http://localhost:10005/web/simmvaluationdemo
|
||||
4. Select the other counterparty (ie Bank B)
|
||||
5. Enter at least 3 trades - via the "Create New Trade" tab.
|
||||
6. On the "Agree Valuations" tab, click the "Start Calculations" button.
|
||||
Then, for both:
|
||||
|
||||
3. Browse to http://localhost:10005/web/simmvaluationdemo
|
||||
4. Select the other counterparty (i.e. Bank B)
|
||||
5. Enter at least 3 trades - via the "Create New Trade" tab
|
||||
6. On the "Agree Valuations" tab, click the "Start Calculations" button
|
||||
|
||||
Additionally, you can confirm that these trades are not visible from `Bank C's node <http://localhost:10009/web/simmvaluationdemo/>`_.
|
||||
|
||||
Please note that any URL text after `simmvaluationdemo` should not be bookmarked or navigated directly to as they are only for aesthetics.
|
||||
Please note that any URL path information after `simmvaluationdemo` should not be bookmarked or navigated to directly, as it is only provided for aesthetic purposes.
|
||||
@ -1,7 +1,7 @@
|
||||
.. _log4j2: http://logging.apache.org/log4j/2.x/
|
||||
|
||||
Introduction - What is a corda network?
|
||||
=======================================
|
||||
What is a corda network?
|
||||
========================
|
||||
|
||||
A Corda network consists of a number of machines running nodes, including a single node operating as the network map
|
||||
service. These nodes communicate using persistent protocols in order to create and validate transactions.
|
||||
@ -15,10 +15,10 @@ services, and one node may run several of them.
|
||||
* Regular node: All nodes have a vault and may start protocols communicating with other nodes, notaries and oracles and evolve their private ledger.
|
||||
|
||||
Setting up your own network
|
||||
===========================
|
||||
---------------------------
|
||||
|
||||
Certificates
|
||||
------------
|
||||
~~~~~~~~~~~~
|
||||
|
||||
All nodes belonging to the same Corda network must have the same root CA. For testing purposes you can
|
||||
use ``certSigningRequestUtility.jar`` to generate a node certificate with a fixed test root:
|
||||
@ -31,7 +31,7 @@ use ``certSigningRequestUtility.jar`` to generate a node certificate with a fixe
|
||||
java -jar build/libs/certSigningRequestUtility.jar --base-dir NODE_DIRECTORY/
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
A node can be configured by adding/editing ``node.conf`` in the node's directory. For details see :doc:`corda-configuration-file`.
|
||||
|
||||
@ -50,7 +50,7 @@ The most important fields regarding network configuration are:
|
||||
then this field must not be specified.
|
||||
|
||||
Starting the nodes
|
||||
------------------
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You may now start the nodes in any order. Note that the node is not fully started until it has successfully registered with the network map!
|
||||
|
||||
@ -61,7 +61,7 @@ You should see a banner, some log lines and eventually ``Node started up and reg
|
||||
In terms of process management there is no prescribed method. You may start the jars by hand or perhaps use systemd and friends.
|
||||
|
||||
Logging
|
||||
-------
|
||||
~~~~~~~
|
||||
|
||||
Only a handful of important lines are printed to the console. For
|
||||
details/diagnosing problems check the logs.
|
||||
@ -71,7 +71,7 @@ are by default redirected to files in ``NODE_DIRECTORY/logs/``.
|
||||
|
||||
|
||||
Connecting to the nodes
|
||||
-----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once a node has started up successfully you may connect to it as a client to initiate protocols/query state etc.
|
||||
Depending on your network setup you may need to tunnel to do this remotely.
|
||||
|
||||
@ -133,7 +133,7 @@ Party and PublicKey
|
||||
Entities using the network are called *parties*. Parties can sign structures using keys, and a party may have many
|
||||
keys under their control.
|
||||
|
||||
Parties may sometimes be identified pseudonomously, for example, in a transaction sent to your node as part of a
|
||||
Parties may sometimes be identified pseudonymously, for example, in a transaction sent to your node as part of a
|
||||
chain of custody it is important you can convince yourself of the transaction's validity, but equally important that
|
||||
you don't learn anything about who was involved in that transaction. In these cases a public key may be present
|
||||
without any identifying information about who owns it.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Building Transactions
|
||||
Building transactions
|
||||
=====================
|
||||
|
||||
Introduction
|
||||
@ -75,7 +75,7 @@ have to separately check that this is still the same
|
||||
The final stage of committing the transaction to the ledger is to
|
||||
notarise the ``SignedTransaction``, distribute this to all appropriate
|
||||
parties and record the data into the ledger. These actions are best
|
||||
delegated to the ``FinalityFlow``, rather than calling the inidividual
|
||||
delegated to the ``FinalityFlow``, rather than calling the individual
|
||||
steps manually. However, do note that the final broadcast to the other
|
||||
nodes is asynchronous, so care must be used in unit testing to
|
||||
correctly await the Vault updates.
|
||||
@ -292,7 +292,7 @@ final step is notarisation. This involves calling ``NotaryFlow.Client``
|
||||
to confirm the transaction, consume the inputs and return its confirming
|
||||
signature. Then the flow should ensure that all nodes end with all
|
||||
signatures and that they call ``ServiceHub.recordTransactions``. The
|
||||
code for this is standardised in the ``FinalityFlow``, or more explictly
|
||||
code for this is standardised in the ``FinalityFlow``, or more explicitly
|
||||
an example is:
|
||||
|
||||
.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/WorkflowTransactionBuildTutorial.kt
|
||||
|
||||
@ -327,7 +327,7 @@ Using state groups
|
||||
------------------
|
||||
|
||||
The simplest way to write a smart contract would be to say that each transaction can have a single input state and a
|
||||
single output state of the kind govered by that contract. This would be easy for the developer, but would prevent many
|
||||
single output state of the kind covered by that contract. This would be easy for the developer, but would prevent many
|
||||
important use cases.
|
||||
|
||||
The next easiest way to write a contract would be to iterate over each input state and expect it to have an output
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/codesets.js"></script>
|
||||
|
||||
The CorDapp Template
|
||||
The CorDapp template
|
||||
====================
|
||||
|
||||
This guide covers how to get started with the `cordapp-template`. Please note there are two Corda repositories:
|
||||
@ -61,7 +61,7 @@ Firstly, follow the :doc:`getting set up <getting-set-up>` page to download the
|
||||
already have it.
|
||||
|
||||
Working from milestone releases
|
||||
-------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you wish to build a CorDapp against a milestone release then please use these instructions.
|
||||
|
||||
@ -98,7 +98,7 @@ where ``local_branch_name`` is a name of your choice and ``tag_name`` is the nam
|
||||
Gradle will handle all the dependencies for you. Now you are now ready to get started `building the CorDapp Template`_.
|
||||
|
||||
Using a SNAPSHOT release
|
||||
------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you wish to build a CorDapp against the most current version of Corda, follow these instructions.
|
||||
|
||||
@ -199,7 +199,7 @@ Once you have published the Corda JARs to your local Maven repository, you are r
|
||||
CorDapp using the latest Corda features.
|
||||
|
||||
Opening the CorDapp Template with IntelliJ
|
||||
------------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For those familiar with IntelliJ, you can skip this section.
|
||||
|
||||
@ -252,7 +252,7 @@ see all available Gradle tasks.
|
||||
To execute a task, double click it. The output will be shown in a console window.
|
||||
|
||||
Building the CorDapp template
|
||||
=============================
|
||||
-----------------------------
|
||||
|
||||
**From the command line**
|
||||
|
||||
@ -306,7 +306,7 @@ folder has the following structure:
|
||||
└── runnodes.bat
|
||||
|
||||
There will be one folder generated for each node you build (more on later when we get into the detail of the
|
||||
``deployNodes`` Gradle task) and a ``runnodes`` shell script (batch file on Widnows).
|
||||
``deployNodes`` Gradle task) and a ``runnodes`` shell script (batch file on Windows).
|
||||
|
||||
Each node folder contains the Corda JAR, a folder for dependencies and a folder for plugins (or CorDapps). There is also
|
||||
a node.conf file. See :doc:`Corda configuration files <corda-configuration-file>`.
|
||||
@ -318,10 +318,10 @@ open on the right hand side of the IDE. Expand `tasks` and then expand `other`.
|
||||
start the build process and output progress to a console window in the IDE.
|
||||
|
||||
Running the CorDapp template
|
||||
============================
|
||||
----------------------------
|
||||
|
||||
Running the CorDapp template from the command line
|
||||
--------------------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To run the sample CorDapp navigate to the ``kotlin/build/nodes`` folder and execute the ``runnodes`` shell script with:
|
||||
|
||||
@ -385,19 +385,8 @@ Notably:
|
||||
|
||||
Additional files and folders are added as the node is running.
|
||||
|
||||
Running CorDapps on separate machines
|
||||
-------------------------------------
|
||||
|
||||
Corda nodes can be run on separate machines with little additional configuration to the above instructions.
|
||||
|
||||
When you have successfully run the ``deployNodes`` gradle task, choose which nodes you would like to run on separate
|
||||
machines. Copy the folders for those nodes from ``kotlin/build/nodes`` to the other machines. Make sure that you set the
|
||||
``networkMapService`` config in ``node.conf`` to the correct hostname:port and legal name of the network map service node.
|
||||
|
||||
The nodes can be run on each machine with ``java -jar corda.jar`` from the node's directory.
|
||||
|
||||
Running the example CorDapp via IntelliJ
|
||||
----------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To run the example CorDapp via IntelliJ you can use the ``Run Example CorDapp`` run configuration. Select it from the drop
|
||||
down menu at the top right-hand side of the IDE and press the green arrow to start the nodes. See image below:
|
||||
@ -428,10 +417,10 @@ To stop the nodes, press the red "stop" button at the top right-hand side of the
|
||||
The node driver can also be used to as a basis for `debugging your CorDapp`_
|
||||
|
||||
Interacting with the CorDapp template
|
||||
=====================================
|
||||
-------------------------------------
|
||||
|
||||
Via HTTP
|
||||
--------
|
||||
~~~~~~~~
|
||||
|
||||
The CorDapp defines a few HTTP API end-points and also serves some static web content. The end-points allow you to
|
||||
list purchase orders and add purchase orders.
|
||||
@ -554,7 +543,7 @@ Navigate to http://localhost:10005/web/example the refresh button in the top lef
|
||||
see the newly created agreement on the page.
|
||||
|
||||
Using the h2 web console
|
||||
------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can connect to the h2 database to see the current state of the ledger, among other data such as the current state of
|
||||
the network map cache. Firstly, navigate to the folder where you downloaded the h2 web console as part of the pre-requisites
|
||||
@ -583,11 +572,11 @@ You will be presented with a web application that enumerates all the available t
|
||||
query them using SQL.
|
||||
|
||||
Using the Example RPC client
|
||||
----------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``/src/main/kotlin/com/example/client/ExampleClientRPC.kt`` file is a simple utility which uses the client RPC library
|
||||
to connect to a node and log the 'placed' purchase orders. It will log any existing purchase orders and listen for any future
|
||||
purchase orders. If you haven't placed any purchase orders when you connect to to one of the Nodes via RPC then the client will log
|
||||
purchase orders. If you haven't placed any purchase orders when you connect to one of the Nodes via RPC then the client will log
|
||||
and future purchase orders which are agreed.
|
||||
|
||||
To build the client use the following gradle task:
|
||||
@ -612,10 +601,10 @@ application see:
|
||||
* :doc:`Client RPC tutorial <tutorial-clientrpc-api>`
|
||||
|
||||
Extending the CorDapp template
|
||||
==============================
|
||||
------------------------------
|
||||
|
||||
CorDapp-template Project Structure
|
||||
----------------------------------
|
||||
CorDapp-template project structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The CorDapp template has the following directory structure:
|
||||
|
||||
@ -739,7 +728,7 @@ In the file structure above, the most important files and directories to note ar
|
||||
Some elements are covered in more detail below.
|
||||
|
||||
The build.gradle file
|
||||
---------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is usually necessary to make a couple of changes to the ``build.gradle`` file. Here will cover the most pertinent bits.
|
||||
|
||||
@ -845,14 +834,13 @@ only requirement is that you must specify a node to run as the network map servi
|
||||
When you are finished editing your *CordFormation* the changes will be reflected the next time you run ``./gradlew deployNodes``.
|
||||
|
||||
Service Provider Configuration File
|
||||
-----------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you are building a CorDapp from scratch or adding a new CorDapp to the CorDapp-template project then you must provide
|
||||
a reference to your sub-class of ``CordaPluginRegistry`` in the provider-configuration file in located in the the
|
||||
``resources/META-INF/services`` directory.
|
||||
a reference to your sub-class of ``CordaPluginRegistry`` in the provider-configuration file in located in the ``resources/META-INF/services`` directory.
|
||||
|
||||
Re-Deploying Your Nodes Locally
|
||||
-------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you need to create any additional nodes you can do it via the ``build.gradle`` file as discussed above in
|
||||
``the build.gradle file`` and in more detail in the "cordFormation" section.
|
||||
@ -867,7 +855,7 @@ Unix/Mac OSX: ``./gradlew deployNodes``
|
||||
Windows: ``gradlew.bat deployNodes``
|
||||
|
||||
Running Nodes Across Machines
|
||||
-----------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The nodes can also be set up to communicate between separate machines on the
|
||||
same subnet.
|
||||
@ -900,7 +888,7 @@ purchase orders among themselves in the same way as when they were running on
|
||||
the same machine.
|
||||
|
||||
Debugging your CorDapp
|
||||
----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Debugging is done via IntelliJ and can be done using the following steps.
|
||||
|
||||
@ -935,4 +923,3 @@ Debugging is done via IntelliJ and can be done using the following steps.
|
||||
|
||||
5. Edit the “Debug CorDapp” run configuration with the port of the node you wish to connect to.
|
||||
6. Run the “Debug CorDapp” run configuration.
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Integration Test Tutorial
|
||||
=========================
|
||||
Integration testing
|
||||
===================
|
||||
|
||||
Integration testing involves bringing up nodes locally and testing
|
||||
invariants about them by starting flows and inspecting their state.
|
||||
@ -46,7 +46,7 @@ Next we connect to Alice and Bob respectively from the test process
|
||||
using the test user we created. Then we establish RPC links that allow
|
||||
us to start flows and query state.
|
||||
|
||||
Note that Driver nodes start up with test server certificiates, so
|
||||
Note that Driver nodes start up with test server certificates, so
|
||||
it's enough to pass in ``configureTestSSL()`` for the clients.
|
||||
|
||||
.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
|
||||
|
||||
Loading…
Reference in New Issue
Block a user