My requirement is that I am looking for an light weight event framework which is compatible in Android and Java Fx( Windows and Linux platform) so that it runs seamless in both the technologies.
I researched for existing event based frameworks.
1) Eventing framework mbassador (by bennidi)-> is it compatible with android 4.0 (Ice Cream sandwich)
as it works fine with javafx and is lightweight and performance is also good.
2) Guava EventBus :- From documentation it seems it is compatible with android but what about performance and is it better then mbassador.
Eventing framework MBassador is compatible with Android 4.0.
Guava Event Bus is lightweight and also compatible with both the technologies.
Both the above framework are lightweight and provide robust mechanism for Subscribe/Publish pattern and according to description of MBassador it's initial design was inspired from Guava Event Bus but the Strong reference to listeners used in Guava Event Bus was problem in some scenario.
According to credits section in description at GitHub MBassador
The initial inspiration for creating this component came from trying out Google Guava's event bus implementation. I liked the simplicity of its design and I do trust the developers at Google a lot, so I was happy to find that they also provided an event bus system. The main reason it proved to be unusable for our scenario was that it uses strong references to the listeners such that every object has to be explicitly deregistered. This was difficult in our Spring managed environment. Finally, I decided to create a custom implementation, which then matured to be stable, extensible and yet very efficient
Both the framework are robust, lightweight and it depends on your requirement which one to use.
I have found performance comparison on [Java event bus library comparison]](http://codeblock.engio.net/?p=37) (I got the results from google cached page of this site) where Google Guava, SimpleBus, EventBus and mbassador frameworks were compared and MBassador was the clear winner.
EDIT: I removed the picture snapshot and just focusing on end results,
The shown performance characteristics of the compared implementations indicate that,
1. Listener subscription is an expensive operation for all implementations but MBassador and Guava
2. Concurrent access does generally slow down the bus performance because of higher
contention/synchronization.
3. SimpleBus is by far the slowest implementation.
4. MBassador is by far the fastest implementation in all
scenarios. It also offers the best scaling characteristics meaning that higher concurrency rates do not slow down the bus performance as much as the others. This is because MBassador relies on a custom data structure with very fast write operations that do not block readers and at the same time do not copy existing data structures (most other implementations use CopyOnWriteArrayList).
To sum it up For the past few months we have been using MBassador and it holds up to our requirement it is working well in Android, JavaFX and works well in simple java too on Linux, Windows, Mac etc O.S.
Related
Google search gives me, 'The Collection in Java is a framework...'. Further search gives me, 'The key difference between a library and a framework is "Inversion of Control"'. I reckon in Collection's context, framework is not used in the sense of IoC. Please enlighten.
The main difference between Library and Framework is:
Library = Set of useful components
Framework = Set of useful components + Utilities to use the components
Library is a set of reusable components.
It provides flexibility to the user on the way in which the components can be called or used.
A real-world analogy of Library:
Traditional City Taxi service is like a library.
Taxi can be called by waving hand, or by shouting 'Taxi...', or by calling a telephone number.
Framework is a Library that comes packaged along with some utilities for using the library.
Framework provides an extra benefit, by offering an efficient built-in way of using the components.
A real-world analogy for framework:
A Taxi service that comes with its own app is like a framework.
The Taxi cannot be called by waving hand or shouting 'Taxi...'.
Taxi can be booked only by using the app.
Java Collections is labeled as a framework, instead of as a library, because it comes with some useful implementations of algorithms (sorting, queue management, etc) along with the set of useful components (List, Set, HashMap, etc).
For example, Java Collections Framework provides an efficient built-in algorithm for sorting objects.
The programmer can choose to either use the built-in sorting utility or write a new algorithm.
As the built-in algorithms are provided along with components, Java Collections is considered a framework, rather than just a library.
A "framework" doesn't imply IoC.
The term is not well-defined, proven by the fact that you can find different definitions online.
E.g. techterms.com says:
A framework, or software framework, is a platform for developing software applications. It provides a foundation on which software developers can build programs for a specific platform. For example, a framework may include predefined classes and functions that can be used to process input, manage hardware devices, and interact with system software. This streamlines the development process since programmers don't need to reinvent the wheel each time they develop a new application.
The "Java Collections Framework" is a good "foundation for building programs". That's all it means.
It seems on every iteration of Java for the last few major releases, there are consistently new ways to manage concurrent tasks.
In Java 9, we have the Flow API which resembles the Flowable API of RxJava but with Java 9 has a much simpler set of classes and interfaces.
Java 9
Has a Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, and SubmissionPublisher, and that's about it.
RxJava
Has whole packages of Flow API-like classes, i.e. io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers, and io.reactivex.observables which seem to do something similar.
What are the main differences between these two libraries? Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
What are the main differences between these two libraries?
The Java 9 Flow API is not a standalone library but a component of the Java Standard Edition library and consists of 4 interfaces adopted from the Reactive Streams specification established in early 2015. In theory, it's inclusion can enable in-JDK specific usages, such as the incubating HttpClient, maybe the planned Async Database Connection in parts, and of course SubmissionPublisher.
RxJava is Java library that uses the ReactiveX style API design to provide a rich set of operators over reactive (push) dataflows. Version 2, through Flowable and various XxxProcessors, implements the Reactive Streams API which allows instances of Flowable to be consumed by other compatible libraries and in turn one can wrap any Publisher into a Flowable to consume those and compose the rich set of operators with them.
So the Reactive Streams API is the minimal interface specification and RxJava 2 is one implementation of it, plus RxJava declares a large set of additional methods to form a rich and fluent API of its own.
RxJava 1 inspired, among other sources, the Reactive Streams specification but couldn't capitalize on it (had to remain compatible). RxJava 2, being a full rewrite and a separate main version, could embrace and use the Reactive Streams specification (and even expand upon it internally, thanks to the Rsc project) and has been released almost a year before Java 9. In addition, it was decided both v1 and v2 keeps supporting Java 6 and thus a lot of Android runtimes. Therefore it couldn't capitalize directly on the Flow API provided now by Java 9 directly but only through a bridge. Such bridge is required by and/or provided in other Reactive Streams-based libraries too.
RxJava 3 may target the Java 9 Flow API but this hasn't been decided yet and depending on what features the subsequent Java versions bring (i.e., value types), we may not have v3 within a year or so.
Till then, there is a prototype library called Reactive4JavaFlow which does implement the Flow API and offers a ReactiveX style rich fluent API over it.
Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
The Flow API is an interoperation specification and not an end-user API. Normally, you wouldn't use it directly but to pass flows around to various implementations of it. When JEP 266 was discussed, the authors didn't find any existing library's API good enough to have something default with the Flow API (unlike the rich java.util.Stream). Therefore, it was decided that users will have to rely on 3rd party implementations for now.
You have to wait for existing reactive libraries to support the Flow API natively, through their own bridge implementation or new libraries to be implemented.
Providing a rich set of operators over the Flow API is only reason a library would implement it. Datasource vendors (i.e., reactive database drivers, network libraries) can start implementing their own data accessors via the Flow API and rely on the rich libraries to wrap those and provide the transformation and coordination for them without forcing everybody to implement all sorts of these operators.
Consequently, a better question is, should you start using the Flow API-based interoperation now or stick to Reactive Streams?
If you need working and reliable solutions relatively soon, I suggest you stick with the Reactive Streams ecosystem for now. If you have plenty of time or you want to explore things, you could start using the Flow API.
At the beginning, there was Rx, version one. It was a language agnostic specification of reactive APIs that has implementations for Java, JavaScript, .NET. Then they improved it and we saw Rx 2. It has implementations for different languages as well. At the time of Rx 2 Spring team was working on Reactor — their own set of reactive APIs.
And then they all thought: why not make a joint effort and create one API to rule them all. That was how Reactive Commons was set up. A joint research effort for building highly optimized reactive streams compliant operators. Current implementors include RxJava2 and Reactor.
At the same time JDK developers realized that reactive stuff is great and worth including in Java. As it is usual in Java world the de facto standard become de jure. Remeber Hibernate and JPA, Joda Time and Java 8 Date/Time API? So what JDK develpers did is extracting the very core of reactive APIs, the most basic part, and making it a standard. That is how j.u.c.Flow was born.
Technically, j.u.c.Flow is much more simpler, it consists only of four simple interfaces, while other libraries provide dozens of classes and hundreds of operators.
I hope, this answers the question "what is the difference between them".
Why would someone choose j.u.c.Flow over Rx? Well, because now it is a standard!
Currently JDK ships with only one implementation of j.u.c.Flow: HTTP/2 API. It is actually an incubating API. But in future we might expect support of it from Reactor, RxJava 2 as well as from other libraries, like reactive DB drivers or even FS IO.
"What are the main differences between these two libraries?"
As you noted yourself, the Java 9 library is much more basic and basically serves as a general API for reactive streams instead of a full-fledged solution.
"Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?"
Well, for the same reason people use basic library constructs over libraries - one less dependency to manage. Also, due to the fact that the Flow API in Java 9 is more general, it is less constrained by the specific implementation.
What are the main differences between these two libraries?
This mostly holds true as an informative comment(but too long to fit in), the JEP 266: More Concurrency Updates responsible for the introduction of the Flow API in Java9 states this in its description(emphasis mine) -
Interfaces supporting the Reactive Streams publish-subscribe
framework, nested within the new class Flow.
Publishers produce items
consumed by one or more Subscribers, each managed by a Subscription.
Communication relies on a simple form of flow control (method
Subscription.request, for communicating back pressure) that can be
used to avoid resource management problems that may otherwise occur in
"push" based systems. A utility class SubmissionPublisher is provided
that developers can use to create custom components.
These (very
small) interfaces correspond to those defined with broad participation
(from the Reactive Streams initiative) and support interoperability
across a number of async systems running on JVMs.
Nesting the interfaces within a class is a conservative policy allowing
their use across various short-term and long-term possibilities. There
are no plans to provide network- or I/O-based java.util.concurrent
components for distributed messaging, but it is possible that future JDK
releases will include such APIs in other packages.
Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
Looking at a wider prospect this is completely opinion based on factors like the type of application a client is developing and its usages of the framework.
I am trying to pick a right web technology both for I/O heavy and CPU heavy tasks. NodeJs is perfect for handling large load and it also can be scaled out. However, I am stuck with the cpu heavy part. Is it possible to integrate another technology (e.g. Java) into node, so that I will have it running my algorithms in other threads and then use the results again in node. Is there any existing solution? Any other suggestions will be very good.
You can intergrate NodeJS with Java using node-java.
As mentioned in a previous answer, you can use node-java which is an npm module that talks to Java. You can also use J2V8 which wraps Node.js as a Java library and provides a Node.js API in Java.
The answer is lambda architecture.
NodeJs is nice by itself - handling fast queries in a lightweight manner, not doing any extra computations on data.
The CPU heavy tasks can be easily delegated to specialized components based on JVM (well, the most famous ones are on JVM). This is nicely implemented by using message brokers and microservices.
An event-based architecture, where nodejs can be hooked up to databases like Cassandra or Mongodb and cluster computing frameworks like Apache Spark (not necessarily, though, it depends on the problem) to handle the cpu-heavy parts of the system. And lightweight containers add an icing to the cake by providing nice isolated runtime environments for each of the components to live in.
That's my conclusion so far regarding this question.
I think the suggestions above sort of eliminate the need to wrap node under java or other JVM based solution for cpu-heavy tasks.
NodeJS is based on the v8 javascript engine which is written in c++.
It is therefore possible to write fully native addons in c++ for NodeJS. Check out some of these resources:
https://github.com/nodejs/node-addon-api
https://github.com/nodejs/node-addon-examples
I'm looking for a straightforward Java workflow engine that:
can handle both automated and manual (GUI-based) steps within a workflow
supports long-running, asynchronous tasks
provides support for restarting workflows in the event of a server crash
stores a full audit history of previously executed workflows
provides easy access to this audit history data
Possible candidates include the new Drools Flow process engine in Drools 5, and OSWorkflow from OpenSymphony. From my current understanding, OSWorkflow seems to offer more of what I want (Drools Flow doesn't appear to store much in the way of an audit history); however, the most recent release of OSWorkflow was back in early 2006. Is it a mistake to now use OSWorkflow when it's no longer under active development?
Does anyone have much experience with either/both of these frameworks? Are there any other workflow engines I should be looking at? All recommendations welcome - thanks.
Just to clarify how Drools Flow supports the requirements you are describing (refering to the Drools Flow documentation):
can handle both automated and manual (GUI-based) steps within a workflow
Drools Flow uses (domain-specific) work items (Chapter 8) to interact with external systems. These could be automated services, or a human task management component (Chapter 9) for manual tasks. This human task component is fully pluggable but Drools Flow supports a WS-HumanTask implementation out of the box. Drools 5.1 will include web-based task lists, including custom task forms.
supports long-running, asynchronous tasks
The engine allows you to start processes that can live for a long time. The process supports different kinds of wait states (work item nodes, event nodes, event wait nodes, sub-process, etc.) to model long-running processes. External tasks can be integrated synchronously or asynchronously.
provides support for restarting workflows in the event of a server crash
The runtime state of all process instances can easily be stored in a data source by turning on persistence (Chapter 5.1). Therefore, all processes can simply be restored in the state they were in after a server crash.
stores a full audit history of previously executed workflows
Drools Flow generates events about what is happening during the execution of your processes. By turning on audit logging (Chapter 5.3), these events can be stored in a database, providing a full audit history of whatever happened during execution.
provides easy access to this audit history data
The history data is stored using a few simple database tables. These tables can be queried directly, or you could use it for generating custom reports (Chapter 12.1) that show the key performance indicators that are relevant for your application.
Furthermore, we believe that a knowledge-oriented approach, allowing you to seamlessly combine processes with rules and event processing whenever necessary, will offer you more power and flexibility compared to aforementioned process-oriented engines.
Kris Verlaenen
Drools Flow Lead
I've not had any experience with the candidates you've mentioned but judging from the projects that I've worked on it might be worth looking at jBPM. Quite a few developers I've worked with swear by it and I think it fits your criteria quite nicely.
Drools Flow is at lot more sophisticated and powerful than both jBPM and OSWorkflow and development is moving at a faster pace than either. We provide a lot of details and screenshots here:
http://www.jboss.org/drools/drools-flow.html
But in summary. You get interactive debugging across rules, workflow and event processing. You have a larger set of built in nodes, improving the number of problems you can directly model declaratively. Correlated (across rules, processes and events) audit logging and reporting. We provide a very simple and yet powerful mechanism for building domain specific workflow, via our pluggable work items.
Drools 5.0 has just been released and 5.1 is going to follow in the next 4 to 6 weeks. We are adding simulation and testing for this, using an MVEL DSL, which we believe will be a huge hit. This will also include more extensive work for remote admin GUIs for processes, all integrated into Guvnor.
The Drools team also prides itself on being more accessible than any of those other mentioned projects. Feel free to pop onto irc for a chat.
Mark
I have experience with both.. also I was involved in a tool for migrating existing processes in OSWorkflow to Drools 5.0. You can read an article about that in: http://blog.athico.com/2009/01/drools-flow-and-osworkflow-migration.html. It is important to mention that this migration tool/translator was created to allow old projects that are using OSWorkflow to upgrade to Drools 5.0 and take advantages of all the Drools 5.0 Business Integration Platform.
Greetings
One chapter in Pragmatic Programmer recommends looking at a blackboard/space-based architecture + a rules engine as a more flexible alternative to a traditional workflow system.
The project I'm working on currently uses a workflow engine, but I'd like to evaluate alternatives. I really feel like a SBA would be a better solution to our business problems, but I'm worried about a total lack of community support/user base/venders/options.
JavaSpaces is dead, and the JINI spin-off Apache River seems to be on life support. SemiSpace looks perfect, but it's a one-man show. The only viable solution seems to be GigaSpaces.
I'd like to hear your thoughts on space based architecture and any experiences you've had with real world implementations.
Why do you regard Javaspaces as dead, beyond the fact that the Jini 2.1 release was some time ago (October 2005) ? Having used that, I'd suggest that it indicates a mature and complete technology set rather than something abandoned and defunct.
For another implementation of Javaspaces, take a look at Blitz Javaspaces. That's maintained and enhanced more regularly (latest release July 2008) and offers a more performant and manageable Javaspace implementation than the default outrigger supplied by Sun.
Gigaspaces is a successful commercial implementation of JavaSpaces -- so, I wouldn't say JavaSpaces is dead.
You might take a look at Java Shared Data Toolkit (also this article) to see if it meets your requirements.
Space-based architecture is a distributed-computing architecture for achieving linear scalability of stateful, high-performance applications using the tuple space paradigm With a space-based architecture, applications are built out of a set of self-sufficient units, known as processing-units.
Ex: Gigaspaces
here I attached the reference for gigaspaces.
https://docs.gigaspaces.com/latest/overview/space-based-architecture.html
While it doesn't support the JavaSpaces API, I'd suggest looking at Oracle Coherence for a distributed and reliable "live" data store that can drive event-based workflow. Deutsche Bank, for example, successfully replaced a "SBA" (Space Based Architecture) with an event-driven system built on Coherence for their FX trading, because of both reliability and performance issues.
For the sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.