• Home
  • Events
  • About
  • OpenDolphin 0.9 released with push for many devices

    March 13th, 2014

    The OpenDolphin project has released version 0.9.

    This new release includes a new “push” capability for instant, bi-directional updates and a full-featured OpenDolphin web client for use with HTML5 and JavaScript/TypeScript.

    The inclusion of the web client OpenDolphin.js allows to share the same OpenDolphin application on desktop and web, including mobile web.

    OpenDolphin on many devices

    OpenDolphin on many devices

    The push capability has been moved from the demos into the OpenDolphin core and is now an official feature with a simple API, standard behavior, and – as always – the option the replace the default implementation with your preferred technology.

    Both OpenDolphin.js and the push capability in combination with the existing OpenDolphin features allow for new interesting use cases many of which are show-cased in this release:

    • multi-device applications where the same application runs on many devices
    • re-connect to an application exactly where you left off even after a longer offline period
    • follow-me applications where you start your work on one device – let’s says on the road with a smartphone or a tablet – and complete your work in the office with a desktop application for longer text entries
    • team-applications where a whole team works collaboratively and everybody immediately sees all contributions from all other team members, avoiding double-work and conflicts, and mutually completing, correcting, and helping with each other’s work
    • point-of-sale solutions where personnel shares a limited set of workstations, freely moving between them and always having their latest context available
    • application integration where you combine the strength of different view technologies, say JavaFX for the layout and web technology for charting, into an integrated OpenDolphin application.

    Furthermore, a number of performance enhancements and consistency checks have been included.

    Please find the full list of changes in the release notes and check out the latest demos.


    From Java to JavaScript/TypeScript

    January 14th, 2014

    Experiences when porting the OpenDolphin client to the web

    dolphinIn spring of 2013 we started with a prototype of a JavaScript port for the OpenDolphin client, which at that time was only available for the Java platform and mainly used with Swing and JavaFX.
    We did a few demos with that prototype and found it to be valuable and promising such that we decided to bring it to production quality.

    This blog post describes the experiences that we made along the way.

    Non-functional requirements and technology choices

    For the sake of getting to speed quickly, the prototype had used a zoo of technologies:
    grunt, bower, require, jquery, angular, node, and a few more. For a production version, though, we
    wanted to have the fewest amount of dependencies such that a user of OpenDolphin.js
    would not run into compatibility issues with his own choice of libraries and their
    respective versions.
    We found namespacing and module management to be critical and decided to stay with
    require.js (with the option to drop that later) but drop all other runtime dependencies.

    Since OpenDolphin.js is a library (as opposed to an application) we expect that we
    have to maintain it over quite some time – a longer period of time than most
    current development tools will be available.
    That is: we can only use tools that produce tool-independent artifacts.
    This consideration ruled out tools like Dart and GWT for development since their
    generated JavaScript is not well-suited for development once the tool is
    discontinued.

    We tried TypeScript for a week before we decided that it looked pretty much like what we
    needed (our state of information at the time of decision):
    - namespacing
    - modularization
    - abstraction over types (classes and interfaces)
    - type safety
    - code navigation (“where used”)
    - simple test facility
    - source-code debugging
    - very readable JavaScript source code generation
    In fact, we found the generated JavaScript to be more consistent and readable
    than what I had written manually – mainly because it wouldn’t have any of the
    dirty tricks that one can do in JavaScript.

    Experiences with TypeScript

    In hindsight, we should have experimented more before starting the real
    development and should have tested the distribution story. As it turned out
    I misunderstood TypeScript modules as being mainly a tool to provide
    namespaces – like packages in Java – but it is just as well a distribution
    mechanism. You see that when you try to “package” a module that spans
    over multiple files, which is not supported.
    A helpful voice pointed that out to me on stackoverflow and correctly
    mentioned that the documentation also says so (even though not very
    prominently).

    I was finally able to combine all my generated JavaScript in a single file
    with some Gradle/Groovy trickery but overall it costed me a day of
    investigation, trial, error, and fixing.

    We wasted two more days with hunting down two TypeScript errors that we
    simply didn’t expect to be possible: we ran into a situation where
    TypeScript inheritance silently didn’t work and on a second occasion
    we got two different instances of the same static reference.

    Lesson learned: avoid inheritance and statics even more than usual.

    This lesson actually turned out to be benefitial because it led to a simpler
    design, e.g. around the HttpClientConnector that we refactored from a
    subclass into a Transmitter interface that the ClientConnector points to
    with NoTransmitter and HttpTransmitter as implementations.
    We plan to refactor the Java version accordingly.

    While it first felt a bit weird that TypeScript cannot compile all
    our *.ts files at once, we learned to value the fast incremental compile
    especially when combined with the Intellij IDEA file watcher setup.

    In the beginning TypeScript feels as if it made your JavaScript more object-
    or better say type-oriented. But the real benefit is that it
    very much improves the “functional programming” story, which is already
    pretty strong in JavaScript but TypeScript adds more structure to it
    when declaring, implementing, or calling functions.
    This is kind of an under-marketed feature of TypeScript.

    We struggled a bit with how to organize *.ts files and references
    between them in a way that works consistently in all scenarios
    - when delivered from a web server or node.js
    - when loaded from a static html file
    - when testing
    - when debugging
    and I’m afraid our solution is not optimal since it led to
    quite a lot of duplication in the references (relative file paths).
    It would be helpful if the TypeScript documentation gave better
    advice on the topic or propose best practices.

    The TypeScript documentation was generally a doubly-edged experience.
    While the language part is well documented, the API is not.
    When searching for a feature I often landed at places where the
    shape of that feature was discussed between the developers
    but could not find any kind of “user guide”.
    But, well, it is version 0.9 and it is free, so we should not complain
    especially since the response time for questions on stackoverflow
    was awesome.

    IDE support inside Intellij IDEA is pretty strong and has helped us a lot.
    Basic things like highlighting, navigation, code completion, and so on
    work reasonably well and certainly better than for plain JavaScript.
    One should not expect the same sophistication like for Java or Groovy,
    though, when it comes to refactoring across multiple files.

    Would I decide for TypeScript again? Definitely yes!
    But I would allow more time for finding the best setup.

    OpenDolphin for the web

    OpenDolphin is use-case driven. We only include a feature, if we have
    a use-case for it and with any use case comes a demo. This nicely
    leads to the comfortable situation that every feature is used
    in at least one demo.

    The additional feature of OpenDolphin.js over the Java version is:
    “it also works in the browser” be it desktop or mobile.
    Consequently, we created some demos.

    Creating the demos immediately revealed how well the OpenDolphin architecture
    (structure, concepts, abstractions) fits for web development. Having
    - views in HTML5 that are totally separate,
    - a binding technology of your choice
    (JavaScript, TypeScript, GSP, vanilla.js, angular.js, GWT, …), and
    - server-side control over the presentation models with Java
    leads to a new level of enterprise applications.

    These new enterprise applications are automatically consistent,
    they update their content immediately, they share information with other
    users, and facilitate user collaboration at a totally new level.
    One can see these features boiled down to the bare minimum in the chat demo.

    Best of all: desktop, web, mobile, and even embedded applications all share
    the same information at runtime and the same programming model!
    They all connect to the exact same server-side application logic.

    The web for application development

    For anyone with experience in desktop UI toolkits like JavaFX, Swing, or
    equivalents web development feels casual and coincidental.
    Obviously, one can “get things done” but it is hard to say whether they
    only work by chance, what the actual constraints are, and on which
    guarantees one can build (pun intended).

    Take a slider as in the master-detail demo.
    There is no such control in HTML5 – as there are no
    real “controls” in the browser anyway. Ok, you can use the “input” element
    with type “range” in some browsers. But which events are fired when
    you drag the thumb? And are they fired while you drag or only after
    stop? Happy testing in all your supported browsers!
    Now try to enlarge the thumb for touch support with CSS – and
    consider that some browsers use circles and others use squares…

    I wouldn’t even go into more advanced controls like tables. HTML5 has no control
    that even remotely compares to what you have in the most basic JavaFX table view.

    But sliders and tables are only the tip of the iceberg. There are no controls.
    There are no layout managers. There is no usable logging. Basic datatypes are missing.
    Performance characteristics of existing datatypes are unclear. Object lifecycle
    is unclear. Scoping is counter-intuitive.
    To make matters worse, you can add ever-changing libraries that try to fill these gaps.
    Welcome to dependency hell!

    In short: the browser is a problematic execution environment.

    Now, if developing applications for the web is so immature, why do we even
    bother creating OpenDolphin.js? Because the web is everywhere and easy to access
    and there is an undeniable request for enterprise applications to have selected parts
    of their functionality visible and accessible on the web.

    The web makes an extremely good distribution channel for information.
    While creating the OpenDolphin web demos, I started to make extensive use of
    the browser features for developers (I know, I’m late to the party).
    These are extremely helpful while developing and occasionally scary when they
    reveal what many of the websites I visit are doing on my machine.
    One should always keep in mind that there is no privacy in the browser.

    As it stands today, we can recommend this mix for enterprise applications:
    - desktop (preferrably in JavaFX) for the office worker to safely edit the core of the system
    - web and mobile “extensions” for special purposes
    (dashboard, directions, check lists, mobile data capture, location, local sensors, field work)
    all conveniently integrated in the OpenDolphin architecture.

    Lessons learned

    When creating the JavaScript implementation of the OpenDolphin architecture, we of
    course profited much from having the Java implementation as a blueprint.
    But it actually turned out to be benefitial both ways: the Java version also
    profited since it was implicitly reviewed along the way and we could improve it in two places
    where even our 100% test coverage was not good enough to uncover a bug.

    Furthermore, the architecture was scrutinized a second time and I feel
    “implement a second time in a different technology” is a great validation
    technique for any architecture. This also led to a better distinction between
    rules and concepts of the architecture versus special design decisions for
    each implementation.

    JavaScript/TypeScript has less features than Java – especially around
    concurrency and inheritance -, which forced us into simpler albeit less powerful designs
    that we may partially bring back to the Java (“compact-0 profile”) implementation in the future.

    It was a pleasure to see that with OpenDolphin.js we can reap the same
    architectural benefits for web applications that we experienced for desktop apps
    while adding the web as a new option for exchangeable visualization technologies.

    That was what we were hoping for but then to see it working out so well
    has been a huge reward for the effort.

    Dierk König

    P.S. OpenDolphin.js will be part of the imminent 0.9 release of OpenDolphin.


    OpenDolphin 0.8 released – scaling and production readiness

    July 28th, 2013

    dolphinWe are happy to announce a significant milestone for the OpenDolphin project: the 0.8 release.

    With 1.0 coming closer, we have focused on harmonizing the API and supporting production systems in terms of scalability, performance, resource consumption and monitoring capabilities.

    The original plan was to care about the production support after the 1.0 release but since OpenDolphin is already used in mission critical and reasonably large production systems, we had to adapt. This led to a deferral of the 0.8 release date but with the benefit of having a production-ready system much earlier.

    Between the various improvements are:

    • new internal asynchronous event handling based on kanbanflow that has proven to scale very nicely with the number of available processing units. OpenDolphin is ready for the multi-core era.
    • client-side presentation models are an option for cases where you need the full versatility of presentation models for the view without the controller knowing anything about it. This enhances performance since no updates are ever sent to the server and it dramatically reduces memory footprint on the server.
    • command batching collects client-side commands in packets before sending them to the server. This is a tremendous time saver when there are very many commands to be sent. It goes without saying that all OpenDolphin characteristics like asynchronous sending and strict command sequence remain untouched.
    • compressing codecs can be used when there is a lot of data to be sent in either direction. We just zip it up.
    • adaptive logging allows to set log levels at runtime (!) on a granularity of your choice to look into pretty much every detail of OpenDolphin.
    • session affinity checks protect your application against server misbehavior with respect to breaches of session affinity (as experienced with market-leading products).

    In the project infrastructure we have seen advances such as

    • 100% test coverage, i.e. statement coverage without any exclusions as visible from the continuous integration builds.
    • revamped website, which we hope you’ll like.
    • more demos particularly around synchronizing many clients and a large set of data points but also for point-of-sale systems and typical business applications.
    • improvements to the jump-start project and the project generator for quickly getting into OpenDolphin.

    The ecosystem around OpenDolphin is growing and has come up with great new approaches like

    I’d like to say a big thank you to all involved parties, particularly our early-adopting users for their great feedback.
    I’m also happy to point out the contributions of our new committers Andreas, Detlef, Christoph, and Sven.

    In order to use the latest release, just update your dependencies from 0.7 to 0.8.

    We plan to release version 1.0 this summer with additional convenience features and a more extensive user guide.

    Have fun!
    Dierk König


    JUGS Event – Talk Open Dolphin | Apr 30, 2013 | Basel

    April 12th, 2013
    Open Dolphin was first announced by Canoo at the JavaOne keynote 2012. Those for whom San Francisco was too far to travel, however, now have the chance to find out more about the open source project at the end of April right on our doorstep. Dierk König will be providing a fascinating insight into the concept and architecture of Open Dolphin at the JUGS Event in Basel. Be sure to be there!

    JavaFX Abacus Tutorial, Part VII – proper structure with OpenDolphin

    March 3rd, 2013

    This is the seventh part of a basic tutorial on JavaFX. The other parts can be found here and the code is on github. The running example of the tutorial is to build an abacus. If you are curious how the final solution will look like, please
    have look at this 7 min video.

    Until part six, we have developed a nice-looking and basically functional abacus. It isn’t yet fully functional since the overflow rule is missing: when pushing balls to right and we come to the last available ball, we must push all balls on the current rail back to the left and add a ball in the rail above. You can see this effect in the video around the 1:50 timestamp. We could do this work just as manually as one does it with a physical abacus but it would be much more convenient if the application could do it for us – imagine how much easier it would be to calculate 999’999 + 1 if we had an automatic overflow (video).

    With this new requirement we have reached the limit where it no longer feels appropriate to

    • have all view and controller logic as well as starter configuration in one class
    • have controller logic working directly on the view without any model.

    Now, we could go the route of creating model classes like Board and Rail and Ball and work with observable lists and bindable properties (and I advice you give this approach a try) but that would mean that we model the domain while at the same time we make the domain aware of the view’s presentation technology (because of all the additional observable/bindable work).
    Let’s go for different approach, where we use presentation models with the help of OpenDolphin.

    Enter OpenDolphin

    OpenDolphin gives us a very clean structure with a clear separation of the following modules

    • client: only containing the view; depends on the view technology (JavaFX) and optionally on shared
    • server: only containing controller logic (actions), optionally depends on shared
    • shared: optionally share constants between client and server, depends on nothing
    • combined: starter configuration that depends on all the above

    There is a huge number of benefits that come with OpenDolphin but for the sake of brevity, we will only use a few of them. We can see a first obvious benefit from only looking at the dependency structure: the actions have no access to the view. The view and the view technology isn’t even on the classpath! No longer can you “accidentally” reach out from a controller onto a view. But how can an action do its work then?

    Presentation models are synchronized between client and server.
    Actions work on presentation models (CRUD operations).
    Views bind against presentation models and send commands to the controller.
    Presentation models are generic, i.e. we do not have to implement any specific class.

    Setting up

    Creating the modules and the dependencies may sound like a lot of work but there is a template that we have used to create the current codebase. The template is available from DolphinJumpStart where we used the dist/jumpstart-maven.zip, unzipped it to dolphinized, and changed the application name in the maven POMs.

    There also is a Gradle variant but if you are using Gradle, you will probably find your way around anyway.

    Abacus_Project_ViewTo get started, you best point your favorite IDE to the root pom.xml and let the IDE create a project for you.

    Tip: with multiple modules and source roots, it is often more convenient to use the “package view” (see screenshot on the right) than the classical directory view.

    Lifting the curtain

    AbacusStarter is the class with a main method that you use for starting the application. It sets up OpenDolphin with the in-memory mode since we currently run client and server in the same JVM (we can add remoting later). It also registers the AbacusDirector, which works a bit like a movie director: it tells what “actors” are in the play.

    After the setup, the AbacusStarter starts the show.

    And ” ACTION ! “

    We have two actions: the CreateBallsAction that initially creates a presentation model for each ball in the abacus, and the ToggleAction that is called when a ball is clicked.

    The gist of the CreateBallsAction creates a presentation model for each row/column combination:

    In the presentation model, we think in terms of “digits on a scale” and whether that digit is switched “on”. The view in contrast – which is only one of many possible views – uses the concept of balls sitting on a rail.

    The ToggleAction is a bit more involved as it contains two command handlers: one for toggling a digit (and its neighbors), and one for the overflow rule.

    The important point to note here is that the server knows, which ball has been touched on the client for toggling, because there is a special presentation model with the constant name PM_TOUCHED which is shared between client and server.

    The overflow rule is a value change listener on the server side that is triggered whenever a “leftmost” digit in switched to “on”.

    We get the nice effect that the overflow rule works separately from the toggling and that the proliferated overflow as in “99 + 1″ comes automatically.

    The separation of the overflow rule in this manner is not quite as easy to achieve without OpenDolphin. One has to ensure a proper sequence of events: pushing the ball to the right, moving the ball in the rail above, moving all balls in the current row to the left. It is all-too easy to fall for a “sham solution” that occasionally leaves balls in the wrong position because they are first moved left and then to the right.
    OpenDolphin guarantees a proper event sequence – even though it executes all actions asynchronously.

    Simple View

    This leaves us with the AbacusApplication JavaFX view. It has been slimmed down to the bare essentials: displaying the presentation models, calling the toggle command when needed.
    Two points are of main interest: the start method and the click handler.
    The start method now looks as follows:

    Note that we create the touchedBall presentation model on the client side and we are sending the CMD_CREATE_BALLS command to the server. Only when that command is finished, we have all necessary presentation models on the client to bind against. Therefore, we provide an OnFinishedHandler that is called when the command has finished with all newly available presentation models.

    The click handler is now registered like so:

    When a ball is clicked we first have to update the touchedBall state before we send the toggle command. Updating via apply essentially copies all values from the ballPm over to the touchedBall presentation model.

    But wait – the toggle action (see above) changes that value of the touchedBall – not of the ballPm that was copied. How is the change propagated back?
    That is because of the qualifier that we have set when creating the presentation models. This qualifier has been copied as well and when a value changes, all presentation models with the same qualifier are updated to the same value.
    Such a construction is only possible because all OpenDolphin presentation models live in a managed object space. OpenDolphin is always in total control of all presentation models, can retrieve them by id or other features, and cares for consistent updates.

    Finally

    This has of course only been a short introduction to OpenDolphin – or better not an introduction at all but a very special use case that can only show a very small fraction of its capabilities.
    I hope you found it useful and it made you curious to find out more.

    I planned this series to have 7 posts, which means we have now completed the curriculum. Congratulations!

    However, our final solution is so versatile, it would be a shame not to make use of it.
    It is has become simple to test the application logic (set/assert the presentation models), use other number systems (binary abacus anyone?), or make more use of cool JavaFX features to dramatically change the visual representation by solely changing the view. So don’t be surprised if you hear about post (8/7) in the near future.

    Please send me your questions/ideas/suggestions on twitter
    @mittie


    css.php