How can I share data between bundles in Karaf? I am loading two bundles in different features. I want to write into something like a shared memory segment from one of the bundles and read it from another bundle. Thanks
Basically you can use all ways to communicate as in any other java application. Not all libraries are nicely compatible to OSGi though.
One built in way to communicate in a loosely coupled way is the eventadmin service. See this tutorial from vogella for example.
The most typical case in OSGi is to let one bundle offer an OSGi service and the other one call it.
There are also libs like hazelcast which use kind of a shared memory even between nodes of a cluster. It is difficult to recommend one way without knowing more about your requirements and what you are trying to do.
Related
I understand the need for abstraction and separating concerns and unit tests, however, it seems to me that separating entities and context into 2 projects is slight overengineering?
I could be missing something really, but is this because you want to be open for different ORM-s?
Much thanks for the clarification.
The main reason I prefer to have Infrastructure in a separate project, rather than just a separate folder, from the domain model (Core project) is simple: enforcing my design via the compiler.
I have a design rule, which is basically the Dependency Inversion Principle. Don't depend on low level implementations (such as those found in Infrastructure), instead depend on abstractions (interfaces). Also, don't have your abstractions depend on details; have details depend on abstractions. The details of how and which infrastructure is being used for a given abstraction are in the Infrastructure service implementations.
Abstractions say what; implementations say how.
What: I need to send an email.
ISendEmail interface
How: I want to do it using the SMTP protcol
SmtpEmailSender class (implements ISendEmail)
How: I want to do it using a SendGrid API
SendGridEmailSender class (implements ISendEmail)
So, in a single project, how would you ensure that the implementations depend on the interfaces, and not vice versa?
How would you ensure your domain classes didn't directly reference or use Infrastructure types?
I'm not aware of a way to do this.
But if you put them in separate projects, and you have the implementation details project depend on the abstractions-and-models project, you now have solved the problem. The compiler WILL NOT ALLOW the Core project to reference anything in the Infrastructure project, because it would create a circular dependency.
This constraint helps developers do the right thing and keeps them falling into the pit of success even if they don't completely grok how the dependency inversion principle works or why it's important.
And I've never found 3 projects (Core/Infra/UI) to be overengineering for any non-demo app I've built for real work. It's only 3 projects.
I've been looking into scaling Meteor, and had an idea by using the Meteor Cluster package;
Create a super-service*, which the user connects to, containing general core packages to be used by every micro-service (api, app, salesSite, etc. would make use of its package),
The super-service then routes to the appropriate micro-service (e.g., the app), providing it with the functionality of its own packages.
(* - as in super- and sub-, not that it's awesome... I mean it is but...)
The idea being that I can cascade each service as a superset of the super-service. This would also allow me to cleverly inherit functionality for other services in a cascading service style. E.g.,
unauthedApp > guestApp > userApp > modApp > adminApp,
for the application, where the functionality of the previous service are inherited to the preceding service (e.g., the further right along that chain, the more extra functionality is added and inherited).
Is this possible?
EDIT: If possible, is there a provided example of how to implement such a pattern using micro-services?
[[[[[ BIG EDIT #2: ]]]]]
Think I'm trying to make a solution fit the problem, so let me re-explain so this question can be answered based on the issue rather than the solution I'm trying to implement.
Basically, I want to "inherit" (for lack of a better word) the packages depended on needed functionality, so that no code is unnecessarily sent through the wire.
So starting with the core packages, which has libraries I want all of my services to have, I then want to further "add" the functionality as needed. Then I want to add page packages if serving a page-based service (instead of, say, the API service, which doesn't render pages), then the appropriate role-based page packages, etc., until the most specific packages are added.
My thought was that I could make the services chain in such a way that I could traverse through from the most generic to most specific service, and that would finally end with a composition of packages from multiple services. So, for e.g., the guestApp, that might be the core packages + generic page packages + generic app packages + unauthApp packages + guestApp packages, so no unneccessary packages are added.
Also with this imaginary pattern I'm describing, I don't need to add all my core packages to each microservice - I can deal with them all within the core package right at the top of the package traversal I've discussed above and not have to worry about forgetting to add the packages to the "inherited" packages.
Hope my reasoning here makes sense, and I hope you guys know of a best practice for doing this. Thank you!
Short answer:
Yes! That's a good use to a microservice architecture.
Long answer:
Microservices don't necessarily provide you an inheritence mechanism as in OOP. You should consider microservices as independent "functions" which take in an input and respond with an output/action. Any microservice can depend on another to complete its own task.
And then, you "compose" necessary microservices in order to achieve the final output/action.
You can have one or few web facing "frontend" services that use a mix of few other backend microservices whose ports are not open to the public network.
The drawback with a microservice would be its "minimum footprint". The idea with microservices is around some main benefits:
Separate core services so that they can be "maintained" independently
Separate core services so that they can be "replaced" independently
Separate core services so that they can be "scaled" independently
But then, each microservice, being a node/meteor app, will have its minimum cpu/ram footprint even when they are just idle and waiting for a connection.
Furthermore, managing a single monolithic app, or just a few "largish" services is much easier, from a devops standpoint, than managing tens of individual deployments.
So with all engineering decisions, the right answer would imply some kind of "balance".
Edit: reference to inheritence
As per the OP's comment, the microservices can indeed be referenced from a parent code as either functions or classes and be composed (functions) or inherited from (classes) because after all the underlying functionality are DDP endpoints.
If you are using the cluster package from meteorhacks
// create a connection to your microservice
var someService = Cluster.discoverConnection("someService");
// call a normal meteor method from that service
var resultFromSomeService = someService.call("someMethodFromSomeService");
So as with any piece of javascript code, you can wrap the above piece of code in a function or a class with its constructor and all and inherit from it, exposing its interfaces as you desire.
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.
I know this is somewhat subjective, but Symfony being as it is there must be a feature specifically designed for this purpose.
Here are the main factors of what I need to do:
The system will be deployed separately for multiple customers (probably just a handful. scale isn't a big concern).
Each deployment has a small amount of highly bespoke functionality specific to the customer. This could be anything.
I want to maintain a single, common codebase (including composer.json). The only file I really want outside of our repo is parameters.yml.
My current thinking involves a custom bundle for every customer - hooking into them using custom Symfony events, fired from the common parts of the system. But ...
Symfony bundles aren't designed to be dynamically registered. They're baked into our core system so I can't switch them on and off for individual customers without forking/splitting the codebase. This means not only a bloated Kernel, but also events would be received by all bundles in all deployments.
I can get around that last point by namespacing the events with a configuration parameter. Even if I can live with redundant bundles in the Kernel, this whole approach seems too hard to be correct.
What is the proper way to support a "pluggable" architecture than I can hook into from the core system without splitting my codebase?
I use multiple app-directories. Then you can turn on/off bundles for each client since each client has it's own AppKernel.php and then you can create a separate /web/app.php for each client and point it to the currect app-directory.
You can then use mod-rewrite in Apache to point each client's subdomain or something to the right app.php file
I'd like to know what are the best practices when creanting a complex and big flex modular application? particularly concercing internationalization, performance, remoting(service), skinning, caching, logging.
How to use theses common resources?
Imagine that many developers will work on the same project, but on different 'small' modules each, and they don't have to know how the entire application works. So every developer will create and compile his/her module (swf), and I'll just have to put these swf in their appropriate folders.
What do you think about this approach:
create a common library : myAppLibrary, which manage languages, services, caching, logging, debuging.. For example this library can have these functions : translate(str:String):String, callAmfService(class:String,methode:string,...params), loadCache(cacheKey:String):Object, etc
require that every module(developer) should use this library when handling languages, services etc. Eg within a module, a developper can do : langSingleton::getInstance()->translate('somestring') for example
make modules communicate by events
(sorry if my english's not clear)
Thanks