I am redesigning the old application--better to say designing the new application for which I want to take some parts of the old application to be more useful and extendable in future.
The old application is a desktop thick application that works on data shared on a file server. (It uses DBF database free tables, but the design is not client-server -- just a thick application.)
The new application is planned to use the client-server architecture with thick client, but the server should also provide the functionality through the REST API interface.
How a specific application server should be designed to be attachable both to a thick client, and to the web service?
The implementation should be portable (Windows, Linux), and also the web server should be or IIS (Microsoft) or a portable web server (like nginx, or so). The implementation language is C++11 plus (at least for the application server, and the thick client).
I am starting from scratch, and I also need to learn the technologies. (I do have experience with C++, and some theoretical knowledge on client-server, and RESTful; however, I need to learn the practical things.)
Comment as answer, as requested:
Consider google protocol buffers for the message encoding and decoding. Version 3 supports both json and binary encoding. It also has stubs for RPC, which you'll find useful.
Related
I have a question related to HTML5 as a desktop application replacement.
At present time my company developed a WinCE application in C++ language with a GUI in C++, that receives and sends messages to the Business Logic layer via sockets (C++ Windows App).
We would like to port this SW on Linux but to realize a cross compilable SW.
The whole application run on a single embedded PC (both BL and GUI) .
About presentation layer we was investigating the HTML5 possible solution, however I have some doubts.
In fact I read that some browsers supports the feature of web sockets, but it seems that this kind of sockets aren't generic TCP/UDP sockets, but are further specialized and their implementation is provided in server side classes, like Socket.IO (Java e node.js) and Jetty (Java).
So is there someone that can provide me some feedback about how/if it is possible to use HTML5 as presentation layer and send/receive updates from/to GUI via sockets to a application running on the same host machine as the web page?
I hope this question fulfill the requirements of the stackexchange "style" and rules, I made my best to be as clear as possible.
Best regards.
Giovanni Parodi
Nothing stops you from having your frontend and backend on same host talking via WebSocket over loopback.
I assume you are unwilling to port your backend to a different language, so you will need a C++ WebSocket implementation. I haven't followed what Microsoft provides in this area, but when using Boost/ASIO, I'd recommend to look at WebSocket++.
Further, WebSocket is still relatively low-level (send message bidirectionally). So you might want something higher-level. You might want to look at WAMP (The WebSocket Application Messaging Protocol), which provides you with RPC and PubSub messaging patterns. Using this, you can plug/exchange your frontend (e.g. have a native Android) talking to same, unchanged backend - same for backend. Decoupling.
There are clients and router(read: server) implementations for various languages.
Btw: WebSocket is supported by Chrome, Firefox and IE (beginning with version 10) -- and other browsers.
I'd need to know more about the specific side-conditions and requirements to give more hints ..
Disclosure: I am original author of Autobahn, WAMP and work for Tavendo.
I am looking for the best way to add support for a REST based Web Service to an MFC C++ Application. This is legacy code that has been around a long time.
I need to have the Application provide the Web Service. I've researched this, and the articles are about consuming Web Services in a C++ App. I envision having to monitor a port and respond to the HTTP requests. It would probably make more sense to tie in with WCF and IIS, but I am not sure how to move forward.
I already have a tool of "making" this App into a Windows Service. I realize it would be better to have a "real" app, and this is what I have to work with. There is so much logic in this code and we are limited in development time, so we are taking the fastest approach possible. We also cannot use DCOM, as the Web Service will be called by a Linux based system.
Any suggested articles would be much appreciated.
For C++ you can test two libraries WSF/C and gSoap, another alternative is to develop it with C# and WCF , and communicate between C# and C++ using C++\CLI.
I use the Poco Net c++ library for this as it supports both HTTP client and server functionality. I considered various other libraries including Boost based stuff, but other than Poco I struggled to find everything I needed in one tidy package. It also has some easy to use mutex support which became essential for me as soon as I added a web server front-end to what had previously been a simple single threaded console app. Poco is cross platform but I mainly use it windows and it has served me well to date. I'm not very clued up on MFC so I don't know how it would get on in that department though.
I am pretty new to web programming.I am developing a HTML5 based user interface which is supposed to use a middle ware written in C/C++.How can I do this?
I do not want to use any browser specific feature/library to communicate with the middle ware. Can we do the same at the server side and then send back the information to the browser? If so how can I achieve this communication with the middle ware at the server side?
Thanks in advance for the reply.
Note : I am planning to use Tomcat as the server in loop back.
As suggested above, you could use CGI (e.g., perl scripts) as a middle-man between the Tomcat server and your C++ middleware. What I also think might work well, and am planning on using myself in the near future, is to use boost::asio, and take the example HTTP server and modify it to use your middleware. You could then communicate between the Tomcat server and the C++ server using AJAX with JSON.
There is also something called pion server http://www.pion.org/projects/pion-network-library
It allows you to write the entire server in your own C++, with most of the common tasks abstracted away.
The Wt "web toolkit" library (pronounced "witty") may be of interest. Essentially all web-aspects are taken care of this, so absolutely no middleware. Here is an intro, quoting from the website:
The API is widget-centric and uses well-tested patterns of desktop GUI
development tailored to the web. To the developer, it offers
abstraction of web-specific implementation details, including
client-server protocols, event handling, graphics support, graceful
degradation (or progressive enhancement), and URL handling.
Unlike many page-based frameworks, Wt was designed for creating
stateful applications that are at the same time highly interactive
(leveraging techinques such as WebSockets and Ajax to their fullest)
and accessible (supporting plain HTML browsers), using automatic
graceful degradation or progressive enhancement. Things that are
natural and simple with Wt would require an impractical amount of
effort otherwise: switching widgets using animations, while being
perfectly indexed by search robots with clean URLs, or having a
persistent chat widget open throughout, that even works in legacy
browsers like Microsoft Internet Explorer 6.
It can run with its own web server (based on a Boost component) or be linked against standard web server libraries.
I wrote a short blog post about how to integrate it with another C++ component I wrote (RInside, which permits to embed R inside C++ apps) and by joining the two, I had a simple 'webapp' exporting R functionality to the web.
You can further enhance it via Javascript but that is something I have not looked into in any detail.
I am in process of building a web application + Mobile application (Android and iPhone to begin with). I know the functionality and can write functional specification. I haven't decided whether I should be build native apps or a mobile web app.
Since I will have a reusable functionality (used by web app as well as mobile apps), I should exposed core functionality as web services and consume it from views (Mobile, Web UI etc.)
My goal is to build faster. Application/platform should scale up well in future. I am low on budget, so am looking for open source or low-licensing fee stack (Java, LAMP, open source etc.).
I need suggestions on technology stack. Also if you have similar experience, let me know your experience.
Thanks a bunch.
I work on similar solution, ie. web-app + API + mobile apps and use:
Server side: Python + Django + Piston (for making REST API).
Client side: Native iPhone app (Android in the future)
I'm satisfied with my choice. Django allows to develop fast. Python is very expressive and quite fast (in terms of dynamic language). Piston lets you create REST API easily. All of these are free, of course.
Considering iPhone - a native app was a requirement, so I wasn't thinking about building mobile web apps.
It very much depends on the type of application you are talking about. From my company's experience and from listening to others, the choice whether to use native app or web app or hybrid app depends very much on the functionality you need to include.
One thing is logic, another is presentation.
Logic can usually reside on the server, but in case you need to work offline as well then at least some of this has to be done on the client. Then even if it is offline - you should decide if it is web app or native logic, but developing a web-browser complex offline logic which will be cross-platform might be more difficult sometimes than writing it twice natively. Really... So if offline is needed, I'd lean to native logic anyway. Otherwise you might think about appcelerator, but you will have big learning curve if you are used to web development. They say they are html + javascript but only about syntax - you have to learn the whole stack anyway.
Presentation - if you require simple list display with not a lot of graphical effects, not a lot of many pictures to browse through with simple few buttons, tabs, web is good to go - jquerymobile, phonegap are your friends there - phonegap especially if you need access to phone functions like camera or contacts. But if you need at least some level of smoothness, good user experience and something of a "wow" effect for the user there is no other way than a pure native applications - android and ios developed by joined multi-platform team (share concepts are more important than shared code IMHO).
For the backend - this might be pretty much everything, also depending on the functionality - how much other systems it should integrate with, how many users, what is the hardware infrastructure required, whether some cloud approach (google appengine, amazon) are considered etc. etc.
I'm designing a set of web services to allow our clients to connect from their apps to one of our systems. Our clients have their apps developed in all varieties of frameworks (.NET, Java, PHP, Python and even the occasional all JS app), so obviously WS is the way to go.
Investigating a little about truly interop WS I've found that the way to go is to design first the WSDL and XSD and derive the implementations from there.
What i'm really looking for is guidance if this is really the way to go. I've read that WCF creates interoperable WS but i'm not a fan of MS creating something standard.
Should i use WCF or there is a good set of tools for designing WSDL and XSD without the pain i'm expecting.
Thanks in advance
If you want to interoperate with JavaScript, then best to make more of a REST style API. This is basically just standard HTTP calls, so you're interopable from the get-go. However, you've kindof indicated that you want to use SOAP, so ...
If you're going with SOAP/WSDL, I'd definitely advocate using the server platform - yes, even .NET - to generate the WSDL, then simply check that the options you're using are producing a good, interopable WSDL.
I'm a Java developer with a history of PHP & Perl, and I've interoperated with .Net on a number of WS projects, from both sides of the coin (as server and client). There's usually no major problems - just be wary of a couple of things:
certain proprietary elements that MS
mixes in with the open standards. For
example, they may offer NTLM-style
authentication, which really isn't
needed in most use cases,
particularly when you're using SSL
certificates.
SOAP has taken a few
different forms over the years
(Document/Literal, RPC/Encoded, ...)
you'll probably find you don't need
to worry about this, as RPC/Encoded
died along with old frameworks, and
most modern frameworks tend towards
Document/Literal
SOAP offers a few
bolt-on standards (e.g. MTOM & DIME
for attachments, and SOAP-WS for
authentication). Try to avoid those
bolt-ons, as different platforms
implement different subsets.
For security, I'd advise to use SSL for
the trust & confidentiality, and then
either HTTP basic auth, or simply custom
string tokens in your soap request definition.
Just keep the WSDL as minimal as possible, try interoperating quite early in the process, and you shouldn't have too many problems
You can use WCF and contract-first development.
If interoperability is the main concern then I would recommend using WCF to provide the service implementation but instead of relying on WCF to generate the service interface to use contract-first development to model the interface.
A really good article on how to develop this way is Schema-based Development with Windows Communication Foundation.
If you are going to roll your own WSDL and schemas you are probably going to want to get an editor like XmlSpy or LiquidXml. I like the price of LiquidXML (free!) but I can't recall if you have to pay for the web service features.
Another interesting tool for contract-first development with Visual Studio and WCF is WSCF.blue. I haven't used it but it does appear to be actively developed based on the WCSF.blue roadmap.
WSDL and XSD are language independent, you just have to have some mechanism to communicate using other languages. Good thing for you to do would be IMHO core data design, so you would not need so many XSD for the same data entities.
I'm not sure what you mean when you ask "should I use WCF"? WCF is the current mechanism for developing web services (and other kinds of communicating services) on .NET. There is no other current mechanism. The others are obsolete, or else considered "legacy technology".