Monday, September 15, 2014

Automatically Generating MagicDraw Report

Someone asked me how to generate MagicDraw HTML report from a certain UML model automatically. This feature is actually quite practical since if you are working in a group of business analysts, architects, developers, quality assurance personnel and operators, you mostly don't want to tell them to use MagicDraw to open the MDZip file. In this case you have two choices available:
  1. Export the diagrams as pictures (JPG or PNG) and put them somewhere like in your company Wiki. This can be done easily but you lose the structure of your model and you need to copy the structure in your Wiki which kind of unpractical.
  2. Export the whole MDZip file as a HTML (dynamic) report, which can be browsed nicely afterwards.
MagicDraw gives you an example how to do this from Maven, so you can generate the report automatically. So here are the steps:
  1. Create a Maven plugin project to run MagicDraw: You need to build a Maven Plugin project which should be used later in your main project. Copy the example from [magicdraw-install]\openapi\examples\mavenintegration\mdmvn and customize it as you need.
  2. Create a Maven report exporter project where you have your MDZip file which should be exported as HTML dynamic report. See this example from MagicDraw: [magicdraw-install]\openapi\examples\mavenintegration\execute.
To be able to run the report exporter project you need to do following:
  • Use the CommandLine class of MagicDraw to be run from the Maven plugin: 
  • Include following classpath additionally to the MagicDraw classpath:
  • Include the with following content, customize the directory and package as you need: 
 template=Web Publisher 2.0  
That's it! You are now able to run the Magic Draw project exporter automatically which creates the dynamic HTML files. Some additional ideas to make the thing more smooth:
  • Run the report exporter in your CI / Jenkins environment. You still need X server to be able to do this in Linux, so you need something like Xvnc plugin for Jenkins. Also check out this Blog:
  • You can extend the Maven exporter project and integrate Spring Boot, so you can deploy the MagicDraw HTML files as a webapp, so your users can smoothly browse it.
I would prepare some code examples in Github if you are interested in this topic, just mail me.

Have fun!

Wednesday, June 18, 2014

Why Should We Dump Java EE Standard?


I never thought that I have to write about this topic again, but I have to since a couple months ago I have to justify a decision of using Spring Framework in an enterprise environment. The decision to be made was whether we are going for Java EE or using Spring Framework. The constraint was very clear:
  • We need to support both batch and web apps.
  • For web apps we only can use an old OAS (Oracle Application Server) with Java EE 1.4.
  • Commercial support has to be available for the framework and the runtime environment.
  • We are going to update the app server for Java EE 6 or 7 soon, so it should be possible to have a smooth migration.
  • We would like to minimize the use of our home grown frameworks.
Still there was such a quarrel in the team because there are already some Java EE web apps run in OAS upgraded with JBoss Weld CDI 1.0. Normally JBoss Weld 1.0 won't run out of the box in OAS but with some patches we got it run. The problem with all those web apps is we had a lot of our own CDI extensions to fulfill enterprise features (declarative transaction management for services, caching, security) which already a part of Spring Framework a long time ago.

So it's time to google this topic "Java EE vs. Spring Framework" to see whether the dispute between them still exists.

Spring Framework Bashing 2012 and 2013

I found in Google a lot of Spring Framework bashing in years 2012 and 2013. There are some of blogs and articles saying that with the existence of Java EE - especially Java EE 7 - we don't need or should avoid Spring Framework. One of the most controversial article is this one: Why is Java EE 6 better than Spring? Luckily there are also some counter parts like this one: Java EE a tough sell for Spring framework users and this one Java EE vs Spring. Or: What is a standard?

So the topic is still hot!

Base on these discussions I need to make my own picture so let's get the two important aspects of enterprise application development: programming models and runtime environments.

Programming Models

Following enterprise application types should be supported from both stacks Java EE and Spring Framework:
  • Web apps
  • Batch apps
At last Java EE 7 supports both application types. Although the support of batch apps is still very young you should be able to define centralized business logic and can use it in both web and batch apps. The biggest problem I see with Java EE 7 so far are: 
  • Since Java EE 7 and JTA 1.2 business logic component with transaction demarcation does not need to be an EJB component  anymore. But what about asynchronous method execution? For this purpose you still need Message Driven Beans (MDB) in EJB container. So EJB is still alive. This is where Spring Framework has its advantage. Everything like business logic components with asynchronous method execution and utilities is always POJOs, no different at all and it is available today. The counterpart of MDB is MDP (Message Driven POJOs) in Spring Framework.
  • Security mechanism like authentication and authorization in Java EE 7 (JAAS) is still inflexible. If you use JAAS it is dependent on the chosen Java EE container. In contrary Spring Security is flexible and you can use it in all runtime environments available. The good news is that Spring Security can be integrated easily in Java EE 7 apps.  
  • Since Spring Batch 3.x supports Java EE 7 batch standard and this framework is the longest batch framework available in the market you maybe will use Spring Batch as your Java EE batch implementation. It is an additional complexity in case I would use Spring Batch 3.x and I need to reuse business logic components written in EJB. Do I have to run my Spring Batch app within an EJB or Java EE container? Using pure Spring Batch makes everything simpler and easier.

