In my grpc application, I need to have a service that has just two client-side streaming methods. Is it possible to define the service, messages without creating a .proto file in grpc-java?. If yes, can you point me to an example or tutorial.
Related
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.
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
While reading through the Java documentation on the grpc website, I found the newBlockingStub and newStub generated methods being referenced.
My main interest in grpc is to use a single connection to handle multiple rpcs in parallel.
By making multiple calls to newBlockingStub/newStub, do I get all these stubs to use the same underlying connection, and thus still have my rpcs working in parallel?
The Channel manages sharing a single connection with multiple RPCs. As long as stubs use the same underlying ManagedChannel, they may share a single connection.
I say may share a connection, since the ManagedChannel can be configured with different policies, for things like load balancing. The point is that ManagedChannel handles those decisions and the stub isn't impacted.
I am trying to implement CoAP as my custom transport protocol for Kaa platform. I've done customization guide creating custom transport step by step, but in the last part (Transport provisioning), it seems that some config files should be created automatically but I can't find any *.config file related to my implemented CoAP class in server/transports package. Neither in /kaa/server nor in /etc/conf sub-folders. Any idea about what should I do?
This attached image show how my implementation developed ‒ project hierarchic.
If it is still relevant for you:
First of all, I don't see in your project neither implementation of transport configuration schema nor transport descriptor. Follow this steps:
Create avro schema that defines configuration parameters for the
transport and compile one with avro maven plugin (look how this done
for tcp transport).
Once you've done with schema, implement the transport descriptor in order to Kaa node can look up your custom transport.
Secondary, the config file for you custom transport you should create manually. The example of config files for tcp and http located in server/node/src/main/resources both for operation and bootstrap servers.
Finally, compile and package your custom transport project into jar artifacts (two jars ‒ config classes and classes related to CoAP transport). Put this jars to /usr/lib/kaa-node/lib on your server, config files ‒ /usr/lib/kaa-node/conf. After that restart the node and enjoy a newly created transport for CoAP.
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