Group items tagged

"An "executable" UML model is one with a behavioral specification detailed enough that it can effectively be "run" as a program. This can be extremely valuable in order to test and validate the model, independently of the one or more implementation platforms to which the system being modeled will ultimately be deployed. Or, in some cases, the model itself can actually be run as the production implementation, given an appropriate execution environment. There have been model execution tools and environments for years, even before UML. However, each tool defined its own semantics for model execution, often including a proprietary action language, and models developed in one tool could not be interchanged with or interoperate with models developed in another tool. A previous post described Stephen Mellor's quest of more than a decade to change this through OMG standards for precise UML model execution semantics and a UML action language. In 2008, this led to the adoption of the Foundational UML (fUML) specification, providing the first precise operational and base semantics for a subset of UML encompassing most object-oriented and activity modeling. The fUML specification still did not provide any new concrete surface syntax, however, tying the precise semantics solely to the existing abstract syntax model of UML. This meant that, in order to fully specify a detailed behavior in a UML model - say the effect behavior of a transition on a state machine or the method of an operation of a class - one still had to draw a very detailed, graphical activity diagram. "

Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I'm really in favor of it. I see a lot of advantages compared to Sun's Java EE standard front-end framework JSF. First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that's an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J. Another advantage is the fact that Vaadin is easy to learn (JSF isn't!) and to use: it's straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I'm used to. Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure. Vaadin is very well documented. There's the book of Vaadin wich explains every aspect of the framework very clear. On the site there's a blog, a FAQ section, a wiki, a forum, examples with Java source code, … It's very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There's also an add-on directory where you can download UI components, data components, tools, themes, …

I am working on a web site that will help students practice their Scala programming skills. As I labored along, writing my JSF app code, I thought "this is silly-why not practice Scala at the same time?" But I like JSF and wasn't ready to jump to Lift or Vaadin. With Eclipse, this isn't all that hard. Install the Java plugin. Make a dynamic web project in the usual way, using the Java EE perspective. Then, switch to the Scala perspective, right-click on the project, and, if all planets are aligned correctly, you will get a menu item "Add Scala nature". (If they are not, see here for a manual approach.) Add your managed beans as Scala classes. Finally, switch back to the Java EE perspective, select the project properties, and add the Scala library JAR as a Java EE module dependency. But I like NetBeans and wasn't ready to switch to Eclipse. (Unfortunately, JSF 2 support in Eclipse is pretty minimal, the Glassfish integration is a bit flaky, and the Scala plugin has very little usable code completion.) NetBeans doesn't let me add a "Scala nature" to a web project. If I add Scala files to the project, I can edit them with the Scala editor, but they just get copied to the WAR file, without any compilation. I had one look at the Ant scripts for a Scala and a web project and decided that I wasn't going to figure out how to merge them. This blog shows how you can use Maven to make a mixed Scala/Java project in NetBeans. So I gathered up JSF and Scala pom.xml files from here and here, cut out the considerable crud from the JSF POM file that was probably meant for supporting Tomcat, and merged the results to the best of my ability-see below. You use the usual Maven directory structure, but with a src/main/scala directory instead of src/main/java:

"I've had an opportunity recently to work on a product that needed an RIA web interface, and I chose my recent favorite tool for this, Vaadin. The services for this project needed to be highly scalable, and lent themselves well to functional techniques, so I selected Scala as my language of choice. I build my projects with Maven, for reasons I won't go into right now, and I do much of my JVM-language work in Intellij's excellent IDEA IDE. Given these tools, I found a way to facilitate very rapid development of web UI's, and I thought I'd pass it along. Another technique I use, which I'll expound on later, is creating "dummy" implementations of all of my backing services for my application. The "real" implementations are written as OSGi services, in separate modules from my UI. The UI is packaged as a war, but is also OSGi aware, with a bundle activator. This activator only gets called if the war is deployed into an OSGi container, and not otherwise. This allows the app to select which implementation of the services it uses - the "dummy" ones when it's deployed outside of OSGi, and the "real" ones when they're available. This means I can use the handy Maven jetty plugin to quickly spin up my application and test it on my local workstation, without needing all of the dependencies (like a data store and such) of my real services. That's good, in that I can get my "cycle time" down to a few seconds, where "cycle time" is the time between making a change and actually being able to test it in my browser. We can do better, though. I'm using Scala as my language of choice for building the UI as well, as it works just fine with Vaadin (and with everything else in the JVM ecosystem, for that matter, which is why I didn't choose a non-JVM language - but that's yet another rant). I compile my Scala with the Maven scala plugin - here's where the next handy bit comes into play. Turns out the Scala plugin has a goal cal

