I'm working on a project that will include a server and a client component that will send/receive requests / information over TCP/IP. The server component will be developed in c++ and I will be using boost.asio libraries. Client component will be an excel add-in and will be developed in visual basic. I have few general questions and please note that I'm not expecting any specific response here but expecting to hear some concepts so I can focus on.
My questions are as below.
The server and the client will be developed in different languages, is there anything to worry about socket communication between two developing languages?
I want the application to have login/authentication mechanism through integration with LDAP systems. Is there any c++ libraries that I can use for this purpose? (like boost.asio for TCP)
Is there any concept that you can suggest user session management in c++
As part of my application, there will be need to transfer data from the server to the client or vice versa. This data can sometime be like hundreds to thousands rows with hundred of columns. What is the best way to transfer such data through sockets? Is arrays good for this?
I know my questions are very high level and basic but your answers will point me the right direction and will help me to focus on the right concepts.
Thanks in advance.
The server and the client will be developed in different languages, is there anything to worry about socket communication between two developing languages?
Not really, as long as you have a clearly defined wire format. Either use an existing one, like HTTP/JSON, or define it yourself explicitly. When the interface is a bit more complicated, consider to use something like CORBA or ICE.
I want the application to have login/authentication mechanism through integration with LDAP systems. Is there any c++ libraries that I can use for this purpose? (like boost.asio for TCP)
There is a C++ API for OpenLDAP. I have no experience with it, so no recommendation or warning here.
Is there any concept that you can suggest user session management in c++
It depends on what you need. The easiest approach is a vector of shared pointers to session objects ordered by age, but those sessions will all be invalid when the process ist restarted. Sessions in memcached survive a restart of the process. When you want to survive the restart of a machine, I'd prefer the session data in a relational database, or files.
As part of my application, there will be need to transfer data from the server to the client or vice versa. This data can sometime be like hundreds to thousands rows with hundred of columns. What is the best way to transfer such data through sockets? Is arrays good for this?
You might use a simple format for each object and simply stream the objects. E.g. CSV, or JSON. Also consider a binary fixed format, when most of your information is not already text. What is the best depends on the type of data, of course.
Related
I have an interesting conundrum. I have been challenged with identifying the most suitable process in which to create a "browser front-end" to an existing multi-user application built within the TigerLogic/Pick D3 environment. My research indicates there are many ways to do this; but I am struggling to decide which method is best or where to start. I have "played" with a few technologies but a commitment to one is needed to get started.
These methods include:
Creation of a complex webservice using MVS Toolkit; and engineering a client from WSDL either from scratch or using maven/wsimport. Tests indicate there is a lot more to this process than originally though for a simply WSDL.
Development of a Java based web app that harnesses the MVSPJavaAPI - I am not a JAVA developer so this means learning a new language. Development would most likely take place in Eclipse.
Using TigerLogics FlashCONNECT - resulting in additional expenditure to clients so not preferable - and more or less ruled
out.
There is also the .NET option - but I have ruled this out on the basis of needing portability.
My question is, has anyone else out there done anything like this and could you share your experience? My first task is to build a web-app that will reliably give me the D3 TCL prompt in a browser that I can customise.
I am not sure there is a definitive answer here but would like peoples thoughts and will label the most useful as the answer.
What path you choose depends in some part on your existing skill-set and whether that fits in with your portability needs. It is very difficult to give you a concrete answer to your question becaue of not knowing in which part of the chain you need the portability.
It is however possible to develop a web-browser front-end using .NET which will run on Linux or Windows, so I don't see an issue with portability here. Your web server will have to be windows based but it shouldn't matter whether D3 is running on Linux or Windows at the server-end, or whether the client desktops are running Linux or Windows.
You could try TigerLogics MVSP .NET API but I do not know if it has the power to deliver based on your needs. I believe you may find mv.NET from Bluefinity could fulfill your needs. This is in my opinion the leading product on the MultiValue market for achieving the goals you have in mind. This will mean spending money of course. For this you will get a very powerful set of tools. Also, the cost of investing in a good tool could end up smaller than the cost in terms of time, effort and potential complications of trying to do this piecemeal without spending any extra money. I am sure Flashconnect would also do the job. You would have to weigh up the cost of the different options to find out which one is right for you both technically and financially.
Not knowing whether or not you have .NET in your skill-set, I don't know whether the .NET option would be easier for you. It is however technically possible.
I would suggest using Rocket's D3 (formerly TigerLogic D3) .NET APIs and create a Web API RESTful service that you can consume with JavaScript in any other web technology and if you need to call from a D3 subroutine (in case you would) then use the MVS Toolkit.
Requirements though are D3 9.0 or later.
I've used all of the technologies described, and many more to interface with D3. I agree with #Glenn and will add... I understand you're edging away from .NET. That's fine, you don't need it. But consider that most LAMP implementations separate the DBMS servers from the web servers. That topology introduces short delays between the tiers but decouples them in case you want to use multiple web servers or multiple databases - a common topology even with D3 / MV.
I have a client where we have a Java/Grails front-end over Linux, with all data queries filtered through a single, elegant data provider class that's abstracted from application logic. That uses a web service call which I wrote in Java, calling to a .NET web service. The service is easily generated/modified, as is the client from the WSDL. From there IIS carries inbound queries to D3 via mv.NET, and at this point it doesn't matter if the D3 DBMS is in Linux or Windows. My web service could have as easily been in Linux with Java but it would then lack a pooling mechanism - see below.
If you want all Linux then you can go with the MVSP Java library. TigerLogic (now acquired by Rocket Software) committed to a PHP binding for MVSP some months ago. Rather than wait, one of my clients created a PHP wrapper around mv.NET, though MVSP is as easy. So the resulting application is essentially LAMP, but with the M = Multivalue. I have written code like this too - we can write a wrapper in any language which exposes a useful API and abstracts both connectivity method and OS dependencies. In other words it doesn't matter what languages we want to use or what OS's are involved. That part is rather trivial and subject to change later. It's better to focus on the application than the communications.
You can also go off the menu, so to speak, and create your own Java/PHP wrapper around the OS-level d3tcl command, which is a script/wrapper around the d3 executable. This allows you to open a connection yourself and pass in commands.
Whatever option you select, you need to consider that opening and closing a DBMS connection is a slow process. You do not want to script a login around every data request. You do want to open a connection and keep that open persistently, while your client code accesses and releases that persistent connection as required. This is why we like mv.NET and FlashCONNECT. With MVSP and other mechanisms you need to create your own persistence model. You'll also need to manage a pool of connection resources - what happens when you get 10 simultaneous queries, or just 1 short one after one long one? You don't want queries to back up, you don't want to reject or timeout connections, and you don't want to fire up a connection for every client. You do want the proper number of DBMS sessions waiting for inbound connections. mv.NET and FlashCONNECT do this for you, the others do not.
Personally I'd shy away from FlashCONNECT. I was there for its initial development and testing and for years of end-user implementations. It's not as widely used as the other options and is more a tool for those who aren't familiar with other options. If you're talking about Java then you're probably not inclined to use FlashCONNECT. That said, if you have developers who are not familiar with anything outside D3 then FlashCONNECT is a decent server-side tool for them while someone else is focusing on the client-side with other technologies. Everyone should use their best skillset.
Finally, (already?) if someone is not familiar with external technologies, and more intimate with D3, then other options exist like DesignBAIS and Viságe, mostly removing the burden of communications and allowing developers to work on the client-side features and back-end rules in BASIC.
I discuss all of these topics plus mobile and telephony on my blog.
HTH
How or what do I need to know programming wise in order to interact with the web using c++. For instance i want to wrote a program that automatically sends invites to players on yahoo chess. How would i go about doing this?
You'll need to understand the basics of TCP/IP and HTTP, possibly UDP, and the protocols involved with Yahoo's chess systems or posses a tool to work around them (A brief search leads me to believe there are few if any). You'll probably need a network API, I'd suggest looking at:
QtNetwork Module
Boost.Asio
Where Qt is easy to use, Asio is more powerful, and more 'C++' in nature. Qt has some nice webkit components, and I've used it to build a small web server, which was a lot of fun. You can accomplish quite a lot with it.
This page says they've added a captcha system to prevent certain people from interacting with their systems. I'm not familiar with Yahoo games and what the result of this has on what you'd want to do, however it suggests to me they'd rather you didn't write code to interact with their systems.
For this you need to use network APIs and use server side script like PHP/ASP to communicate with the web and C using message queue.
How should a Windows 8 Metro application connect to a central database?
I've read about local storage, but I haven't read anything about connecting to a central database.
Obviously, this architectural design decision needs to support the disconnected scenario.
WCF web services seem to make sense.
But even if they do make sense, should we really create separate methods for all read/write operations?
Or are OData WCF services the way to go?
It seems like tablet software architecture should be able to borrow a lot from smartphone software architecture (but I am new to both).
Has Microsoft made any recommendations in its app samples?
It appears that others are asking similar questions on the Microsoft Developer Forums.
Here is what I've found:
According to Tim Heuer:
...You cannot directly have a SQL db embedded in your app or use
something like ADO.NET. This is more of an async/services
infrastructure. So if your data was exposed via services, then of
course you could connect that way. There are some other light-weight
methods you could use for local storage as well using things like the
Windows.Storage namespace (which is similar to Isolated Storage in
.NET).
Morten Nielsen agrees:
You can use HttpClient to download pretty much anything from the web.
Why don't you configure your WCF service to return data as JSON, and
use the DataContractJsonSerializer to deserialize the results?
Also, Tim Heuer cautions:
...Please note that while awesome, the SQLWinRT project on codeplex is a
wrapper to communicate with the classic SQLite engine...which uses
APIs that would not pass store validation currently.
Generic Object Storage Helper for WinRT and WinRTFile Based Database seem to have some promise.
But Daniel Stolt raises some good points:
It's awesome that there is good support for building OData clients and
other REST clients - but this only addresses the online scenario. The
"structured" part of Windows.Storage is a very limited model,
essentially limited to name/value pairs, insufficient for all but the
most basic scenarios. Yes there is local file storage, which is great
of course. But forcing every app developer out there to build her own
DBMS on top of local file storage will simply not cut it, especially
with all of System.Data having been removed from the profile. If local
file storage was sufficient for most device apps, then things like
SQLCE would have no purpose today already. And SQLCE clearly has a
purpose, and has played a very important role for occasionally
connected device apps for a very long time. There is also a tremendous
need for synchronization with a server-side database such as SQL
Azure, mostly to be able to roam data between devices. Yes there is
the roaming storage model in WinRT, but it shares the same limitations
of local storage mentioned above, and on top of this is very limited
in capacity (currently 30KB if memory serves). It is simply
insufficient for all but the simplest roaming data needs. Again,
forcing every app developer to design and implement her own
synchronization solution is very bad. You can do much better to enable
developers.
Many people are disappointed that the System.Data namespace is not supported in WinRT.
Richard Bethell said:
I don't even have words for this. This is astonishing. Leave aside for
the moment they want to force you to abstract to middleware for
database connectivity - I don't agree, but I can quasi understand a
rationale for that. I can even see pathways for developing like that.
But no System.Data.... at all? Do you even understand what you've done
to us?
What System.Data can do, outside of just having providers for Sql,
OleDb and other custom providers like Oracle, is provide a rich
abstraction of XML datasets that allow you to very quickly build a
data oriented Service Oriented Architecture.
For instance, I can easily create a web service using SOAP or WCF that
returns DataSets or DataTables, and then consume those objects easily
and directly. Being able to do this allows very rapid construction of
n-tier architectures, even without direct data connections available.
Without System.Data, and the power of DataViews, DataTables, etc. this
gets a lot harder. Sure you can custom create structs, put data in
there, and serve up structs, and use Linq to do whatever sorting,
filtering, etc. you want to do.... but it ends up being twice the
work, and makes code reuse a lot harder. And it means using our
existing service oriented architecture is impossible (without a big
overhaul.)
The withdrawal of System.Data is as big a thing for developers to deal
with as the loss of the Printer object in VB6 to vb.net 1.0 was. What
is harder to understand in this case is why it is necessary -
re-enabling it in the Metro profile can't possibly be a technical
difficulty of the product, can it?
It is valuable enough that I would seriously consider including Mono's
System.Data classes as part of any app I create (which would obviously
have to be open source.)
I think that this is another of those "it depends" questions...
The first and most obvious issue is that it very much depends on the context in which the application is running as to whether, to take the first case "Obviously...support...disconnected" is actually true - if the app is an internal corporate app then quite possibly not in that case no db == not work.
Secondly you could look (hmm, rash... one assumes you could look, this could be a bad assumption) at database synchronisation between a local SQL database and the remote db and so on and so forth.
Taking a step back... yes - you're absolutely right, look at it as being the same as phone or silverlight (although I don't know if there is yet RIA support) - but the thing is at this point its very hard to be prescriptive because given a general purpose platform one can therefore write applications to suit all sorts of purposes.
Not a hugely helpful answer really - but a start.
Having read #Jim G's answer it seems that I should probably withdrawn mine?
I am considering building an app in C++ that will be parsing text from the web and create some statistical results. These results I want to be fed in an external app in real time. The external app (to whose code I have no access, but can ask for a - paid - custom made addition) will then need some code to read and use these results.
I am wondering what would be the best way to interconnect the two apps, in terms of speed and ease of implementation. I am considering :
disk I/O (slow)
a Windows service
a DLL
a web service
a web page
Perhaps I am missing a better solution ? Thank you.
Update : there is an additional need to know how long a data request may take at worst.
Sockets?
Shared Memory?
RAM Disk?
TCP/IP?
Windows Messages?
Command line arguments (of the other application)?
What methods does the other application have to support receiving data?
A windows service would be sensible but would still need to communicate with the other app, this is called IPC, approaches on windows are described here, Named Pipes are simple & flexible, File Mapping is powerfull.
An alternative would be to stick a database in the middle?
There are a number of IPC mechanisms to choose from from (sockets, shared memory, pipes, ...). I guess the "best choice" will depend to a large extend on how the other application is structured aka. how much your custom extension will cost you.
I don't know much of your environment but it might be worthwhile to have a look at boost.interprocess:
http://www.boost.org/doc/libs/1_43_0/doc/html/interprocess.html
I need to be able to communicate between two applications that reside on the same machine. One is using Flex and the other is in C++. I would like to be able to call functions and pass arguments to each other. What is the best way to communicate between them? I was thinking about using sockets.
As for now yes, you'll need to use sockets.
AIR 2.0 will provide access to native processes, but that will require a native (per OS) installer. More info: http://www.mikechambers.com/blog/2009/09/22/fotb-slides-advanced-desktop-development-with-adobe-air/
As for AIR 1.x, Mike Chambers posted a sample library called CommandProxy which does the trick. It provides code for AS3 and .NET which could easily be ported to C++ if you have a decent XML parser.
The basic idea is that each compnent can send each other XML "packets" across the wire where each one has an ID to ensure the request/response can be tied together. However, both the AS3 and .NET code don't account for slow or fast TCP/IP speeds where two XML chunks could be sent on one packet or one XML chunk split across two. Any ways, it does the trick.
Also, you could look for a C++ AMF (ActionScript Message Format) library so that you could serialize AS3 objects over the wire which would have a more "integrated" feel.