Runtime Environments

Application server is the platform or the runtime environment where your Java EE applications can be deployed and executed. Looking at the Java EE application servers market you will notice that following has happened last year:
So actually the platform where you can run Java EE applications is getting very few:
  • Open Source application server with commercial support and reasonable price can only be found from JBoss / Wildfly and TomEE. Also a Java EE batch app needs a Java EE container.
  • Apps based on Spring Framework can run everywhere (pure Servlet or Java EE containers like Jetty, Tomcat, VMware vFabric tc Server, now Pivotal tc Server, JBoss, Wildfly, TomEE) as long as your apps can access the implementations of services like JMS, transaction and cache. Spring Batch apps can run just within the plain Java SE.

Your Options

So in 2014 if you ever need to start an enterprise project what kind of enterprise platform will you use? If you want to write easy, secure enterprise apps (web and batch) with a single Java programming model which can be executed in many runtime environments, Spring Framework is still the one and only one choice you have.

The Problem with Java EE and My Solution: "One Runtime Environment with Standardized APIs and Simple Implementation Dependencies"

The idea to standardize some mechanisms using Java API is fine. It is good to standardize persistent mechanism with JPA, it is good to standardize dependency injection with CDI, messaging with JMS, Batch programming model with JSR-352 and others. What we don't need is the umbrella standard Java EE which puts a lot of those APIs together. Take a look at this page to see the content of Java EE. So what do we actually need?
  • We only need one runtime enviroment standard. That is what we know today with Servlet container (Tomcat, Jetty and others). This is the one and only application server or operating system we need for our enterprise applications.
  • We have all those standardization of APIs like JPA, JMS, CDI, Batch and others. The specification of those APIs should be completely loosely coupling. At the end as an end user you want to mix and match those APIs as you need them. The implementation of those APIs can be done like today through a normal framework implementation just like Hibernate (JPA), ActiveMQ (JMS), JBoss Weld (CDI), Spring Batch (Batch) and others.
That's it! No need to have those Java EE runtime environments like JBoss, Weblogic or Websphere. Of course they can still bundle all those frameworks together like what they already have done today but the most important point is actually that you can mix and match the implementations with different specification versions. Today it is impossible to do so. If you have a Java EE application server which supports Java EE 1.4 it is almost impossible to use JPA 2.1. 

Also if you have a lot of web and batch apps in production you cannot update all of them at once. Update has to be planned carefully. If you have Java EE 1.4 container in production you will stick to it in long term, since your traditional operation won't accept if you want to use different kind of containers for example Java EE 1.4 and Java EE 7 in production. If you want to move to a new Java EE 7 container you need to migrate all of your web apps at once and this is in a normal enterprise situation almost impossible. You can only update a web app within a project and you have limited resources to execute your project. So to use just a simple container and put all the implementation dependencies in the web app is the way to go. In this case you can use up-to-date APIs in some web apps. You don't need to update all the web apps just to be able to use up-to-date APIs in some new web apps. 

To conclude: the umbrella Java EE specification which contains all those APIs also makes everything more complex and makes update to a newer version of APIs very slow. 

Spring Framework supports the idea of one runtime environment and mix and match APIs since the beginning:
  • You can use any runtime environments or containers which supports Servlet specification like Tomcat, Jetty or JBoss or others.
  • You can mix and match all those standardized APIs like JPA, JMS, Batch (JSR-352), CDI (not complete but some of the specs like JSR-330 and JSR-250). 
  • To use the APIs you have to include the implementations of the API specifications by yourself using standardize dependency mechanism for Java.
  • You get a lot of nice helpers to "glue" APIs together to build a nice programming model on the top.
So the ideal situation would look like this picture below:
  • Web app: the runtime environment (Web Container) does not include all the APIs implementations. The web app needs to include the dependencies by themselves (WEB-INF/lib directory).
  • Batch app: no special runtime environment, just standard JVM. The batch app needs to include the dependencies by themselves (-classpath in Java execution parameter). 


In my opinion the enterprise development in Java has to go in the direction above:
  • Drop the umbrella standard Java EE.
  • Concentrate on one and only one runtime environment specification, the Servlet specification.
  • Concentrate on APIs standardization like JPA, JTA, JMS, CDI, Batch and others and make them loosely coupled. Let the version of the APIs to be used mixed and matched.
  • Use the standard dependency mechanism of Java to include the implementations within the web and batch apps.
  • Don't forget the Security APIs, just copy them from Spring Security analog to Batch APIs using Spring Batch.