ModeShape (formerly "JBoss DNA") is a JCR 2.0 (JSR-283) implementation that provides access to content stored in many different kinds of systems. A ModeShape repository isn't yet another silo of isolated information, but rather it's a JCR view of the information you already have in your environment: files systems, databases, other repositories, services, applications, etc. To your applications, ModeShape looks and behaves like a regular JCR repository. Using the standard JCR API, applications can search, navigate, version, and listen for changes in the content. But under the covers, ModeShape gets its content by federating multiple back-end systems (like databases, services, other repositories, etc.), allowing those systems to continue "owning" the information while ensuring the unified repository stays up-to-date and in sync. ModeShape repositories can be used in a variety of applications. One of the most obvious ones is in provisioning and management, where it's critical to understand and keep track of the metadata for models, database, services, components, applications, clusters, machines, and other systems used in an enterprise. Governance takes that a step farther, by also tracking the policies and expectations against which performance can be verified. In these cases, a repository is an excellent mechanism for managing this complex and highly-varied information. But a ModeShape repository doesn't have to be large and complex: it could just manage configuration information for an application, or it could just provide a JCR interface on top of a couple of non-JCR systems.

"Community Dashboard Framework (CDF) is a project that allows you to create friendly, powerful, fully featured dashboards on top of the Pentaho BI server. Former Pentaho dashboards had several drawbacks from a developer's point of view. The developing process was awkward, it required know-how of web technologies and programming languages, and basically it was time-consuming. CDF emerged as a need for a framework that overcame all those difficulties. The final result is a powerful framework featuring the following: . It is based on Open Source technologies. . It separates logic (JavaScript) of the presentation (HTML, CSS) . It features a life cycle with components interacting with each other . It uses AJAX . It is extensible, which gives the users a high level of customization: . Advanced users can extend the library of components. . They also can insert their own snippets of JavaScript and jQuery code. CDF can be used: . As part of a Pentaho solution. This is the most common scenario. . In a standalone mode as an alternative to the Pentaho User Console . Integrated with Portlets, PHP applications, intranet portals and even desktop applications. "

"Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR ). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection. Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs. I hope you find Clojure's combination of facilities elegant, powerful, practical and fun to use."

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I'd implied, so I thought I'd spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse. Prerequisites This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven't already - I had issues when I had multiple Lift projects imported with Xmx set to 386. Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I'm not sure how well it works with m2eclipse - I'm going to play with that more later. I also assume you know how to install plugins into Eclipse - I will create a more in-depth screencast for doing all of this if there is enough interest.

Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol") submission to W3C. From the draft W3C specification: SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. This project is a follow-on to the Apache SOAP project. Please see the Reference Library for a list of technical resources that should prove useful.

There are many approaches available to scale PostgreSQL beyond running on a single server. An outline of the terminology and basic technologies involved is at High Availability and Load Balancing. There is a presentation covering some of these solutions. There is no one-size fits all replication software. You have to understand your requirements and how various approaches fit into that. For example, here are two extremes in the replication problem space: You have a few servers connected to a local network you want to always keep current for failover and load-balancing purposes. Here you would be considering solutions that are synchronous, eager, and therefore conflict-free. Your users take a local copy of the database with them on laptops when they leave the office, make changes while they are away, and need to merge those with the main database when they return. Here you'd want an asynchronous, lazy replication approach, and will be forced to consider how to handle conflicts in cases where the same record has been modified both on the master server and on a local copy. These are both database replication problems, but the best way to solve them is very different. And as you can see from these examples, replication has a lot of specific terminology that you'll have to understand to figure out what class of solution makes sense for your requirements. A great source for this background is in the Postgres-R Terms and Definitions for Database Replication. The main theoretical topic it doesn't mention is how to resolve conflict resolution in lazy replication cases like the laptop situation, which involves voting and similar schemes.

"The concept of automatic incremental compilation is not familiar to many developers. A very frequent question from Eclipse beginners is, "where is the compile button?" The answer is that an IDE with automatic compilation doesn't need a compile button. Every time you make a change to a file, or a group of files, the incremental builder immediately rebuilds every source file that was affected by the change. In this environment, the idea of compilation as a task the user is involved in disappears -- the world is just always in a compiled state. So what magic goes on behind the scenes to make this happen? How does the Java™ builder know which files need to be recompiled when a given source file changes? This is no easy task, but in broad brush strokes, this is what the Eclipse Java builder does: "

"Developers usually have their programs write log and debug information to the standard output during coding and testing. This results in a lot of text being printed to Eclipse's console view, often more than can be easily surveyed. Since at any given time, only a small part of this information is of primary interest to the developer, a tool which highlights specific lines or words can significantly increase the readability of this output. Grep Console allows you to define a series of regular expressions which will be tested against the console output. Each expression matching a line will affect the style of either the entire line or parts of it. For example, error messages could be set to show up with a red background, or integer values showing the state of a certain variable could be rendered in bold font. "

