I have some EDI files that need to be sent to a partner, this partner accepts transfers only using the AS3 protocol (Applicability statement through FTP). I have already implemented an FTP(S) server, but I need to enhance it to meet the AS3 requirements as defined in the RFC 4823.
After browsing most of GitHub, I couldn't find a single implementation of the AS3 protocol, do you know any open source implementation, any language is fine (preferably in PHP or Python) ? Or do I have to implement it my self following the RFC ?
Related
I know that Corda is in the process of removing its web server module and in the documentation they suggest the use of other frameworks.
In one example ("spring-observable-stream") they use Spring Boot for the server-side APIs and use an RPC call to the actual running Corda node. That's fine and comparable with what I have to do.
In that example, the author import the specific Corda's RPC code, along with the code of the actual flow (and states) needed.
What I want to ask here is if it's possible to avoid that tangle and keep the web server APIs independent from the actual Corda/CordApp's code by using a general RPC library (any advice ?).
If, instead, I must import the Corda-specific code (there is a reason ?), I'd like to ask you:
What is the minimum necessary to do so from a Gradle perspective ?
Is it possible to implement some sort of plugin on the CordApp to reduce that tangle ?
To be honest, I'm interested in a more general way for interacting with the CordApp (e.g. from Python), but I know that due to the AMQP integration not yet ready, we have to stay on the JVM for now. So, feel free to answer just about what we need to do as of today from Kotlin (which I have to use for a short-term PoC)…
Thank you in advance!
Currently, your server has to depend on the Corda RPC library to interact with nodes via RPC. Corda doesn't yet expose an independent format for sending and receiving messages via RPC.
Your server also needs to depend on any CorDapps that contain flows that the server will start via RPC, or that contain types that will be returned via RPC. Otherwise, your server will not be able to start the flows or deserialise the returned types.
If you're using Gradle, here's what a minimal dependencies block might look like:
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
cordaCompile "net.corda:corda-rpc:$corda_release_version"
compile "com.github.corda:cordapp-example:release-V1-SNAPSHOT"
}
Here, we're depending on the corda-rpc library, and also using JitPack to depend on the CorDapp where we define the flows and states that we want to start/return via RPC.
If you want, you can modularise the CorDapp so that all the classes you need to depend on for RPC are included in a separate module, and only depend on that module.
I have a multiserver multiclient application and I would like to keep some common data managed by a single daemon (to avoid a nightmare f concurrency), so the servers can just ask it when they need to manipulate the shared data.
I am already using libevent in the servers so I would like to stick to it and use it's RPC framework but I could not find an example of it used in real world.
Google Protobuf provides a RPC framework. And it is also used inside Google for RPC and many other things.
Protobuf is a library for data exchanging.
It handles data serialization, deserialization, compression, and so on.
It is created and opensourced by Google.
However, they didn't opensource the part of RPC implementation.
It only provides a framework.
You can integrate Protobuf with your existing libevent program.
I have personally implemented a RPC with Protobuf and libev(which is a similar project to libevent). And they work fine.
I have a telephony scenario in which the following happens:
Customer calls a Voice Gateway
TCL script runs and a code is taken from customer
Authentication is done through a RADIUS server
Customer will hear correct voice menu
The problem is that RADIUS server must connect to a SQL Database and check the credentials. I have currently designed the solution using cisco secure ACS and through managed stored procedures on MS SQL server.
My question is: Is the VoiceXML a better tool to do this job and because some extenstions and wrappers of VoiceXML exists in .net, does it fit in this simple scenario??
Sincerely speaking, I am a little confisued with the technology and looking for a good tutorial on its features as well.
Thanks
In a strict sense, only step 4 is implemented by VoiceXML. Other aspects are handled by the platform or external code. VoiceXML is the standards mechanism for implementing step 4, but if all you are going to do is limited audio output and simple input, it may be overkill depending on the solutions available to you.
The following is just an example of a way to solve your problem and is fairly fictitious given I don't know anything about your environment nor constraints.
Given most VoiceXML platforms, upon receiving of a call your VoiceXML application will be executed. If this is a servlet/ASP based solution, you can perform steps 2 & 3 then generate/return the VoiceXML to play the menu, gather the input and move to the next step. If this is a static VoiceXML 2.1 solution, you can use a Data element call to make an HTTP request to a system that can perform these actions. The system will need to return XML that the Javascript/ECMAScript in VoiceXML application can parse and provide the correct audio output and input processing.
Since you are asking about VoiceXML, I'm assuming your challenge is the telephony aspect of the problem. Unless you have a system already available, choosing and activating a premise or hosted solution is far more complicated than the call flow code involved. Depending on your requirements, there are solutions as low as a single line, analog modem that supports audio output and DTMF input to massively scaled on premise and hosted solutions to handle 10,000s of concurrent calls that implement VoiceXML as well as a wide range of other call flow technologies.
VoiceXML would work fine in this scenario. There is a an open source project called VoiceModel that uses ASP.NET MVC to generate the VoiceXML and therefore integrates nicely with the .NET stack. There are a lot of examples in the project with discussions on how to use the examples in this blog. The examples use Voxeo Prophecy as the VoiceXML platform which has a SIP interface that will connect with a Voice Gateway. You can download two ports for free to try it out.
As a followup to Does ServiceStack support binary responses?, I'm wondering whether there are injection points built (or planned) to use binary serializers such as Mark Gravell's protobuf-net for efficiency between non-HTTP clients. In fact, it might not be long before protocol buffers work in JavaScript.
Yep, ServiceStack has a custom pluggable format API where its own built-in CSV Format and HTML Report Format are both registered using it. The tutorial of Nortwind Database's custom v-card media type shows how to register your own format/media type using this API.
Support for protobuf-net is planned for the near future. There was someone on the ServiceStack Group looking at exploring adding support for it. In any case, I plan to be catching up with protobuf-net's author soon so I'll find out the best way of how to add support for it then.
What can we do to integrate code written in a language with code written in any other language? Which techniques are more/less known? I know that some/most languages can be compiled to Java bytecode, but what do we do about the rest ?
You mention the "compile to Java" approach, and there's also the "use a .NET language" approach, so let's look at other cases. There are a number of ways you can interoperate, and it depends on what you're trying to accomplish, it's a case by case situation. Things that come to mind are
Web Services (SOAP or REST)
A text (or other) file in the file system
Use of a database to relay state or other data
A messaging environment like MSMQ or MQSeries
TCP sockets or UDP messages
Mailslots and named pipes
It depends on the level of integration you want.
Do you need the code to share data? Use a platform-neutral data format, such as JSON, XML, Protocol Buffers, Thrift etc.
Do you need to be able to ask code written in one language to perform some task for code in the other? Use a web service or similar inter-process communication layer.
Do you need to be able to call the code within a single process? The answer at that point will entirely depend on which languages you're talking about.
Direct invocations:
Direct calls (if the compilers understand each other's call stack)
Remote Procedure Call (early 90's)
CORBA (late 90's)
Remote Method Invocation (Java, with RMI stack/library in target environment)
.Net Remoting
Less tightly integrated:
Web services/SOAP
REST
The two I see most often are SWIG and Thrift. The main difference is (IIRC) Thrift opens up a port and puts a server there to marshal the data between the different languages, whereas SWIG builds library interface files and uses those to call the specified methods.
I think there are a few possible relationships among programs in different langauges...
There's shares a runtime (e.g. C# and Visual Basic) and compiled into same application/process...
There's one invokes the other (e.g. perl script that invokes a C program)...
There's talks to each other via IPC on the box, or over the network (e.g. pipes and web services)...
Unfortunately your question is rather vague.
There are ways to use different languages in the same process usually by embedding a VM or an interpreter into the executable. If you need to communicate over process boundaries there again are several possibilities many of them have been already mentioned by other answers.
I would suggest you refine your question to get more helpful answers.
On the Web, cookies can be set to pass variables between ASP/PHP/JavaScript. On a previous project I worked on, we used this to create a PHP file for downloading PDFs without revealing their location on the file system from an ASP application.
Almost every language that pretends some kind of system's development use is capable of linking against external routines with either a standard OS interface, or a C function interface. That is what I tend to use.