Non-http channels

[erikalfthan]

It would be nice to add channels that are not http, like python SocketServer or gevent StreamServer. I havent read the code and Im not a seasoned ESB developer so I dont know what that implies, but my company's back end has some strange back-ends that are speaking legacy protocols, where socket level is the last common level.

[dsuch]

Hi @jicksnooker and thanks suggesting it.

As far as implementation goes, the main servers are based on gevent's WSGI ones and that is very convenient - pretty much everyone uses HTTP now and in Python using WSGI is what one needs to do.

Other protocols - WebSphere MQ, AMQP and ZeroMQ - are started in dedicated sub-processes, partly because they open their own sockets in C, hence they are not friends with gevent.

My question would be, what do you need a raw TCP server for? Why not HTTP? If you can shed some light, what are your requirements that dictate such a low-level option as direct sockets? Perhaps it can be done some other way?

Cheers!

[erikalfthan]

The background is that I work as a solution architect in the payment industry, where one of the most common interface is ISO_8583, but also others like EPAS SPDH, ep2 and all sorts of stuff. These are typically with tons of custom variation between countries but functionally very close. It would be nice to be able to accept more of them to a lower cost than implementing them in a mainframe

EDIT: Im not currently working as a developer, but if I could build a PoC, it would be possible for me to create a business case where I would get the resources to actually build and put something really cool and rare in the payment business.

[dsuch]

Ah yes, I've had my share of MF programs, no worries, I understand the banking background very well :-)

I know COBOL can send XML/SOAP just fine so naturally, in your situation the question only is if your existing applications support anything than raw sockets. They probably don't and you can't touch them either?

When you say MF, I take it as z/OS so you probably already use WebSphere MQ which Zato does out of the box. This is one direction.

Another point is that you can easily open TCP sockets directly in outgoing connections.

The question only is, like you say, how to make it work in Zato channels.

How important is that feature for you? Would you be willing to contribute code or sponsor the development to make it available sooner than, say, within 4-7 months?

My email is dsuch@zato.io if you'd like to discuss it in private.

[dsuch]

A related, yet not closely tied to it, question is that of all the parses for these industry formats once the messages are transported across to you.

I don't know if there are Python parsers for it. But that just as an aside regardless of TCP connections.

[erikalfthan]

The problem will probably not be our backend, but rather if we have to act as server to someone elses old protocol - something I would not be able to change.

If I can make a case, we might implement something where HTTP is enough for all channels, and clients can as you say be custom written when outgoing. If I reach that point, I should have code contribution and I might be able to get sponsorship from my company.

Until then, thanks for the feedback, it confirms my view and idea, and the time frame indication might come handy to prove that it is realistic.

On the related question, it is actually quite straight forward to convert the protocols to python dicts/json or some basic xml, I have even implemented a gevent + pyro based "tiny ESB" just to verify that the performance wouldnt be an issue. zato has a nice gui, LB, dynamic stuff and monitoring that I definitely never got around to do...

[aek]

Maybe zeromq can be used for the network communication, it create sockets like components that can be used to build networking architectures and Zato has support for it