I want to create a new transport processor on WSO2 ESB. This transport is to provide ISO 8583 message processing and transform Raw TCP to SOAP message, vice versa. On the source code, there is a transport management object and inherited by several transport service class such as JMS, HTTP, HTTPS, etc. I have several questions:
How the transport management object works?
Is that possible to recode TCP service source code and redeploy with my customized actions?
Thanks.
WSO2 ESB is backed by Apache Synapse and it uses Axis2 Transports to provide the transport layer. You can write a new Axis2 transport and plug it to WSO2 ESB. resources can be found at here and here.
Regards,
/nuwan
Another way to expose the raw TCP to the ESB, could be to create an ActiveMQ queue to listen the raw TCP and make them available to the ESB.
There are custom transport implementations in the WSO2 ESB which has written for specific customer requirements. FIX (Financial Information Exchange) is such a custom transport. You can get an idea about writing a custom transport if you go through the source code of this transport.
https://github.com/wso2/wso2-synapse/tree/master/modules/transports/optional/fix
Here is a blog post which I have written to explain the process of creating a custom transport for ISO8583 protocol.
http://soatutorials.blogspot.com/2015/06/extending-wso2-esb-with-custom_21.html
Related
I understand that gRPC is designed for client-server architecture. A server provides remote services and clients obtain the services by calling the defined RPCs. But is it possible for a client also defines a service so that other clients can request services from that client too?
An example, a server knows every client's locations and can inform other clients about the location information. A client, upon receiving the other clients' locations from the server, can now directly call the services provided by other clients.
Can gRPC do that? Thank you!
Yes, this is possible.
The terms "client" and "server" are overloaded in this context and would be better thought of as (stub) caller and (implementation) receiver. It's possible for the client and server to be the same process but then you don't need the complexity of gRPC.
There's no prohibition on some entity functioning as both a caller ("client") and receiver ("server"). This situation arises commonly, in peer-peer networks and in micro-services where some original client calls some service which (acts as a client and) then calls various other services ....
short question : How can I host an MQTT server on my remote Ubuntu 16 server while at the same time hosting an HTTP server that will be using the MQTT data ?
true question : I want to build an IoT system that will be MONITORED and CONTROLLED by ESP32, which will SEND FEEDBACK and ACCEPT COMMANDS respectively from a remote server (maybe LAMP ?). I also want the user to log-in in a website hosted on this remote server, where s/he can monitor any sensor values or send commands (e.g. turning a led on or off).
So what's the way to go here?
I was adviced to go with MQTT but then the above problem arised.
what I've found : I 've found that using Mosquitto MQTT, I may be able to serve a website using websockets. But I prefer a more scalable HTTPS approach. That is, I intend to have a database linked with my site and running my PHP scripts.
I'm not that experienced, so please don't take anything for granted :)
MQTT uses TCP connection and follows publish/subscribe API model where as the web(http) follows Restful API model(Create,read,update,delete). If you want to stick with MQTT then you should use SAAS service like enterprise MQTT from HIVE which provide this integrability but will charge some fees and in return, they will provide you with an account and a dashboard for all your devices. Otherwise, you can try to make your own middleware which can integrate MQTT with web services .
Another thing I would recommend is CoAP which is also an M2M protocol but follows Restful API model and UDP connection. It has direct forward proxy to convert coap packets to https packets and vice versa.
In MQTT you have a central server(Broker) to which the nodes send their data and fetch their required data through topic filters.
In CoAP each device having some data to share becomes a server and the other device interested in it's data becomes a client and sends a GET request to the respective server to get its data. Similarly a PUT request along with a payload from a client would update the value at the server.
You really should not be looking to combine the MQTT broker with a HTTP server, especially if you intent the HTTP Server to actually be an application server (Running back end logic e.g. PHP). These are 2 totally separate systems. There is nothing to stop your application logic connecting to the broker as a client.
If you intend to use MQTT over WebSockets you can use something link nginx to proxy the WebSockets connection to the broker so it can sit behind the same logical HTTP/HTTPS address.
I need to develop an application which would run in a corporate network. The client should both receive commands (shutdown, restart, ...) and send info (something happened, ...) from/to the server. So, using a web interface, the network administrator would be able to see what clients are connected, send commands to them, and see real-time info coming from them. The client should be written in Delphi (normal VCL forms with Edits, etc.) and the server "preferably" in ASP.Net.
I researched a bit and I think WebSockets might be good to achieve this. I plan to use some WebSocket libraries for Delphi like this. I'm not sure what technology I should use for the server.
Please tell me if WebSockets is good for my requirements. Other solutions are welcome (maybe writing the server in Delphi?).
Web interfaces typically are HTML based views, and require a web HTTP server and a web browser (Chrome, Firefox, etc.). Delphi Web Socket client libraries however can only be used to talk with a Web Socket server from within a native Delphi application, for example a VCL GUI.
If you plan to write a VCL application (not web browser based), you have other transport protocol options besides Web Sockets, which are widely used in small and large systems:
MQTT (formerly Message Queue Telemetry Transport)
STOMP (Streaming Text Oriented Messaging Protocol)
AMQP (Advanced Message Queuing Protocol)
MSMQ (Microsoft Message Queuing)
As with WebSockets, these protocols offer asynchronous / bi-directional messaging. On the server side you can choose from many production quality implementations of these protocols (known as 'message brokers'), mostly free / open source. Similar to HTTP, message payload can be anything - text or binary data - and messages can use headers to provide application-defined metadata.
Your server-side application code can be written in Delphi, and is only another client of the message broker, communicating with the client applications over the message broker protocol. As soon as client and server are connected to the message broker, messages can flow in both directions.
Many advanced features are included in message brokers: if a client disconnects while the server is still sending messages, the message broker can store these messages and deliver them as soon as the client reconnects.
For most of these protocols I have seen client libraries or wrappers for Delphi / Object Pascal, free and open source or commercial.
Here is what I am trying to do:
Pick up files from various locations using BizTalk
Debatch the data
Publish a message to NService bus.
The question is how to publish a message to NSB when the underlying transport for NSB is SqlServer and not MSMQ?
Have you considered exposing a Service in NServiceBus as a WCF endpoint? You can then call the WCF endpoint from Biztalk.
When looking at SOA (Service Oriented Architectures) the main problems seems to be distributing a services load across multiple hosts and then managing these hosts (taking hosts off line or adding new hosts)
When one service talks to another it should not need to know any host information (at the application level). Rather the SOA Environment should be able to route a service request to a specific host based on the hosts current load characteristics (so it must know all hots a service is running on and their relative load).
Are there any existing open protocols for service to report their existence and load to an SOA Environment.
SOA is a set of high-level software architecture guidelines. It is not a technical standard or recommendation and it has nothing to do with technical implementation details, like load balancing.
Load balancing is based on addressing, which is dependent on the service access technology.
Systems built in "SOA-way" may be using different service access technology, like SOAP (over HTTP, JMS, etc.), REST, asynchronous XML messages over JMS, etc.
With SOAP, the service consumer may look up a UDDI registry to locate the service provider. Some of the latest UDDI registry software provide simple (e.g. round-robin) load balancing.
Another SOAP idea is using WS-Addressing, but it is not really meant for load balancing.
I think currently the best place for load-balancing is the underlying network transport layer. With HTTP transport you can choose hardware or software (e.g. Apache HTTPD modules) load balancers that can adapt the distribution based on response times and time-outs. With JMS transport, the most popular JMS servers provide some form of load balancing. Other protocols - like CORBA or Rendezvous - usually require a custom solution.
You can also utilize an ESB software, e.g. Oracle Service Bus or TIBCO AMX Service Bus. With an ESB you can easily create a load-balancing proxy for your service instances. The proxy may be enhanced with some logic, like look-up a database table for guidance.
As you can see, there is no one-size-fits-all solution for service load balancing. The optimal solution will be based on the actual implementation architecture and vendors' recommendations.
After reading a lot the concept I was actually looking for was the Enterprise Service Bus ESP.
Though it does not explicitly define an explicit protocol it defines an architectural style that allows the solving of the problems I stated above.