I want to create an obligation stating all the details about a particular property which is to be transferred to another party. So is creating this obligation a state?
Yes. In Corda any shared fact on the ledger is a state.
In general, CorDapps decompose into three main parts:
States, which describe shared facts
Contracts, which govern the evolution of these shared facts
Flows, which allow your node to execute some process, generally related to updating the ledger's shared facts
Related
Been reading up on Corda (no actual use yet) and other DLTs to see if we could use it in a project. What I was wondering after reading all the Corda key concepts: what would be the way to share data with everyone, including nodes that are only added later?
I've been reading things like https://corda.net/blog/broadcasting-a-transaction-to-external-organisations/ and https://stackoverflow.com/a/53205303/1382108. But what if another node joins later?
As an example use case: say an organization wants to advertise goods it's selling to all nodes in a network, while price negotiations or actual sales can then happen in private. If a new node joins, what's the best/easiest way to make sure they are also aware of the advertised goods? With blockchain technologies I'd think they'd just replicate the chain that has these facts upon joining but how would it work in Corda? Any links or code samples would be greatly appreciated!
You can share transactions with other nodes that have not previously seen them, but this sort of functionality doesn't come out of the box and has to be implemented using flows by the CorDapp developer.
As the author of ONIXLabs, I've implemented much of this functionality generally to make it easier for CorDapp developers to consume. There are quite a few feature-rich APIs available on GitHub.
In order to publish a transaction, the ONIXLabs Corda Core API contains functions that extend FlowLogic<*> to provide generalised transaction publishing:
publishTransaction called on the initiating-side of the flow, specifies the transaction to be published, and to whom.
publishTransactionHandler called on the initiated-by/handler side of the flow specifies the transaction to be recorded and who it's from.
As an example of how these APIs are consumed, take a look at the ONIXLabs Corda Identity Framework, where we have a mechanism for publishing accounts from one node to a collection of counterparties.
PublishAccountFlow consumes the publishTransaction function.
PublishAccountFlowHandler consumes the publishTransactionHandler function.
Scenario is I have two cordapps in same network. Party B of Cordapp 2 is requesting a data from Party A of Cordapp 1. So here Part A need to hide couple of fields from the state and need to expose to Party B as response.
Is it possible?
I have seen Transaction tear off, but I am not sure is it applicable here.
Please help
Maybe I'm misunderstanding but it should really only be a single cordapp that manages a particular set of states / usecases.
I think it's rare that there would be an instance that you'd want two different cordapps to be interoperable. This is an issue that should be fixed at the design.
Also remember that cordapps should be given only to the nodes you want to actually participate in specific transactions.
One of the business requirements I have been presented with is a potential process to purge customer related data (e.g. under GPDR).
This is a hosted solution where I have admin access on all the nodes.
Is there a way to delete states from Corda.
Can it be done without breaking potential links/references?
i.e. without "corrupting" the database or causing lots of errors when people walk the chain history etc
At the current stage, we don't support data deletion. You can manually delete the data from the database. However, if you ever need the data for future transaction, your node will throw an error.
This question was also answered here: Is Corda support state deletion scenario?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This is quite a general question regarding software design in a web application supposed to run on an intranet of a company. The basic design is simple: I have a backend (PHP) on a server, where a database (MySQL) is holding all data for the application. The application is used in a company and shall reflect employee related tasks. The frontend webpage (HTML, CSS) shows a UI for manipulating employee data etc.
A basic business object is here the employee, which is represented by a PHP class. When the frontend asks to show data for an employee, the query goes to the php class, which loads the employee data from database, instantiates an employee object and sends the employee data back to the client. Further queries from the client involve some logic that is done in the employee object, so I wanted to keep the just instantiated employee object in memory and use it again. I wanted to avoid the database access to load the employee data, instantiate object every time the client does a request.
So I created an object manager in PHP on server side which should store already instantiated business objects and provide them on demand or load objects required at the moment they are needed (lazy loading). But I realized that (of course) the server does not keep instances in memory between different http requests from the client, so my object manager does not work.
In a desktop application this would work, but not in a web application. Is this a bad approach for web application design? Is it normal that business objects are loaded and instantiated on every client request?
Another possibility is to describe and instantiate employee objects in javascript class and do this logic on the client side where objects can be kept in memory, isn't it? But I thought it is better to do business logic on the server to not stress the client to much.
I wanted to avoid the database access to load the employee data, instantiate object every time the client does a request.
You are headed for a great deal of complexity if this is really a requirement in your environment. I would benchmark the actual cost of just re-reading the data and judge if the added complexity is really needed.
You are trying to implement an object cache. If you solve the issue of keeping the object in memory between HTTP requests (it can be done), you will soon discover questions of concurrency (multiple clients acting on objects that you have cached) and the issue of transactionality (changes to the object cache must be written to the database in a transactionally consistent manner, among other issues.
If you really need this functionality, look into existing object cache implementations.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm reading about SOA and the four tenets thats required to make a SOA-application. I have tried different sources, but the explainations is twisting. Im searching for something that is a bit less abstract. Is my interpretation correct?
The four tenets is:
Services have explicit boundaries
Services are autonomous
Services share schema and contract, not class
Services interoperate based on policy
My interpretation is:
The methods that a client may use shall be easy to use and well
defined.
Services shall not be dependent on others. Change of one service
shall not affect another in any way.
A scheme represent the data that will be sent, contract contains the
defined methods for a service. To make a system loose coupled you
share scheme and contract instead of classes and objects.
A policy to use a service may be that a particular type of binding
is required so it may be used. Anyone that want to use this service,
must connect to it with this type of binding.
Got answer at programmers.stackexchange.com. Im reposting answer from GlenH7:
You're pretty close with your abstractions, yes.
Yes. Well encapsulated is another way of looking at this.
Yes, but... Service can rely on other services for functionality,
especially if that avoids duplication of code. The nuance here is in
the definition of dependent, I guess.
Yes. Services perform a contract for a scheme. User provides XYZ
data and the Service will provide ABC action per the contract.
I view services as operating against a business policy. Business
policy shouldn't get to the level of specifying binding. From the
implementing business policy point of view, you can see where some
services would be dependent upon other services in order to fulfill
their contract without duplicating code. At a broader level,
business policy is just a bunch of rules. Rules that hopefully
interoperate nicely with each. But just like human resources,
business rules have a nasty habit of not getting along with each
other as well. Services are the instantiation of those business
rules. From a lower level point of view, if the caller doesn't use
the advertised binding(s) then the caller will (obviously) be unable
to utilize the service. So while your statement is correct, it's a
bit of a tautology which doesn't enhance your understanding as much.