I want to create an application that consists of a web based front-end and a c++ back-end. My choice is to use websocket protocol in order to achieve data transfer between them.Specifically the front end will trigger some measurements that will be done in the back-end and eventually return and store the relevant values in the front-end. I decided for the websocket protocol implementation to use poco library and specifically I came across the following example https://github.com/pocoproject/poco/blob/develop/Net/samples/WebSocketServer/src/WebSocketServer.cpp. However since I haven't totally grasped the factory concept in C++ I haven't figured out the role of class RequestHandlerFactory.Is it possible for someone to explain what is the role of the aforementioned class and regarding my implementation (front-end -> trigger back-end -> back-end do measurements ->back-end returns the value to front-end in order to be depicted in a web-based gui) do I need to make any modifications to make this work for my case ?
As you might have read in the sample, there are two implementations derived from HTTPServer. So depending on the type of connection requested by the client (WebsocketRequest, PageRequest) one can return the appropriate HTTPServer. The work of factory class is to handle the incoming request, decide which class should handle it (depending on the connection requested).
Since you would be requesting to exchange data and not a request to display a HTML document, you should go for WebSocketRequestHandler. Yes it can be done. You might want to remove the PageRequestHandler since you wouldn't be using it.
Related
I am writing an application in C++ in windows, that has a UI (WxWidgets) and user normally use the application via its UI.
Now I have a new requirement, the application needs to start and controlled by another application.
I can not develop a DLL or similar solutions.
I have access to my code (apparently!) and the other applications is developed by other users, but I can give them details on how to control my application.
My question is: How can I allow other applications to control my application via a defined interface?
For simplicity assume that I developed a calculator (has UI) and I want to give other application to do math on my application (for example they may ask my application to add two numbers and so on, As the math is very time consuming, I need to inform them about progress and any error that generate during processing.
Can I open a pipe to communicate?
Any other way to achieve this?
You can use pipes or tcp/sockets with a custom protocol, but probably it's better if you split your application in two parts:
One part that does the computation
The user interface
and publish the first one as an http server responding to JSON requests.
Using a standard protocol can ease up testing and increases interoperability (you can also probably leverage already existing libraries for both implementing the server and the JSON marshalling).
Note that in addition to accepting commands, any error message you are going to show for example in a message box or any other nested event loop like dialog boxes need to be rewired properly; this can be very problematic if message or dialog box come up as the result of calls to external code that you didn't write yourself.
This is the typical change that would have costed 10 if done early and that will cost 1000 now.
This is the Documentation from Oracle Docs. I want to clarify certain jargon based questions.
On the server side, the developer specifies the web service operations by defining methods in an interface written in the Java programming language. The developer also codes one or more classes that implement those methods. Client programs are also easy to code. A client creates a proxy (a local object representing the service) and then simply invokes methods on the proxy.
In The first Bold lettered sentence,
Are these classes, the Implementation classes of the Web service ?
Second Bold lettered,
will the client create the object of those service implementation classes? If yes, how come? Will JAX WS transport the complete service implementation class code which is # server to the client?
I am very new to the concept of web services. if my doubt is silly please bear with me. Thanks!
First point. Yes you code the implementation of the web service. However this is just limited to the business logic you wish to execute you don't have to go code the low level boiler plate code like creating a HTTP socket etc.
A simple class that is exposed as a web service will look like this:
#Webservice()
public class CalculatorWS()
{
#WebMethod(#operationame="add")
public int add(#WebParam(name="i") int i, WebParam(name="j") int j)
{
//this is where you code your implementation
return i+ j;
}
}
A client proxy class does NOT transfer the implementation across the wire. It just creates a proxy that you can use to call the implementation.
You can learn all about it step by step by following this tutorial. It is easy one to understand and follow and will answer all of your questions.
I want my server app to be able to send data to be processed by a bunch of various clients, and then have the processed data returned to the server.
Ideally, I'd have some call like some_process = send_to_client_for_calculating(connection, data)
I just need to be able to send a bunch of data to a client, tell the client what to do (preferably in the same message, which can be done with an array [command, data]), and then return the data...
I'm breaking up pieces of a neural network (tis very large), and then assembling them all later.
If I need to be clearer, let me know how.
I'm shocked no one has thrown it out there... how about boost::asio.
Why don't you have a look at using Apache ActiveMQ? It's a Java JMS server, but it has C++ bindings, and does what you want with a minimum of writing networking code. You basically just subscribe to messages, and send responses back. The MQ server takes care of dispatch and message persistence for you.
You could try using beanstalkd, a fast working queue. I don't know if it fits your purposes. There is a client library written in C, which you should be able to use from C++.
I'd suggest looking at gSOAP, which implements SOAP in C++, including networking.
I use cwebpage_src code and I need to update some HTTP request headers while clicking on links. As I understand it can be done with self implementation of IHttpNegotiate->BeginTransaction. But how to get my IHttpNegotiate implementation called??
Thanks!
Although I have no experience of writing one, I believe that you need to write an asynchronous pluggable protocol, as recommended in this thread.
Details of how and why to do this are scattered around the web in various places, but the best exposition that I've read is in this post by Igor Tandetnik (abridged here for brevity):
There are several technology layers
that support the download and
navigation in Internet Explorer and
WebBrowser control. At the top, there
is WebBrowser itself and MSHTML object
that provides HTML parsing and
rendering. The client uses such
interfaces as IWebBrowser2 and
IHTMLDocument2 to communicate with
these high-level objects.
WebBrowser and MSHTML use URL Monikers
library to perform actual downloads.
URLMon exposes its services via
IMoniker and IBinding interfaces, and
the client (say MSHTML) implements
IBindStatusCallback and a number of
associated interfaces, e.g.
IHttpNegotiate or IAuthenticate.
Next down is an Asynchronous Pluggable
Protocol handler. An APP encapsulates
the details of a particular protocol,
such as http, file or res.
...
Most of the time, an application
hosting a WebBrowser control (or a BHO
running inside IE) uses high-level
services provided by WebBrowser and
MSHTML objects. However, sometimes
these services are insufficient, and a
lower-level hook is required.
...
It would be nice to be able to hook
into the communication sequence
between WebBrowser/MSHTML and URL
Monikers. Unfortunately, there does
not seem to be any way to do that - at
least, none that I know of. So, we
look at the next level - a
communication between a URL moniker
and an APP.
...
Now, it is rarely necessary to
implement a full-blown APP from
scratch - after all, how often do new
protocols actually get defined? But
for our purposes, it is useful to
implement a so-called passthrough APP
(pAPP). A pApp is an object that
implements both sides of URL
moniker-to-APP communication, that is,
it implements both IInternetProtocol
and IInternetProtocolSink /
IInternetBindInfo. We register it as a
temporary handler for a standard
protocol, such as HTTP. Now whenever
an HTTP request needs to be sent, URL
moniker will create an instance of our
pAPP and ask it to do the job. The
pAPP then creates an instance of a
standard APP for the protocol in
question (I call it a target APP, or
tAPP, but be aware that I've invented
the terminology myself, it's not
widely accepted, suggestions for a
better naming convention are welcome)
and acts as its client. At this point,
our pAPP becomes a proverbial
man-in-the-middle. In the simplest
case, any method call made by URL
Moniker on pAPP is forwarded to tAPP,
and any method call made by tAPP on
pAPP is forwarded back to URL Moniker.
The pAPP gets to observe and, if
desired, modify every bit of
information relevant to this request
passing back and forth between the
moniker and the tAPP.
Igor has a couple of sample projects that should help in writing your own pAPP:
PassthruApp.zip
PassthruAppBeta.zip
SOAP is continuing to confuse me.
In RMI, there are remote objects, which live on the remote server. You can pass them around, but this will just create stubs locally. The stubs delegate all method calls over the wire.
This is quite different from pure data objects, which are serialized and sent as a copy.
Are there remote objects in SOAP? From what I have seen so far (did not dig deep, though), there are complex objects that can be passed around (as arguments or return values), but those are "just" data carriers.
You may find it helpful to read up on the WebServices standards such as WS-I Basic Profile,
which say things like:
SOAP 1.1 defines a message exchange
model for processing of messages.
In other words this is is about passing messages between different systems.
As a client of a SOAP service you have no idea whether or not there are objects at the other end and (at least in common practice) the payloads you receive do not give you back reference objects on which you could invoke further remote messages. For example if you had (in concept)
Order getOrder( int orderId )
and Order looked like
Order { int orderId;
Customer { String name, String TelephoneNumber ... }
}
There Customer "object" there has no methods you invoke that result in remote work.
The SOAP interface has payloads expressed purely in terms of data.
Lanaguge bindings, to enable us to code (for example) Java to invoke a SOAP/HTTP give us local proxies objtecs for the service, but that does not imply an RMI-like remote object model.
Since SOAP is language agnostic, there can't be any remote objects. Which language should be be in?