We have used "Yo!CorDapp" example (https://github.com/corda/spring-observable-stream) to build a POC.
In this POC, can we replace angular by .NET for frontend and use IIS webserver in place of springboot webserver to talk to Corda platform?
Thanks
You can use any front-end technology you want.
As of Corda 3, your backend must be JVM-based, for two reasons:
You need to load various flow, state and other class definitions onto the classpath to pass as arguments to flows, retrieve objects from the vault, etc.
You need to use the CordaRPCClient library to create an RPC connection to the node
If you really need to write your back-end in another language, there are a few workarounds:
Create a thin Java webserver that sits between your main webserver and the node. The Java webserver translates HTTP requests from the main webserver into RPC calls to the node, and RPC responses from the node into HTTP responses to the main webserver
This is the approach taken by libraries such as Braid
Use a library such as GraalVM to compile non-JVM languages to JVM bytecode
An example of writing a JVM webserver in Javascript using GraalVM is available here: https://github.com/nitesh7sid/cordapp-example-nodejs-server-graalvm
Related
We have airflow as workflow management tool to schedule/monitor tasks and also some have applications using Spring cloud dataflow for loose coupling across processes via producer and consumer talking message bus Kafka and Grafana dashboards for UI (ETL). Kubernetes and AWS (EKS) are options for deployments.
We are starting to creating data pipelines which will have sources( Files on S3 or server or databases), processors( custom applications, AL/ML pipelines ) and destinations (Kafka, s3, databases, ES). I am planning to use airflow to manage overall management of pipelines and tasks within pipeline via SCDF based applications or future applications written python as AL/ML piece expands. Is this correct approach or can I let go of one over other?
Based on your requirements, SCDF would fit and provide options to manage your streaming data pipelines.
While you can still research to find any other possible approaches, I can provide some more hints on what SCDF provides to meet some of your requirements.
SCDF provides out of the box apps which you can extend/customize. These apps include S3 source and sink which you can use out of the box. For a complete list of out of the box apps, you can refer the page here
Apparently, SCDF has Kubernetes deployer which you can work on any Kubernetes based platforms. You can configure your K8s specific properties as a set of kubernetes deployer properties when you deploy the applications.
You can embed a python based application as a processor/transformer in the streaming data pipeline. You can check this receipe from the SCDF site to know more about this.
You can also embed tensorflow application as a processor application inside a pipeline.
I am designing a CorDapp, which would require user input as well as API integration, and I am considering various approaches to expose flows and vault queries to the outside world.
Default option seems to be to use Corda RPC. Unless I missed something, there are only Java bindings for it, which is effectively restricting the clients to only be JVM-based. This is somewhat inconvenient, and ideally I would like something like OpenAPI to make it more open and implementation-agnostic.
Another option is to use some kind of Corda RPC to OpenAPI proxy. I know about Braid, and I'm sure there are others. Braid seems to support deployment as a Corda service packed together with the flows into the CorDapp itself, effectively making it running embedded into the Corda JVM.
Braid can be deployed as a standalone proxy too, which I suppose is option three.
Instinctively I find the embedded mode more attractive, as it reduces the number of moving parts, as opposed to a standalone mode. However, I am concerned that such model may be in fact become discouraged at some point, either because Corda developers consider it to be a misuse of services facility, or because some organisations will not be keen to deploy such code onto their nodes, especially when they may be running multiple CorDapps. I would imagine anything deployed as part of Corda JVM would at least require more scrutiny due to potential impact on other things running there, which in turn would reduce the agility.
I wonder what approach to integrate with a CorDapp is actually recommended?
Edit 1: I know it is technically possible to embed a webserver into the node and expose a REST API from there, at least in the current version of Corda (4.3 at the time of writing). The question is more about whether it is a good idea to do so, or not, and why.
Take a look at the question I had asked on Stackoverflow regarding front end for CordApp. This might be of some help.
Following is the link -
"Corda: Can we develop Dapps that will be run by IIS webserver to talk to Corda platform?"
You can use any front-end technology you want.
As of Corda 3, your backend must be JVM-based, for two reasons:
You need to load various flow, state and other class definitions onto
the classpath to pass as arguments to flows, retrieve objects from the
vault, etc.
You need to use the CordaRPCClient library to create an
RPC connection to the node
If you really need to write your back-end
in another language, there are a few workarounds:
Create a thin Java webserver that sits between your main webserver and
the node. The Java webserver translates HTTP requests from the main
webserver into RPC calls to the node, and RPC responses from the node
into HTTP responses to the main webserver
This is the approach taken
by libraries such as Braid
Use a library such as GraalVM to compile
non-JVM languages to JVM bytecode
An example of writing a JVM
webserver in Javascript using GraalVM is available here:
https://github.com/nitesh7sid/cordapp-example-nodejs-server-graalvm
By reading the docs, it is clear that the only way to interact with corda is via RPC. If you want to interact via http, then we have to write a web server exposing specific endpoints.
I am trying to write a rpc client to start a flow in the cordapp without webserver.
rpcOps.startTrackedFlowDynamic(ExampleFlow.Initiator.class, iouValue, otherParty)
I couldn't understand properly here. Should I duplicate the ExampleFlow class both on client end and in the cordapp? What is the structure of rpcclient and cordapp in this case of not having a web server?
tl;dr Write a client to start a flow on already running corda node without webserver? Thanks
Yes - currently, the client must depend on ExampleFlow.Initiator and have it available on the classpath. This is true whether it's a webserver or a regular command line client.
Background-
I am extremely new to CORDA and Blockchain Platform. In the past few months i have had my share of experience working on a small project on Ethereum as platform. Ethereum blockchain was leveraged as ledger to mark Transaction as a proof of existence. It means for some action (success/failure) we have marked respective transaction on Blockchain. We may consider it as a proof of concept to show knowledge of interaction with nodes running on Ethereum Blockchain.
Infrastructure - Node.js web services, two ethereum (PoA) nodes
Question-
I would now like to port this running example on to CORDA blockchain. How would i achieve this with bare minimum changes. That means if i have a Corda network with two nodes running on my system and i want my web services to connect to one or both of the nodes and save the transaction (in its state). I understand that this certainly is not what CORDA might be meant for. Consider this question as my first step to interact with CORDA from Node.js web services.
Any inputs highly appreciated.
I recommend you go through the documentation first. your Tx will be a state. you need to build contracts and flows for a Tx to happen. Tx will happen using flows which will be initiated using Crash Shell or RPC Client. AFAIK, this client is in Kotlin or Java. so you'll have to create a JAVA or Kotlin application to instantiate this client. now in the Java application, you'll have to expose rest endpoints to communicate with the client which will initiate your flows. you can call these rest endpoints from your node application. All this has to be created in CodaApp. This is the bare minimum.
I just found there is a library.
look at this: https://gitlab.com/bluebank/braid
This can help you.
I need to implement simple file watcher utility. I have decided to implement this in a simple windows service which will internally use FileSystemWatcher. The purpose is to monitor given directory path (or ftp) and copy the file to some other server wherever new file comes in after checking some predefined logic
As I am using .net 3.5; client suggested me to use WCF. I have very less experience in WCF.
I am not sure how I can create WCF service which will function like WindowsService and can be deployed in services on windows server.
To be a futuristic is it a good idea to create WCF service instead of windows service, or I should insist on window service.
Windows Service != WCF
You can't create a WCF service that acts functions like a windows service. A WCF service waits for messages from third parties and acts on them, a windows service is a process that is always running in the background. WCF tries to solve the problem of separating out the communication mechanism (transport protocols such as Tcp, Http, Named Pipe, etc) from the service interfaces.
File Watcher Utility
While in theory it's possible to create a new Flat-File binding in WCF that "could" have it's address set to a file system location, one does not exist directly in the .NET framework. Looking at the Custom Bindings article on MSDN it's not immediately obvious to me how one would construct a File System binding. These are the defined transport options available:
TCP
HTTP
HTTPS
Named Pipes (IPC)
Peer-to-Peer (P2P)
Message Queueing (MSMQ)
Custom
If communication must be done through file drops, then WCF does not solve your problem.
Where WCF Might Work
What the client might have meant is to create a WCF endpoint that does the copy the file to some other server wherever new file comes in after checking some predefined logic, but you would still want to have a windows service with a FileWatcher monitoring the input directory.
If you have multiple clients that need to be able to perform that same logic and then send the output to that other server then it might make sense to make the WCF service, otherwise it's over-engineered at this point.
You should choose the simplest option until you find a need to change, with the simplest option being a Windows Service.
There is a coding principle call YAGNI (you ain't gonna need it) that applies in this case as simply wrapping something up in a WCF service would do nothing but add unneeded complexity for the majority of cases. Simply put do the minimum viable solution and extend only when you need to.
PS. If you are using the FileSystemWatcher over network shares note that there are documented problems with it and you should use a combination of a poll + FileSystemWatcher. There are lots of explanations on Stack Overflow about it.
In your use case, the Windows Service makes a lot more sense and I think that to be the more appropriate solution. You need something that is always running and monitoring a directory and thats exactly the use case which Windows services are very good at.
I would consider talking to the client and explaining the Windows Services are the more appropriate solution to this kind of use case. Also, windows services are not old hat, they are there to solve exactly these kinds of use cases and WCF / windows services complement each other.
Both features have Service in their names by they have virtually nothing in common.
A Windows service runs constantly on a single machine.
A WCF service is code than can be called remotely by other machines.
It simply depends on what you need to do. A Windows Service and a "WCF service" have little in common.
The question here is whether you need a HTTP endpoint or not. If you do, you could even host a WCF service in your windows service to provide that. Keep in mind that a WCF is only used as a way to communicate between applications.
Reading your description, though, it doesn't seem like you need it.
WCF Service in a Managed Windows Service