For my master thesis I'm developing an application framework for selling tickets for large events. My main requirements are modifiability, scalability and performance. My clients (event organisers) should be able to easily replace a component at runtime and add functionality. An example of such a component could be the seat assignment component.
My mentors said to look at OSGi. The idea of loosely coupled bundles is certainly appealing. When looking for alternatives I discovered Akka. This framework promises a lot of things, like scalability and high performance. I wondered if Akka's concept of actors suits my modifiability requirements. Akka seems more productive than OSGi, so development would be faster. Akka also seems more fit for scalability. With OSGi I would have a harder time.
If you have experience in both OSGi and Akka, which would you recommend for me? What are the pro and cons of both technologies when comparing them? And finally, are there are any good alternatives to OSGi or Akka that cover my requirements?
EDIT
First, thank you for the replies so far, you're a great help.
As mentioned below, I'm trying to compare apples and pears. A more logical question would be: How can OSGi and Akka be used together and benefit from each other? How is this structured? Do all your actors reside in one OSGi bundle, do they each get a separate bundle, is there a hybrid solution or isn't there really a 'right' way to do it?
EDIT bis
I posted a follow up question here, asking how to combine OSGi and Akka.
As Peter says they are not directly comparable. In fact you can use them together and they should be quite complementary.
Akka provides an asynchronous communications API. OSGi provides a modular, service-oriented framework. There is nothing in Akka, for example, that would solve the problem of isolating modules so that they cannot have visibility of each others' internals. Likewise there is nothing in OSGi quite like the async communications provided by Akka. So use them together and you get the best of both worlds...
OSGi does have synchronous Services, which are the principal method of communication between modules in a single JVM. OSGi also has a Remote Services layer that can be used for communication between remote machines. This is probably the area where OSGi and Akka most directly overlap, I suppose. But even here I think there is potential for cooperation. For example, OSGi Remote Services has a really powerful discovery mechanism that allows us to advertise capabilities on the network. You could possibly use this discovery to find Akka actors that are available for you to communicate with.
I'm not aware of anybody actually working on this as present, so I think that exploring and expanding on this idea would be an excellent topic for a master's thesis!
Which university do you attend? The OSGi Alliance is very interested in fostering links with the academic community, perhaps we could set up an online meeting with you and your professor?
I think you compare apple and pears. You can run Scala code on OSGi (though their binary compatibility is horrible).
Scala is a programming language, and Akka a messaging library. OSGi is a dynamic component system. So not sure how you can compare them
I agree with both Neil and Peter, you're asking us to make a comparison between apples and oranges. You can use both frameworks together. I'm currently working on a project with the same main requirements you specified. I'm creating a prototype that demonstrates using both technologies together, OSGi to provide modularity and updatability, and Akka to provide scalability and performance.
If you would like to see both frameworks working together you can play with the sample application I posted on github.
They aren't an apples to apples comparison. They are Orthogonal to each other and, if anything, complement each other. Use both.
Related
With multiple ways to configure using either XML, Annotations or Java Config and the need to remember 100's of annotations and super-lengthy class-names, the Spring framework appears an extremely complex demon that cannot be understood. Moving from a structured programming paradigm where you are completely in control of the program flow and the code you write, framework driven programming is posing a serious challenge. Can anyone suggest an easy way to transition from structured programming to framework driven approach and also suggest the best way to understand and learn spring.
All resources available on the net have learning methods that keep hopping from one topic to another and seldom able to link different topics and explain subtle differences between scored of annotations that spring framework offers.
I have put out this note after investing two full weeks to just get the basics of "Why Spring" and "How to" using spring scouring hundreds of scattered articles on the net. So, I request all the experts out there not to cancel this question since it sounds very subjective with no straight answers.
Are you telling me there are frameworks that do not require remembering their classes or solutions that they provide?
The best way to learn Spring is to simply get into one by one module and see what it brings to the table. Their official examples are great and you can go through each of them in about 20-30 minutes.
Spring is big, but that is the reason why is it good because it provides many solutions to web issues.
Regarding annotations, why will simply remember which one is for what after enough repetition, the same as you remembered for loop.
As for "Why Spring" official spring site answers that question https://spring.io/why-spring
As for "How to" you can scroll through the following page https://spring.io/
I'm trying to find out whether we should use Akka or Reactor for our next project. One of the most important questions is if the future framework of choice will provide remoting. As i saw, Akka offers this just in the way we'd like to have it.
In the GitHub wiki, unfortunately the TCP-server/client sections are blank and i couldn't find other informations about that yet.
Will reactor provide remoting?
I don't think Akka and Reactor are Apples to Apples. Reactor is purposely minimal, with only a couple external dependencies. It gives you a basic set of tools in which to write event-driven applications but it by design does not enforce a particular model. It would actually not take that long to implement a Dynamo system using Reactor components. Everything that would be needed is there and it would likely only take writing a tutorial on it to show how to wire things together.
The Dynamo model that Akka uses is a proven system. Basho has done a fantastic implementation of it in Riak. It's great to see Akka following their lead in that respect. If we were to implement a Reactor clustering system, it would likely be the Dynamo model. But since a Reactor is basically just event handlers and topic pub/sub, your Consumers can do any remote communication you want. They can integrate with HTTP, AMQP, Redis, whatever. There's no need to have special APIs for doing this sort of thing because they're just events. You can code up an AMQP client application in about 10 minutes and be publishing data from RabbitMQ into a Reactor application.
We might very well at some point have different implementations of clustering for different purposes. The Dynamo model might work well for some while others would want a simple Redis-based system. Or maybe one could leverage the components already in Reactor to work with the Java Chronicle to do disk-based clustering--something you can do right now just by wiring up the right Consumers. But those will be in external modules that could be added to Reactor. reactor-core itself will likely never have an opinionated clustering solution simply because it doesn't fit the purpose of those core components: a foundational framework for event-driven applications on the JVM.
(I'm working on the TcpClient/TcpServer wiki docs right now, so hopefully those will be filled in for the M2 of Reactor which will be happening very soon.)
Is it possible to integrate play framework with OSGI to create plugable components? Did someone try it?
If you mean "create Play modules with OSGi", then no, it's not supported
If you mean "deploy Play as an OSGi module" then no, it's not supported
And to be fair, there's no reason to push its support. You can read these thoughts from Spring founder on OSGi, as an example. OSGi would add extra complexity to Play, while the main aim of Play is to be a rapid development platform, simple to use, removing some Java conventions (like Sessions). It would kind of defeat the purpose.
If we're discussing Play 2 then it's definitely worth acknowledging that an important and integral part of Play now is Akka, which could be seen as an alternative to OSGi. Philosophically I think Akka has a lot in common with the core principles of Play and Scala (a functional, stateless, NIO approach), while OSGi is more aligned with the Java EE/Spring camp.
That's not to say that Akka and OSGi are wholly mutually-exclusive: Akka's documentation suggests you can deploy Akka as an OSGi bundle and create some mutant app which has Akka actors firing up via an OSGi bundle.
But to answer the question, no, Play doesn't do OSGi, but it very much does do Akka.
I'm looking to make a website that will probably get some heavy, repetitive traffic. Is grails up to the task?
I agree with lael, also because it's built on java technologies there are a lot of proven clustering and 'enterprisey' tools available which allow you to easily scale across multiple application services.
The cloud tools around Grails are also becoming very good and make deploying to a cloud like EC2 very easy. I've recently been using Cloud Foundry and found it very good.
As the first poster points out however, you can write a badly performing application in any framework/language. One thing I'd recommend is getting a good understanding of Hibernate which is the underlying persistence library. If you understand how that works, it should help you avoid making any silly mistakes at the DB level. On this side of things, a tool like p6spy is great for checking what the database is up to during normal use. It should help you spot any repetitive queries.
The scalability of your web application won't really depend on what language/framework you choose to use, but rather how your application is built. You can build a scalable web application in Grails, just as you can build an incredibly slow application in C++. If Grails is the framework you would like to use, then use it; you can always rewrite the slow parts in Java or another fast language, if need be. (After all, that's what Twitter did with Scala.)
Disclaimer: I've never actually used Grails.
Grails is essentially a thin layer on top of the Spring Framework, which many consider to be a very scalable framework in the enterprise world. Spring + Hibernate has become a standard in many Java shops around the globe.
If you run into performance bottlenecks in Groovy, you can always rewrite those parts in Java.
Take a look at the Success Stories for examples of sites that were written in Grails. The Testamonials are also a good place to look for examples. You will use a little more memory(heap and permgen) than a vanilla Java app, but you can tune it just like you would any other Java application.
On the low end you aren't going to find $3/month Hosting options that you could with PHP stack (for example). That said, there are some good caching solutions for Grails apps EhCache, MemCache, etc. Beyond that you can also setup an Apache layer to caches static resources or whatever you need.
Don't mean to pile on here. You've already got some great answers but I just want to add on thing that I was reminded of recently. Scalability depends not only on the software you write (regardless of language/framework) but also on the deployment environment. A very well written application deployed on an undersized or poorly configured server will not scale at all. If you do use Grails or any other Java based framework, the default settings on your container (Tomcat, JBoss, etc.) will probably not be what you need.
Just something to keep in mind,
Dave
Grails run on the JVM. Simply put, you will not find a more scalable, solid and robust runtime platform than the JVM, anywhere. That's Grails's big advantage over, say, PHP or RoR.
I have been trying to understand a bit more about the wider picture of OSGi without reading thru the entire specification. As with so many things, the introduction to what OSGi actually is was probably written by someone who had been working on it for a decade and perhaps wasn't best placed to put themselves in the mindset of someone who knows nothing about it :-)
Looking at Felix's example DictionaryService, I don't really understand what is going on. Is OSGi a distinct instance of a JVM into which you load bundles which can then find each other?
Obviously it is not just this because other answers on StackOverflow are explicit that OSGi can solve the dependency problem of a distributed system containing modules deployed within distinct JVMs (plus the FAQ keeps talking about networks).
In this latter case, how does a component running in one JVM interact with another component in a separate JVM? Can the two components "use" each other as if they were running within the same JVM (i.e. via local method calls), and how does OSGi manage the marshalling of data across a network (do you have to use Serializable for example)?
Or does the component author have to use some other distinct mechanism (either provided by OSGi or written themselves) for communication between remote components?
Any help much appreciated!
Yes, OSGi only deals with bundles and services running on the same VM. However, one should note that it is a distinct feature of OSGi that it facilitates running multiple applications (in a controlled way and sharing common modules) on the same JVM at all.
When it comes to accessing services outside the clients JVM, there is currently no standardized solution. Paremus Infiniflow and the derived open-source project Newton use an SCA approach. The upcoming 4.2 release of the OSGi specs will address one side of the problem, namely how to use generic distribution software in such a way that it can bring remote services into the client's JVM.
As somebody mentioned R-OSGi, this approach also deals with the other side of the problem, being how to manage dependencies between distributed OSGi frameworks. Since R-OSGi is not generic distribution software but explicitly deals with the lifecycle issues and dependency management of OSGi bundles.
As far as I know, OSGi does not solve this problem out of the box. There are OSGi-bundles, for example Remote OSGi, which allow the programmer to distribute services across a network.
Not yet, i think it's being worked on for the next release.
But some companies have already implemented distributed osgi. One i'm aware of is Paremus' Infiniflow (http://www.paremus.com/products/products.html). At linkedin they are also working on this. More info here: Building Linkedin next gen architecture with osgi and here: Matt raible: building linkedin next gen architecture
Here's a summary of the changes for OSGI 4.2: Some thoughts on the OSGi R4.2 draft, There's a section on RFC-119 dealing with distributed OSGi.
AFAIK, bundles are running in the same JVM, but are not loaded using the same class loader (that why you can use two different versions of the same bundle at the same time).
To interact with components in another JVM, you must use a network protocol such as rmi.
The OSGi alliance is working on a standard for distributed OSGi:
http://www.osgi.org/download/osgi-4.2-early-draft2.pdf
There even is an early Apache implementation of this new standard:
http://cxf.apache.org/distributed-osgi.html
#Patriarch24
The accepted answer to this question would seem to indicate otherwise (unless I'm misreading it). Also, taken from the FAQ:
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restart
(Emphasis my own). Although in the same FAQ it describes OSGi as in-VM.
Why am I so confused about this? Why is such a basic question about a decade-old technology not clear?
The original problem of OSGI was more related to distribution of code (and then configuration of bundle) than to distribution of execution.
People looking at distributed components are rather looking towards SCA
The "introduction" link is not really an intro, it is a FAQ entry. For more information, see http://www.osgi.org/About/WhatIsOSGi Not hard to find I would think.
Anyway, OSGi is an in-VM SOA. That is, the OSGi Framework is about what happens inside the VM, it provides a framework for structuring your application inside the VM so you can built it too a large extent from components. So the core has nothing to do with distribution, it is completely oblivious of who implements the services, it just provides a mechanism for modules to meet each other in a loosely coupled way.
That said, the µService model reifies the joints between the modules and it turns out that you can build support on top of the framework that provides distribution to the other components. In the last releases we specified some mechanisms that make this standardized in the core and provide a special service Remote Service Admin that can manage a distributed topology.
If you are looking for a distributed OSGi centric Cloud runtime - then the Paremus Service Fabric ( https://docs.paremus.com/display/SF16/Introduction ) provides these capabilities.
One or more Systems each consisting of a number of OSGi assemblies (Blueprint or Declarative Services) can be dynamically deployed and maintained across a population of OSGi runtime Frameworks (Knopflerfish, Felix or Equinox).
A light weight RSA remote framework is provided which provides Service discovery by default using DDS (a seriously good middleware messaging technology) - (thought ZooKeeper and other approach can be used). Currently supported re-moting protocols include RMI and Avro.
Regards
Richard