Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I got a desktop application and it's getting bigger and bigger. And i wonder if i can make something like microservices with desktop application? I want to application for now stays desktop. Application it's written in C++.
I can exclude some of the modules with some preparations.
But is it possible and if anybody have idea how to start with this?
A microservice-like architecture for the desktop is feasible. In fact, many OSes use services, which are often called daemons. For instance, the X Window system uses a client/server architecture. More recently, IDEs can now use the Language Server Protocol to communicate with one or more language servers that provide syntax highlighting, code completion, compilation feedback, etc.
There are a few things to consider:
What communication protocols are already available on the target system? On many systems, you can use a D-Bus (https://en.wikipedia.org/wiki/D-Bus)
What performance do you need? If performance is highly critical, you will need to use a highly optimized protocol for communicating between services, and startup times will need to be small. For good performance, something similar to the Language Server Protocol is probably good enough and will be easier to write, maintain and debug.
Can you handle the added complexity of splitting processes up? In a monolith, the whole thing is either up or down. With microservices, parts of the system that are running can attempt to call parts that are not. This situation must be handled.
What are the seams in your applications? Where can you split it up easily? Take a look at Domain Driven Design. Identify potential independent modules, and refactor to confirm. If the refactoring makes sense then split the module into its own process.
Desktop application and microservices are mutually exclusive because Desktop means one machine and microservices implies multiple machines (physical or virtual) that communicate through network using a technology agnostic protocol.
What you can do is to use modularization. This is an alternative to microservices that can work in some scenarios like yours.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We are implementing a Web Service using Apache Camel that has many (20-50) "direct:" routes calling Java methods. Every method basically has a route to it, whether it's for business rule processing, or DAO access methods. All the routes use from("direct:").to("direct"), but never to any other component.
While this may seem like it decouples the system from the standard Controller->bo->dao layers, it adds unnecessary book keeping of the Camel routes.
A better alternative would just simply be to define Java interfaces for the Business Objects and Dao layers, with an additional interface for any other service (external to the system, like file://, or http://) requests that would be a dependency inside the Business Objects or Controllers. The implementation to this additional interface would be using Apache Camel to talk to those external services.
As a side note, I'm thinking about how to convince my current colleagues to see my point.
Thoughts?
tldr;
Should Apache Camel be used where there is only 1 or 2 applications present?
I have used applications where there have been 20 systems involved in various complexity, protocols and patterns. I know other places where 50+ systems are involved. The only limit is on your design, performance etc.
Apache Camel is a middleware framework. Essentially your business logic should not know about how the data got to it or where it is to be delivered, only what it should deliver. Camel should take care of the rest.
By the way, does your middleware not talk to the external world? Why only use the direct and not other components?
You can also hide the middleware by using bean integration. That gives you an even more decoupling. See here: http://camel.apache.org/bean-integration.html
It really depends on what it is you want to accomplish and what your requirements are.
Well, for your specific use case I would say that you would probably have been better off with just a regular Java implementation with Camel being used as a glue between your system and the outside world. Like Souciance explains in his answer, Camel really shines when you have to integrate with multiple systems so you should at least keep it for communicating with the outside-world.
However, having already implemented the system's internals using Camel, I would have to say that it doesn't make much sense to put additional effort into replacing it with pure Java, especially since the current implementation gives you the ability to make the system more robust, for instance by using a high-performance MQ as a replacement for the direct routes, which would help your system become more resistant to failures and more easily decoupled later on, not to mention that having routes around your DAO objects makes it much easier to implement batching of DB updates when your system's load grows.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I just started a summer job at my university doing work in a lab, and I've been given a rather large, vague problem to tackle without much guidance so I was hoping someone could help point me in the right direction.
Essentially it's a 3-d world built in Qt using VTK (Visualization ToolKit) for use in therapy and rehab, and my task is to find a way to network two or more instances of the program so that users can share the same 3-d environment (essentially a networked video game).
The professor wants it to be secure, for latency to be as low as possible, and for the program to record data after a session is complete.
So far I was thinking (without much experience) of doing a client/server model built in Qt, but I'm not sure where to start.
Q1:
Should I use Boost.asio, or Qt library for networking?
Q2:
Are there any concepts I should be mindful of from the get-go for security, and network programming in general? (I've heard good things about Beej's Guide, and books by W. Richard Stevens)
Trying to answer your first question, it depends on which platforms are you targeting (Windows, Linux, OSX...). You could use native OS socket api (bsd sockets or winsock) but Qt provides very good abstractions for these so for the sake of simplicity I would stick with it. I'm unfamiliar with boost.asio but I'm pretty sure that Qt could provide you with all you need disregarding the platform you intent to target.
As for the second question, you have to carefully analyze what kind of information you want to transmit and what will characterize the exchange.
If you intend to make it like a video game where players interact in real time, you are bound to use UDP sockets (although some data can go missing, it allows for "real time" communication). Control messages can circulate through TCP as the impact of latency won't be so critical and you want them to be reliably sent, so consider having two sockets (TCP and UDP) if that's the case, and use them for their purposes.
Those resources that you link are quite informative but assuming you have knowledge of TCP and UDP and their features, I would suggest you to brush up your multithreading skills. Qt offers you good infrastructure for this, but topics like Asynchronous I/O (how to implement selectable sockets) may help you to create a better design that will remove a lot of overhead from additional threads (specially for reading).
These are my 2 cents.
Good luck for your project, I'm sure it will be a good chance for you to learn and put some theory into practice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are aiming to leverage software reuse in embedded ARM/Linux platforms. Some of our hardware platforms are designed for customers' specific needs. Of course the application would be customized in various ways too.
While it is not an Android product, for one it is way too big compared to ours, it does make a good analogy in that other than the constant of being Linux based, there are different look and feel to the UI, there are different phones, there are different CPUs, there are different firmwares for different radios, etc. So there are many configurations to manage. And the configurations are a sparse matrix, in that not all combinations exist.
Continuous Integration is also not completely out of the picture in the future.
So for the near future the end point seems to be:
A core set of libraries that we want to keep developing and apply everywhere. Class inheritance supplies the customizations. So there is a build configuration for the application types.
A handful of customized ARM/Linux hardware platforms. Seems a BSP/board class HAL for our libraries is the way to go. That means a build configuration to pick the right hardware/board.
A handful of co-processor firmwares matching to the hardware/board, but the API to our libraries is the same. So there is a build configuration depending on the firmwares.
A handful of implementation for different look and feel/applications. That's another build configuration.
Needless to say there are many include paths, #define's, and file exclusions to make all these work.
So as you can see, if we wanted a collection of Eclipse/CDT projects in a workspace that allows us to build all these variants in the same environment all at once, there are a lot of configurations to create and manage in Eclipse/CDT. If the GUI is the only way to manage, there is a whole deal of mouse clicking to do. And after that there is no simple way to verify that all configurations are setup correctly without a whole lot more mouse clicking. There isn't a dashboard view. Is there a text editor based approach to manage all these?
I did try to do my homework. I understand that there is the 'Import Settings...' and 'Export Settings...' buttons in the 'Paths and Symbols' tab. But it does one configuration at a time, for one project at a time. It doesn't seem very systematic and is easy to miss something.
I have also look directly at .cprojects but I worry that if I made a mistake Eclipse will just silently do the unexpected things and will take big effort to fix.
Do fellow experts have a better suggestion?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So my question is, would it be possible to write a protocol which does the same as the Internet Protocol, and if so, how do I get started? And don't say, "isn't the Internet Protocol good enough?", yes it is, it is just to see if it is possible:P
I would like to know a bit more about how,
just for learning how protocols are done. I have some experience in programming, but not anything like networking protocols.
The short answer is yes -- it has been done, and could be done again.
Examples of what have been done include DECnet, NetBIOS, Appletalk, and ATM. Although I'm not sure it was ever fully implemented as intended (though DECNet came pretty close), the standard OSI 7-layer model for networking was originally intended as a model of actual implementation (i.e., the intent was that people would implement those layers, and you'd be able to build a fully network stack by plugging together the implementation of your choice of each layer).
Of course, what most of us think of as IP today is really IPv4 -- as you can probably guess from the version number, it had predecessors (and a successor, IPv6).
Edit: as to how you do it: pretty much like anything else. I'd start by writing up something about your motivation -- what you want to accomplish, what sorts of operations it should support, etc. Then start working on the simplest design you can figure out that can possibly do what you want. Then, as you use it and encounter problems, figure out whether they stem from poor implementation, or shortcomings in the design itself. Modify one or both as needed, trying to keep its evolution as coherent and understandable as possible.
In short: Yes, it would be possible. On a higher level (i.e. OSI layer 7) it is done daily. If you want to implement the next IP, all you need are:
Special hardware (for the actual physical implementation, assuming that your protocol greatly differs from IP)
Device drivers for your favourite operating system that support your protocol
Maybe a high-level API to facilitate implementation
Edit: Saw that two others beat me to it ;)
would it be possible to write a protocol which does the same as the
Internet Protocol?
Yes it is possible to write your own IP stack, but it is extremely difficult to actually go ahead and do it (and actually do it right) unless you are an expert level both in programming and in networking
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I need to create an application which will be reading and writing to files(C++/MFC). but I need the process not to appear in process monitor (which comes with SysInternals).
From the reactions of others, I now confirm that this seems "illegal". but that is the request of the client I'm dealing with. so, I guess I just have to satisfy the client's request.
One of the uses of Process Monitor is to find and remove malicious software that tries to hide from the user:
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines
the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements including rich and
non-destructive filtering,
comprehensive event properties such
session IDs and user names, reliable
process information, full thread
stacks with integrated symbol support
for each operation, simultaneous
logging to a file, and much more. Its
uniquely powerful features will make
Process Monitor a core utility in your
system troubleshooting and malware
hunting toolkit.
I am not saying that what you want to do is impossible, rather that you are trying to do something that feels a bit dishonest.
That being said I would like you to consider the fact that you are trying to hide a process from a utility that was written to find anything and everything by folks that are a lot smarter than you and me.
I'll assume you're not planning to do anything malicious. If that's the case, it's important you don't hide your application from diagnostic tools. You can't guarantee your application is bug free. Even if it is, you can't predict its interaction with other applications. Because of that, you should leave it visible so other technical people can troubleshoot if something goes wrong.
Regarding your comment, "so, I guess I just have to satisfy the client's request" - not if it's illegal or technically dangerous for them. You need to protect yourself and them from bad judgment.
PM reads data at a very low level so to hide from it you have to actually take over certain NT kernel structures and methods to report different information to PM than what Windows itself sees. Doing this is platform and version dependent ( ie. Windows XP SP1 is different than Windows XP SP2 is different than Vista x64, etc.). It's nearly impossible to do correctly without creating an incredible number of system instability issues.
While it's not strictly illegal, every company that has done it and been discovered (which you will) has enjoyed lots of backlash and criticism from users and security professionals. Again while not explicitly illegal, the kinds of changes required can open severe security holes on the end users' machines. Should they have major system crashes or be exposed to hackers/viruses you may be legally liable for the damage.
Possible semi-legitimate (though I wouldn't want my name associated with them) applications you would want to keep people from seeing are DRM enforcers and nanny-cam style monitors for kids and errant spouses.
That said, I don't think your client really wants you to subvert such an important system. They likely want something less rootkit-like but they picked up the vocabulary watching "24" and have failed to adequately express what it is they want done.
My advice would be to go back to them for clarification. If they do indeed want something to be completely undetectable then you need to decide based on your own conscience whether to proceed or leave the client.