Is there any large scale commercial software developed base on OSGi specification? I would like to see some examples and what the architecture look like.
What is large scale? Our enterprise runs on eclipse equinox with 2.000.000+ lines of code, what is nothing uncommon. (Of course the architecture is not available to non company members)
Perhaps the glassfish j2ee app server can give you a good example. See this slides...
Eclipse is based on OSGi, I do not think there are that many larger code bases in a more variable environment. On top of this you find most Java EE Application Servers to be based on OSGi or heavily support it.
IT is a long time ago I had to answer this question ...
Related
While developing Java EE applications, the NetBeans IDE (currently using 8.0.2 but the issue is not restricted/limited to this version only) issues a low memory message quite frequently.
For example, while modifying and saving some Java classes (especially, JPA entity classes), the memory soon gets over-flooded after repeating this modifying and saving process for merely 10 to 15 entity classes. The IDE issues a low memory message disturbing the whole system severely.
It leaves only one alternative which is to restart the system and I indeed have been wasting more time in restarting the system than actually developing Java EE applications for couple of years :). I have not yet seen anything about this issue over the internet.
The auto-deploy (Deploy on save) option on the IDE is turned off forever. I never use this facility as it causes the heap/PermGen space to get over-flooded quite soon.
This may or may not happen in small toy applications. I am only talking about Java EE applications using a Java EE compliant application server.
I see if there is no way to get around this problem, then this IDE cannot be used in developing real Java EE applications because dealing with this problem basically takes more time than the actual development time and otherwise, the solution may be to lean towards other IDEs like Eclipse, IntelliJ Idea, JDeveloper etc, if they go better.
I am currently using,
GlassFish Server 4.1/Java EE 7
JDK 8u45
NetBeans 8.0.2
Is there a solution somewhere in the world?
NetBeans tends to be slower than other IDEs on Windows but this is far beyond the single term slow.
The picture is taken from a simple test web application (thus not an enterprise application). In enterprise applications, changing a single character in a single entity class is not affordable. One is likely to run into a big problem, if attempted. Fixing those errors shown in the link may take hours or probably the whole day or so.
Not to mention again that I am not talking anything other than large scale applications involving Java EE or other platforms like Spring.
Long story short : Nothing can prevent me from wondering as to how it is affordable to use this IDE in software industries. It is no longer usable in this way (Nothing to abuse. Honestly, I kept patience for almost three years. I am merely wasting time using this IDE).
The question is quite simple:
Can we use JavaFX as a thin client running on a browser while a java server does most of the work?
IE: cretate the UI and it's controllers with JavaFX and have the bussiness/database connection/etc part run on a server?
Even if possible, would it be a complicated turnaround?
Based on the information you've provided, I wouldn't necessarily say that JavaFX is a good fit, but on the other hand I would not worry about the load times. My rationale is: The bad thing about JavaFX is that you have an additional tech requirement for your clients (JVM) and require some form of installation (even if it is just an applet). Those won't be a factor for HTML5. JavaFX has benefits over HTML5 if one of these cases is true:
1) You have complex controls and/or a lot of user interaction with the UI
2) You need your application to be really flashy, e.g. by incorporating animations
3) You have a complex business logic that you would like to execute on the client (e.g. because you had a previous implementation as a rich client)
'Some tables and simple controls' don't really fit here.
The reason why I wouldn't worry too much about the download time is that most users of an enterprise application will be using your app a lot from few different machines, thus caching should deal with that problem (plus an FX app is not going to be that large).
There is an interesting article on the topic to be found here: http://www.oracle.com/technetwork/articles/java/casa-1919152.html . Since it is coming directly from Oracle, you should of course take it with a pinch of salt, but I for one do agree with the general notion. The article also outlines some (subjective) experiences when switching to JavaFX.
If it's an enterprise app, and you already know that your users will have java installed on their clients, javafx is a good solution. If not, the downloading of the javafx jar can be quite a buzz kill the first time an app is run, as it's quite (understandably) large. I'm using it for enterprise apps, and the web start functionality works well.
And don't forget, if you're using jdk 7, there is a javafx packager which will create a single file installer/run-time for your app. I can't provide a lot of detail for that as I haven't bothered with it yet.
I've heard the Google Web Toolkit isn't that good for web sites with more than 5 pages and a common layout. Is that true? We have at least a 100 subpages and a common layout defined in CSSes. Today were using PHP but we will move to a Java front either Spring MVC or GWT. We're using som jQuery AJAX and other jQuery components like a jqGrid. We also have some .swf-films and fusion charts. Will opting for Spring combined with GWT be a good choice or is Spring MVC with a jQuery library a better choice for us?
It's not true now. Earlier GWT versions really had some issues with scalability (e.g. problems with JS code size in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440), but since GWT 2.0 you have no limitations here.
Moreover, latest GWT versions support functionality for splitting projects to the parts that may be loaded dynamically when they're needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to learn how it works.
Take into account also that since Spring is Java, you have possibility to share classes between server- and client-side. Plus Java has very good support in IDE - all kind of refactoring will be available for you (it is not so convenient in case you use jQuery).
So Spring+GWT looks more preferable choice.
GWT is not a universal framework for building just a any webapp from scratch. It is very useful when you have a lot of complicated logic on client side, (image editing, real time collaboration, diagram drawing, games , complex reports building and etc etc). But all of this can be done without GWT.
GWT can be used when:
your team hates/dislikes JS (and is unable to build nothing complex with JS, just because they hate JS)
your team is quite experienced with Java
your team understand how all this browser related stuff works (HTTP, JS, DOM , CSS and etc)
in this project there are will be a lot of logic running on client side
I've seen quite a few big projects built completely with GWT. Some of them should never used GWT, because the were no reason for them to use it in such way. For most projects it is enough to use GWT only for some part of application.
The choice depends on your team and the project you are doing. If your team can't really see what benefits GWT will bring to the project, then you shouldn't use GWT.
Our enterprise-level application utilizes both and we're quite happy with the results. GWT is a powerful toolkit which lowers development time by orders of magnitude. That said, there are still things that GWT either doesn't handle all too well or just plain isn't suited for (and that's ok... that's why Spring MVC lives nearby). We have GWT-RPC hitting Spring services directly and it works incredibly well.
Our project though is a true webapp, not a website. We use a unified design which spans all "pages" (using a DockLayoutPanel and swapping out just the center makes this super easy).
IMO, whoever told you that GWT isn't good for consistent design across numerous "pages" is nuts...
I think any assertion that GWT (or any other method) lowers development time by an order of magnitude has already been debunked by Frederic Brooks in a time when shoulder pads and Jan Hammer's synthesizer were fashionable: http://en.wikipedia.org/wiki/No_Silver_Bullet.
But seriously, if you're a PHP shop, moving to 100% Java would be a huge investment, and not to be taken lightly.
On my experience of GWT, my only bad experience was with GWT compilation slowness due to lot's of permutations. Our application had more than 20 languages to support, which multiplied by 6 for browsers specific result in 120 permutations, which proved to get horrible performance.
But this is not a real bug issue, because you'll mainly use the dev mode, with instant code update, and you can have special compilation unit with reduced set of browser and language (even one language and one browser => one permutation if you wish).
So in my case, using Jenkins we made the big prod target full build nightly, deploying on a QA platform so that the QA team test every browser language combination. And on every commit a reduced build (1 browser and 2 languages in our case) was deployed on a dev validation platform.
GWT is definitively a great tool for large app. ;)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What tutorials would you recommend for learning about modular Java with OSGi, and advice on how to write decoupled systems by decomposing them into modules? What level of granularity is right; a big bundle with everything, lots of very little bundles with one specific task, or somewhere in between?
What level of granularity is right
I hope this doesn't come off as sounding too trite, but I can't think of any way to answer other than - it depends. Off the top of my head, here are some factors that would influence the answer: How big is the project? How many developers? How long will it be in use? Is it a single-shot throwaway app (say, for a demonstration), or something you need to continue to develop over a number of years? Do you want to support multiple configurations of the same base application? After releasing, do you have the opportunity to do major refactorings, or would this be impossible? Is it open source or closed source? Does the budget allow additional up-front costs (to design and develop in an appropriate modular way) for projected future benefits (not having to modularise a monolithic initial implementation)?
If you develop lots of little bundles you increase your flexibility, but at the cost of an increase in complexity. You will probably have to abstract out common interfaces into their own modules that other modules use to interact with each other. If you look at something like the Eclipse IDE, which has a lot of bundles (100+?), some of which are quite large in themselves, trying to decipher how it all fits together without some really good documentation or roadmap is like pulling teeth.
Can you provide a few more concrete details of a specific application? It might help narrow down the advice.
As Ash say: "It depends". I would take the following points into regard before deciding on the structure of the modularity.
Embedded or enterprise application? The first realm is a environment with very scarce resources. Here it make sense to have many bundles, that can loaded and unloaded if needed (but not to many bundles since the management etc eats up resources as well). In the enterprise world you need fast start-up time and reactions for an application.
Can you easily separate your application in model, view, and controller? This is a good starting point for the modularization.
Do you expect that some parts of the application need to be updated often, some won't? This might be good cutting line as well.
Finally, can you foresee that some parts of the application can be reused in other applications? Put them into a separate bundle.
One more advice: have a look at the versioning capabilities of OSGi. You can specify what is the minimum (and maximum) version that is needed by another bundle.
It probably doesn't suit you, but I've liked this book (in German, i don't think there are translations available): http://www.dpunkt.de/buecher/2635.html
I think there is no straight-forward answer to your question. Its a Software Engineering problem and if there is a phrase that applies its "It depends....".
The general idea of decomposition is to tackle complexity by composing a solution to a large problem from simpler solutions to smaller problems (i.e. divide and conquer). There should not be an increase in complexity, rather it should be easier to build your system this way. From practice, this usually works fine, as long as the "modules" are loosely coupled i.e. without introducing too many inter-dependencies.
The trade off may sometimes be investing a little bit more of work into each module, depending on how independent a module should be (example: Felix embeds an XML parser in some modules to avoid the dependency; or it provides various mechanisms for configuration, so that bundles don't depend on other services; there will always be some kind of tradeoff...)
Also there are mechanisms to get a visual overview of a composition even if you have a complex composition see "Visualizing OSGi Systems" (I also remember having seen some BEA presentation with graph plots....).
I have been working on the Coalevo Project for some time now (sorry, the link is currently down, because I am in a transition phase) and I think it has worked to a large degree and maybe the future shows how much so).
From my point of view, I think that the decision should be rather strategic and go beyond a single project view.
Also consider, that in todays landscape, with most commercial J2EE containers on top of OSGi (BEA is, Websphere is, JBoss to some degree, Glassfish in the works), maybe the upfront cost is reduced drastically by the fact that you can obtain off-the-shelf ready-to use bundles from various different providers (which was always a basic element of the OSGi vision).
Expect to see more patterns emerging over time, that will help to design OSGi software "properly" for modularity; OSGi by itself, does provide the fundamental definitions for dynamic modular systems, but I think that software build on top of it isn't just modular by itself.
I have been trying to work in this area a little bit myself; check out "OSGi Mediator".
For me, OSGi may be at the node scale, what SOA can be at a large distributed scale, if done right.
I have been deep-divining in osgi from past few months and must say impressed by it. In recent days I saw one blog saying that impala is better than osgi. I heard about impala but never got a chance to deep-dive into it.
I just want to know that which one better Impala or OSGi? Is anyone is working on impala?
For developing large enterprise application one should go with osgi or impala and why?
Impala is an implementation of a framework from one person (company?). OSGi is a specification that is supported by all major IT vendors. It has been around for 10 years. There are 4 very popular open source implementations of OSGi available: Concierge, Knopflerfish, Felix and Equinox.
OSGi is used in thousands of embedded applications, it is the core of Eclipse, IBM and Oracle use it in strategic applications.
Though this of course does not say anything about technical superiority, you could imagine that the OSGi specifications have had a bit more real life weathering ...
You might find the following article useful for understanding when one might be more beneficial than the other:
http://osgi.dzone.com/articles/impala-alternative-module
Of note is the observation that
with Impala you don't get versioning and reloading of third party
libraries within the application
which is an important difference with OSGi
i think this is more of a debate... people who use Impala will say Impala, and those who use Spring OSGi will say OSGi; it's like Java vs C# or ASP.NET vs. PHP.
If you want to decide what is best for you, then just jump right into both of them, and see with which you are more confortable.
Before that read blogs about both maybe that will make you skip the whole diving into both step.
http://impalablog.blogspot.com/2007/11/impala-and-osgi.html