So at the end as an end user we have one and only one runtime environment (container). The rest is just standardized APIs (JPA, JMS, CDI, Batch, Security) with their implementations (Hibernate, ActiveMQ, Spring DI, JBoss Weld, Spring Batch, Spring Security) which can be used mixed and matched as you need them. With this style you can update the version of particular specification without having to update the whole runtime environment and all the APIs in one step. A new developed app can use the up-to-date APIs and their implementations. Update of older web and batch apps can be planned carefully without the need to update all the apps at once.

At the end we chose Spring Framework. We will use all available standardized APIs with the best implementations we can get. To be able to mix and match the version of APIs in each web and batch app we will manage the dependencies within the apps itself using standardize Java mechanism.

  • 27.06.14: The term should be Java EE instead of JEE. Please see: and
  • 27.06.14: In the mean time you can follow discussions about this topic at: JavaLobby ( and TheServerSide (

Sunday, April 27, 2014

Smart Home Sweet Home with Gigaset Elements?

Last week I had a chance to try the Smart Home solution from Gigaset Elements. I read some articles about this product which said how easy to install this product for dummy users. Those articles woke my interest and I began to google products for Smart Home solutions.

In this article (German language) you will find a nice overview about some products for Smart Home, which can be bought in Germany. The Nest product from Google is still not available in Germany. Although it seems that RWE will offer Nest products in Germany in couple of months.

The installation of Gigaset Elements was really easy. The problem I encountered was to add the siren sensor. I had to push hard the button on the siren sensor at the same time with the button on the base, so that they can communicate with each other. After about one hour I managed to install everything properly.

Points to mention
Generally the idea is very nice. Gigaset Elements try to push KISS (Keep it Simple Stupid) principle. However I found some points that Gigaset Elements needs to optimize. Here are the points:
  • Reliability: The cloud was already down for two times and for almost one day each. See this facebook discussion and Gigaset Elements blog. Again, two times and within this time you are just offline! A no go situation for a cloud solution.
  • Security: Gigaset Elements web access only offers username and password to login, no Two-step Verification. It is not necessary that Gigaset Elements has to offer two-step verification with SMS (Short Messages), it would be just enough to offer this authentication method with app like Google Authenticator. It is pretty easy to integrate Google Authenticator in your own web apps. In this article you can find a lot of webapps which already support Google Authenticator.
  • Openness: Gigaset Elements should offer Open APIs (Application Programming Interfaces) for all users. Just take an example of Google+ APIs. In Gigaset Elements context they should offer both types of APIs: Inside-Out and Outside-In Integration Services and Extensions. It would be pretty useful to be able to extend the capabilities of Gigaset Elements. Something like "turn on the holiday mode in 30 minutes" or "holiday mode ends on 03rd. of Februar 2014 at 4pm". This all will be possible if there is Open APIs access to their services.
  • Freedom of Choice: Cloud and at the same time Stand-alone solution should be easily possible. At the end the web servicesweb app and mobile apps (Android and iOS) are just normal applications. I assume that Gigaset Elements uses following application architecture (see Gigaset Elements System Architecture below). There is no problem to offer all the webservices as stand-alone product. Gigaset Elements should also Open Source all of the apps (webservice, web, Android, iOS), so that a bigger community can make all the apps better. At the same time all the users can have their own choice to host their own apps and services by themselves or use the cloud installation from Gigaset Elements. Not everyone would host their own apps and services!
Gigaset Elemensts System Architecture

Facts, APIs
Looking into the webapp of Gigaset Elements you will find that it uses actual architecture with RESTful webservice and use JavaScript (AngularJS) for the front end. Following APIs calls (service calls) from the JavaScript to the RESTful services can be seen:

It is very good way that Gigaset Elements uses OpenID and OAuth to identify the user and access to the APIs. This also means that they could easily open their APIs to public because the infrastructure is already available.

Interesting is to see the access from the base into their web services. After plugging in the network cable from my laptop to my switch and use Man in the Middle software for Windows called Cain and Abel with Wireshark you can see following calls, just after you make a move in the front of your motion sensor:

Wireshark Analysis from base to router

Smart Home Sweet Home?
This is just the beginning of Smart Home solutions. Gigaset Elements with its sensors is a great KISS idea. The more sensors (video cam, smoke detector, water sensor, programmable power outlet, programmable thermostat, etc.) will be available on the market of smart home solutions the more users will be attracted to try such solutions in their houses. Can you imagine what you can do with a Gigaset Elements HD video cam which will be available in summer 2014?

One important thing for all those Smart Home vendors, also Gigaset Elements, the one which offers "Open System" will always win! So Gigaset Elements, please hear my voice and open your system, make your applications Open Source. The chance to sell millions of your sensors world wide will be better afterwards!

Monday, February 03, 2014

Nobody can save Microsoft Mobile and Tablet Devices, also not Sundar Pichai

As we heard from the news, it seems that Sundar Pichai is a hot candidate for Microsoft CEO. In my opinion it does not play any role who will become Microsoft CEO, nobody can save Microsoft with all those Windows mobile technologies. Why?
  • Windows Phones or tablets with its operating system is not a bad thing but who needs another mobile or tablet devices? We have enough offering from Apple with iOS and Android offering. I know that in the beginning everybody says "who needs another browser". At the end Google Chrome is very successful thanks to Sundar Pichai. One thing makes here a big difference: Google Chrome is an Open Source product. If Sundar can build Open Source Windows operating system, then we will see a different story. Open Source and Microsoft is just a tough story, although they offer CodePlex for hosting Open Source projects. But wait a second: Microsoft Xbox is very successful hitting Sony Playstation and Nintendo? Yes, this is just analog to Google Chrome. Xbox competes with Playstation and Nintendo on the same level, just like Google Chrome and Firefox. But Windows Mobile is completely closed and controlled by Microsoft whereas Android is open and can be used by everyone. This makes a huge difference.
  • Windows on desktop is still the one and only product which Microsoft can be proud of. Apple has done a great job taking all the developers to use Macbook but a normal user still prefers Windows. So in this area nothing will change a lot. Only all those normal users change the style of working just by using tablet instead of notebook or desktop pc and this is the challenge Microsoft will face in coming years. What can Sundar Pichai do about this? Absolute nothing.
  • The environment (workers, culture) where you work plays a huge role on the success of your product. This is a fact. Marissa Meyer was successful at Google. Take a look now how she is doing at Yahoo, not really wow. Why? Because you just have another working environment! One person can never ever save a company! So how can Sundar Pichai rescue Microsoft with its mobile strategy? He cannot, he will just look bad, just as bad as her ex collegue Marissa Meyer.
So, what Microsoft should do about their mobile strategy? Forget it, close it. You cannot be the leader of this area. It is just too late, just the same as Blackberry and Nokia. Sometimes it is wise to know and accept your weak point. Concentrate in other fields like pc operating system, office, clouds, game consoles although in some areas you will also get problems from Google, Amazon, Apple and co. One thing you could try is to join Android development and build the best Android Apps for your products.

For us developers the history already told us many times: nobody wants to use Microsoft development tools and languages for serious enterprise development. Remember the story of copying Java with Microsoft Java (Visual J#)? Or do you want to use C# or Visual Basic doing your web app?

In this sense, Google will lose Sundar as an important person, who has done a lot of great stuffs with Chrome and other Google products. But Google will surely find another intelligent person who will love to work there to make all those products better and better. Don't forget: all the talented engineers are still there and they are the most important part of Google.

Now we all know that Satya Nadella is the new CEO of Microsoft. If I were in his position I would do following things:
  • Follow Oracle's way. Oracle always supports Java since its beginning, although Oracle itself is not the creator of Java. The result of just following and embracing Java is amazing. Oracle becomes the best implementor and integrator in Java world (JRockit, JDeveloper and Java in Oracle Database to name some products). Oracle also manages to consolidate its technologies to support Java as the main path. The take over of Sun is just the logical way to continue supporting Java. Microsoft could follow this way. Support Java as the main language and runtime environment in all Windows operating system. Forget .NET, just integrate Java directly in Windows and become the best operating system for Java. Also expose all the API directly to Java world.
  • Follow Samsung's way. Samsung always support Android with Java since its beginning. Today Samsung becomes the best mobile and tablet device vendor which support Android. Microsoft could build Nokia with Android operating system and become the best Android mobile and tablet device vendor.
Doing both points will open the world of Microsoft, its Windows operating system and all those Nokia's and Xbox's devices. Everything will be based on JavaWrite Once Run Everywhere or more important: Learn Once Use Everywhere will be reality and Microsoft will get all those developers and supporters without limit to support Microsoft's New World.

In this sense, good luck to the new CEO of Microsoft Satya Nadella and don't forget that Open Systems will always win.

New Article at Developer: (Bi)Temporal Data Management in Java with Open Source Frameworks

If you ever need to handle (bi)temporal data in your Java app, check out my new article (in German language) at about: (Bi)Temporal Data, Implementation in Java with Open Source Frameworks:

Actually you always need to handle this topic in your Java business apps, a must read. All the examples can be found at Github:

Have fun!