From a Corda business network design perspective, may Corda oracles propose transactions? Reading the Corda Docs about oracles, my impression is "no", but maybe I'm misreading, or reading too much into the docs, e.g.,
"Oracles are network services that, upon request, provide commands that encapsulate a specific fact (e.g. the exchange rate at time x) and list the oracle as a required signer."
ref: https://docs.corda.net/releases/release-V2.0/key-concepts-oracles.html?highlight=oracle
Oracles are just regular Corda nodes, and any Corda node can serve as an oracle, provided it is trusted to provide a certain set of facts. Although oracles may differ from other nodes from a business perspective in that they are recognised providers of trusted facts, they are identical from a technical perspective.
Related
I am trying to understand the applicability of pluggable consensus in corda.
For example, the consensus service from hedera hashgraph can be plugged into corda,technically. But I am not clear why it is needed?
Can anyone help me in understanding with an appropriate business use case?
Corda is an incredibly powerful toolkit for building business networks in a distributed manner. One assumption of Corda today is that it depends on either a centralized notary, or the need to configure a network of notaries, in order to provide uniqueness consensus of the Corda transactions.
The Hedera Consensus Service addresses this dependency. Rather than building a cluster of notaries, or trusting a single notary, transaction hashes can be sent to the Hedera Consensus Service which provides a consensus timestamp of the message by the globally distributed Hedera Mainnet. Any notary or member of the Corda network can independently verify the timestamp. This can provide a more decentralized and resilient infrastructure, as well as reduce the operating burden and cost of configuring the Corda network.
More information can be found on the corda notary here: https://github.com/hashgraph/hedera-hcs-corda-demo
I am pretty new to corda and I am curious if it is possible to do a cross compatibility zone DvP. According to https://www.corda.net/2017/08/compatibility-and-upgrades/ it is possible to have different corda newtorks in a global network.
My question addresses following use case:
let's say I have two corda networks (compatibility zones). Each network has its own notary, nodes, customers & KYC process and is supporting a certain asset.
The first network provides for example a payment infrastructure and the second network a securities network.
Is it possible to do that by using R3 corda, if yes is there any example/tutorial?
Thanks in advance for any support!
The answer is yes but I think we're talking at cross-purposes :) Networks operated and governed by different entities are intended to form and operate WITHIN a compatibility zone.
The way I think it's most helpful to think of Compatibility Zones is to imagine the concept just doesn't exist... imagine there was just ONE Corda network (ie CZ) that everybody used (that was transparently/openly governed so no one firm/group of firms controlled it)... and then all the different apps and business networks existed within it... able to interoperate and transact across each other, because their nodes were compatible... they would understand and accept each other's transactions, etc.
Think about it from the perspective of a firm installing a blockchain node: getting onto any blockchain network (a Corda CZ or whatever the equivalent concept is for other platforms)... getting an identity, punching the right holes in the firewall, setting up the node infrastructure... it's analogous to the work needed to get a firm "on the internet" - setting up routers, getting IP addresses, etc, etc.
It's the kind of thing you want to do once and then reuse ruthlessly. The idea that you would have to connect to an entirely new communications network for each app your firm used would be ludicrous. And yet that's how some people seem to think blockchain deployments should be: ie for each app, you set up a separate blockchain network with its own nodes and settings and identity layer and consensus providers. But that's surely just nonsense, right?
You want to connect to a global network once and then reuse that infrastructure.
So the idea is that we try to have as few CZs as possible and encourage as many business networks as possible to form within that small number of CZs.
I know this can mess with your mind when you first hear about it because all the other enterprise blockchain platforms are going in totally the wrong direction (in my opinion..!) They seem to be encouraging the formation of a separate private network for each application. But that just seems crazy to me.
So maybe try this: even if you think I'm mad, play along with the idea for a day or so and see if it begins to grow on you :) If not, let's debate it again but I really do think this idea of multiple apps on the same overall shared network (ie multiple business networks in a single compatibility zone) is just so amazingly powerful as a concept.
So to your answer: can you do cross-app/cross-business-network DvP within a CZ? Yes! That is one of the key use-cases we invented Corda to solve... it's almost perfect for those sorts of scenarios.
Could you do it if the two apps were on different CZs? Well, yes... but it would be like asking if you could do DvP between assets managed in different databases or hosted on different blockchains.. it's just messier... needing locking and 2PC and all the stuff that we can just eliminate if we hold ourselves accountable for not creating needless balkanisation/siloed deployment through deployment of standalone networks unless they're really, really needed.
I am writing Corda App for financial transactions between companies. The incoming transaction initiates a business workflow at the receiving end. Can Corda flows be used as a general purpose BPMN software or is it a better design to use a separate BPMN software and trigger flow in that system?
It really depends on the kind of BPMN you have in mind.
However, within a flow you have full access to any JVM libraries. You can perform networking (see the Flow HTTP sample here), DB reads (see the Flow DB sample here), and anything else.
I'm a developer and I'm interested in blockchain technology.
I only have a few knowledges of networking, including peer to peer P2P.
On the internet, I can't find the answer for this question : Must I use a client application to interact with a blockchain (to perform transactions & to participate in the construction of the blockchain).
If there's no need, how can I proceed ?
Think of all these different blockchains as communication protocols. At their heart, that is all Ethereum and Bitcoin are - a suite of specifications as to how peers should talk to each other. Thus, "interacting" with a blockchain is essentially establishing communication with other peers and then exchanging information with them. Well, that only entails following the protocol of that blockchain, because otherwise the peers will disregard you. You can do that by either coding your own software against the specifications, or downloading a pre made client that blockchain makers typically provide.
Blockchain is not singular. There might be differet number of blockchain in this world.
Coming to your question, if you want to develop an app/learn the technology it will be better to get yourself acquianted with Ethereum and some basic Blockchain concepts. There is a full length course available on Coursera on Blockchain and cryptocurrency. I would suggest you to finish that first and then move to development.
I am curious if it even makes consider BizTalk for the implementation of a pub/sub messaging architecture (basically what you can do with NServiceBus or MassTransit is all I really need). My manager tends to want to stick with frameworks provided directly from Microsoft and so as part of my due diligence as to which one to use I need to give a good set of pro/cons for both sides. Any guidance would be greatly appreciated!
One of the major cons of a Broker is that it is very difficult to version and upgrade. You would have to stop the flow of messages to upgrade a particular endpoint(s). A Service Bus allows endpoints to be autonomous and be upgraded independently.
Then there is a difference in terms of scale. With a Broker the tendency is to scale those up(vertical) versus a Service Bus which is built for scaling out(horizontal). You would also have to make the Broker highly available through some sort of HA setup(clustering usually). This combined with the cost of software to do so can become pretty cost prohibitive.
NSB in particular will be offering a paid support model so if your manager is nervous about not having someone on the other end of the line when something goes wrong, you can buy into support.
Biztalk is a broker and is more suited for EAI within the boundaries of different business services. A servicebus is fundamentally different. A comparison can be found here:
http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk
If you can share some of your requirements I might be able to give some more guidance.
It's important to note that BizTalk is a server product for Enterprise Application Integration (EAI -- as Andreas mentioned). It's more involved and complicated than a framework.
Microsoft does have the Enterprise Service Bus Toolkit available to use within BizTalk, so that you can call your BizTalk environment your ESB. What they consider "ESB" may not be what you consider ESB. You can take a look at their ESB Toolkit page (http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx), but it includes things like:
Dynamic (i.e., at run-time) message
transformation and translation.
Message routing can be content-based, itinerary-based, or context-based, and determined at run-time.
Of course, the publish-subscribe pattern is not the same thing as using a service bus.
BizTalk does do pub-sub well, whether or not you use the ESB Toolkit. It's extremely simple to publish a single message to the BizTalk "Message Box", and have the message routed to any and all subscribers. The pub-sub solution means that BizTalk acts as a broker, but this helps guarantee that messages do not get missed, and all messages are tracked. A BizTalk pub-sub solution has built-in extensibility points that allow us to add, change, or remove endpoints without impacting the rest of the solution.
All that being said, your requirements may not dictate extensive message reliability, monitoring, and tracking, so it could be that BizTalk is not the best fit for you. It is a large investment, and since the product can do so many different things all at once, it can be daunting at a first glance.
A new book was just published call Applied Architecture Patterns on the Microsoft Platform, which covers much of this. One of that book's authors, Richard Seroter, also published SOA Patterns with BIzTalk Server 2009, which would be essential reading if you do decide to go with BizTalk for your company.
I'm with Andreas on this - BizTalk is generally more suited to 'value add' integration and business process management, rather than ESB type activity. BizTalk is good at:
BPEL
Long Running / Compensated Transactions
EAI
Brokering / Mapping
Protocol changes (MQ to WCF, Flat File to SAP etc)
EDI, RFID
However, efforts have been made to use BizTalk as a service bus, notably the ESB Toolkit