"A lot of people have asked me to document the reasons I want to migrate Hibernate from Maven to Gradle as its build tool so I enumerate those reasons here. If you are completely new to Gradle, I suggest having a look at their overview page. Up front I want to point out that this is not intended as a "Maven bash session" nor as a means to directly compare Maven and Gradle. It is just a means to describe the issues and frustrations I have seen in my 2.5+ years of using Maven for Hibernate builds; in many cases the cause is simply an assumption or concept in Maven itself which did not line up cleanly with how I wanted to do build stuff in Hibernate. Some of the list aggregated by Paul comes directly from Hibernate use-cases; I'd suggest reading through those as well. It is also a means to describe why I decided on Gradle as opposed to other related build tools out there now (Buildr, SBT, etc). Note that there is a comparison wiki between Gradle and Maven, but that it is quite old and out of date in many respects especially in regards to Gradle. The issues I had with Maven (note that these are largely chronological, not in order of "importance") are as follows:"

The aim of this paper is a brief introduction to MDA technology and a summary / comparison to the approachments to MDA of AndroMDA and Acceleo, intending to be a practical and understandable summary Introduction Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. It was launched by the Object Management Group (OMG) in 2001 The Model-Driven Architecture approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language (DSL). One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.

Last week I decided to challenge Scala's downscalability by trying to replace a Groovy script with a Scala pendant. In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor. But first some background about the script: Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it. Here you see an example of such a mail (note: I have my mails displayed in plain text format):

This article shows how to develop a simple plugin which provides a custom transformation step for Kettle 4.0. The transformation step should accept any row stream and append a string field at the end, filling it with a fixed value. The user should be able to define the name of the added field. For starters, that should be enough. Keeping the step functionality at a minimum allows me to explain how the plugin interfaces with Kettle with as little distraction as possible.

SymmetricDS is web-enabled, database independent, data synchronization/replication software. It uses web and database technologies to replicate tables between relational databases in near real time. The software was designed to scale for a large number of databases, work across low-bandwidth connections, and withstand periods of network outage. By using database triggers, SymmetricDS guarantees that data changes are captured and atomicity is preserved. Support for database vendors is provided through a Database Dialect layer, with implementations for MySQL, Oracle, SQL Server, PostgreSQL, DB2, Firebird, HSQLDB, H2, and Apache Derby included. Synchronization can be configured to push data (trickle-back) or pull data (trickle-poll) at an interval. SymmetricDS allows for synchronization between two or more tiers of nodes, such as the following: A farm of web server nodes fronting an enterprise-class general office database A handful of regional servers for synchronizing from the general office to remote geographical areas 1000(s) of store server nodes using a departmental class database to sync with a regional node 10(s) of Point of Sale (POS) register nodes using an embedded database to sync with a store server Deployment options include the following: Web application archive (WAR) deployed to an application server such as Tomcat, Jetty, or JBoss Standalone service Embedded in an application SymmetricDS is written in Java and licensed as open source software under the GNU Lesser General Public License (LGPL).

"I'll try to list all the MDE tools I know, I'll also try to reference them by their scope. Feel free to comment this list of MDE tools! M2M/M2T tools: actifsource (http://www.actifsource.com/) AndroMDA (http://www.andromda.org/) Eclipse ATL (http://www.eclipse.org/atl/) is a part of Eclipse Modeling project Eclipse QVTO (http://wiki.eclipse.org/M2M/QVTO) is a part of Eclipse Modeling project Itemis/Eclipse xpand/xtend (http://wiki.eclipse.org/Xpand) it was originaly a part of the no longer supported openArchitectureWare (http://oaw.itemis.com/ & http://www.openarchitectureware.org/) is now a part of Eclipse Modeling project Mia-Software Mia-Generation (http://www.mia-software.com/) is a part of Mia-Studio tool suite Mia-Software Mia-Transformation (http://www.mia-software.com/) is a part of Mia-Studio tool suite Obeo/Eclipse Acceleo (http://www.eclipse.org/acceleo/) is a M2T tool that has recently moved from the Obeo (http://www.obeo.fr/) company to Eclipse Modeling project"

The Java Content Repository (JCR) standard, which is based on the Java Specification Requests JSR170 (version 1.0) and JSR 283 (version 2.0), provides a Java-centric object-oriented storage API specifically targeted at content management scenarios. The JCR is not a content management system or a full-fledged content management system API, but rather a content repository API. A content repository provides a common API for all content-driven applications and CMS components, which require access to the content. It provides methods to read, write, and query content. The primary motivation of the JCR standard is to provide a standard and vendor-neutral programmatic interface for content repositories, allowing applications of multiple vendors to interact efficiently.