Platform Strategy: From Portlets to OpenSocial Gadgets to Progressive Web Apps: State of the Art

Introduction

As the world was still at Java's hand we often define what so called a component-based platform. I had this experience in the year 2000 with OpenUSS (Open University Support System). At that time I had an idea to develop a platform which is extendable using component architecture and J2EE technology (OpenUSS Component Architecture). After a while we saw the birth of portal and portlet technology. Everyone tried to build portlets which can be easily installed in a portal server, all Java based. Do you remember all those portals like Apache Jetspeed, Liferay, JBoss Portal, IBM Webshepe Portal, etc?

After the portal wave there was OpenSocial gadget which is not only specified for Java but generally available for different technology implementations. It uses HTML, JavaScript and REST completely independent from Java. Apache Shindig was an Open Source implementation for OpenSocial gadgets container. OpenSocial gadget was also the main technology for iGoogle, Orkut, MySpace, XING and StudiVZ. With OpenSocial you can integrate web apps in two different ways.

Today you still have those technologies like Portal, Portlet and OpenSocial gadgets but they are not very compelling any longer. iGoogle is dead and nobody wants to use portal and portlet technology in their new web apps. All important web apps today don't use those portals, portlets and gadgets anymore. The growth of these technologies is definitely going down to zero.

Platform

Generally a Platform consists nowadays of two elements:

• Web App for web browsers: this is today still the most used application. Laptops, desktops, tablets and smart phones users use this type of application.
• Native App for tablets, smart phones and wearables: only in a few cases you still need native apps for desktops and laptops as webapps are getting better everyday for this use case. The most targeted platforms for smart phones, tablets and wearables today are Android and iOS.

Let's take a look at both elements in detail.

Web Apps

As mentioned above we don't need those portals, portlets and gadgets anymore. Do we still in search for a component-based platform? Do we still need following requirements which were mostly answered by using portal, portlets and gadgets?

• Aggregate content and applications
• Integrate across applications
• Provide a unified user interface
• Support a unified web application development platform
• Personalize content and services
• Deploy a framework for publishing dynamic pages

The answer is yes but the main emphasis moves to different areas. The new trend in web app development is the so called Progressive Web Apps (PWA). Today is more important to concentrate on the user experience instead of the web app itself. Following are the definition of Progressive Web Apps (taken from Google Developers Code Lab):

• Progressive - Works for every user, regardless of browser choice.    
• Responsive - Fits any form factor: desktop, mobile and tablet.
• Connectivity independent - Enhanced with service workers to work offline or on low-quality networks.
• Native App-like - Feels like an app to the user with app-style interactions and navigation.
• Fresh - Always up-to-date thanks to the service worker update process.
• Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
• Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search engines to find it.
• Re-engageable - Makes re-engagement easy through features like push notifications.
• Installable - Allows users to "keep" apps they find most useful on their home screen without the hassle of an app store.
• Linkable - Easily share via URL, does not require complex installation.

So the main emphasis was moving from:

• Portals, portlets and gadgets which were defined to make the life of companies (which delivered the portals, portlets, gadgets) and developers (which write the portals, portlets, gadgets) easier to
• Progressive Web Apps which make users happy.  

This does not mean that with a progressive web app we cannot deliver the requirements above. Let's take a look at all the requirement points in detail. 

(1) Aggregate content and applications and integrate across applications
With Progressive Web Apps this looks different. You won't have such an integration using portlets. Instead it will be an integration of many web apps using the same toolbar and each web app is working just like a standalone application. Here is a comparison.

Portal and Portlets Integration: netvibes with Portal and Portlets

In a Portal and Portlet integration each portlets can be maximized as a separate web app.

Progressive Web Apps Integration with Google Web Apps: Google+, Inbox, Search, etc.

In a Progressive Web Apps integration each icon defines a web app and it will be opened separately as a standalone web app to follow the rule of Native App-like.

I was a happy user of iGoogle (OpenSocial Gadgets solution from Google), before Google turned it off. In the beginning I thougt that I need to search for an alternative just like netvibes. At the end I don't miss it at all. If I need to get the information I mostly need it in a full screen mode. So at the end I always need the web app in a whole and not only in a small portlet.

(2) Provide a unified user interface
Both types can support a unified user interface. Progressive Web Apps use common UI model like Google Material Design or Bootstrap. Portal, Portlets and Gadgets have mostly a mechanism to use the skins within the Portal Container.

(3) Support a unified web application development platform
This is where Progressive Web Apps play their strength. As long as the web app uses HTML, JavaScript, CSS and REST it can be implemented in different technology stacks like Java, PHP, JavaScript and many more. Since you don't have any "Portal Container" in such a Progressive Web App, you can vertically use your chosen technology stack. Whereas Portal and Portlets deployment is based on a Portal Container. So if you use Tomcat as a container you will have to deploy your portlet inside that Container. Surely you can make a remote service call but it is not the standard case.

(4) Personalize content and services
This is where Portlet shows its strong character. You can turn off and on the portlets for your needs. If you see the Google toolbar above you can also personalized the content. So in this case the Progressive Web App can do the same thing with individual design of its web app. 

(5) Deploy a framework for publishing dynamic pages
This is also possible with both types and the trend goes to Microservice.

As a summary you can still fulfill the above requirements using Progressive Web Apps. Additionally you can build component-based web apps by using the standard Web Components. Some real world use cases for Progressive Web Apps can be seen here:

• Flipkart: Progressive Web Apps at Flipkart
• Air Berlin: Progressive Web Apps at Air Berlin

Native Apps

A platform strategy without taking care of the most used clients (mobile phones and tablets) is simple a failure. Here are the types of the client devices today with their operating systems:

• Desktops and laptops with Windows, Linux and MacOS: in most cases you just need a web browser (Firefox, Internet Explorer, Edge, Chrome and Safari) with the web apps. There is no need to build native apps for each operating systems, just go for Progressive Web Apps. Here are some facts:
• Google stops the development of Picasa client app and moves everything to the web with Google Photos.
• Integrated Development Environment (IDE) like Eclipse would be the one thing that should be natively implemented to run on clients on the top of the operating systems. But this model will also change in the future since Eclipse is beginning using web app as its future IDE: Eclipse Che - Cloud IDE.
• Tablets with Android and iOS: at the moment you need to build native apps for Android and iOS. But in many cases the web apps with Progressive Web Apps could be the solution since web apps can do almost the same thing as the native apps, especially with the arrival of HTML5.
• Mobile phones with Android and iOS: as in the tablets area at the moment you need to build native apps for Android and iOS. Because of the screen size it is likely that we need to develop the native apps. But the Progressive Web Apps are doing better everyday (see the picture below and both examples above with Flipkart and Air Berlin).
• Wearables, gadgets, cars and TV with Android Wear, Android Auto, Android TV, watchOS, Apple CarPlay and tvOS: this is the area where you have to write native apps since the smaller devices won't be able to run a web browser.

Progressive Web Apps with Material Design

Implementation Technology with Java

Developing apps for different target systems is expensive. The idea of Progressive Web Apps is great since it saves you writing native apps for each operating system. But still in some cases - at least at the moment - we need to build native apps. For this purpose and to save ressources there is the so called Hybrid Application Development. There are a lot of Hybrid Application Framework with HTML User Interface out there. The problem with this technique is that the HTML UI does not feel really native. Therefore there is a second type of Hybrid Application the so called Hybrid Application Framework with Native UI. In this case you still use the native UI in each operating system and use e.g. the same programming language to cover the rest. As Java is still the number one programming language it is wise to based your platform strategy on Java.

The graphic below shows a comparison between Progressive Web Apps, Hybrid Applications with HTML UI and Native UI in runtime.

Comparison Progressive Web Apps -  Hybrid Apps with HTML UI - Hybrid Apps wirh Native UI

What kind of tools and products does Java offer us to implement the technology above?

(1) Foundation

• Spring Boot and Spring Cloud for the Microservice Architecture. These Open Source products are really mature, production ready and easy to use.
  

(2) Web Apps based on Progressive Web Apps

• For this type of web apps you don't have a lot of alternatives in Java area. Framework like JSF or Grails is not real capable of implementing this feature, since you need JavaScript which has to run on the browser side. Using pure Java instead of adding complexity in JavaScript with frameworks like AngularJS could be a plus. For this purpose you can choose following products:
• GWT - This is still the best Java to JavaScript Open Source transpiler.
• jsweet - A transpiler from Java to TypeScript/JavaScript. jsweet has a different mechanisms of transformation the Java codes to JavaScript from GWT since jsweet uses its own Java libraries to manage the transformation.
• ST-JS (Strongly Typed JavaScript) - A transpiler from Java to JavaScript, quite similar to jsweet.
• TeaVM: A transpiler from Java bytecode to JavaScript.
• DukeScript: A framework to create JavaScript application based on Java. Generally DukeScript can talk directly from Java to the JavaScript code.
• DoppioJVM: A Java Virtual Machine written in 100% JavaScript. The idea is to run Java apps in the browser with this virtual machine.
• Java2Script Bridge RCP to RIA: A converter of Eclipse SWT to JavaScript.
• GWT is the most mature product in this category and Google uses GWT in a lot of their products. GWT can be integrated with following UI frameworks: 
• Bootstrap (GWTBootstrap3), 
• Material Design (GWT Material Design),  
• Material Design with Polymer. 
• The future version of GWT also can work with Angular 2 (Angular2Boot).
• There is a collection of best practices how to use GWT to implement Progressive Web Apps.So you can write Progressive Web Apps today completely in Java with GWT.

(3) Native Apps with HTML UI

• Using mGWT and mGWT PhoneGap with skins of Android and iOS: With the same technology Java, GWT and PhoneGap / Apache Cordova you can write a native app with HTML UI. Instead of using this technology you maybe should use Progressive Web Apps technology since HTML UI does not look native anyway. Progressive Web App is just the same and you can write it once for web and mobile.

(4) Native Apps with Native UI

• In Android you can implement the native UI just using Java, no special workaround needed.
• In iOS you need to use Objective-C to implement the native UI. Using Open Source product like J2ObjC (Java to Objective-C transpiler) will help a lot to reuse the Java codes
• Product like Google Inbox use GWT and J2ObjC to deliver the same functionalities across operating systems (Web, Android and iOS) on the same time.
  

Platform Strategy

So how can we define our platform strategy today? Following points are my summary:

(1) Foundation

• If you use Java as your programming language leverage Spring Boot and Spring Clouds for your Microservice archtiecture implementation. But at the end you can use different implementation technologies like Java, .NET and others. It is just important to use the standards in the next point.

(2) Server-side and Business Logic

• Use RESTful and JSON for the communication between the mircoservices.
• Authentication and Single Sign On with OpenId Connect and OAuth 2 is a must in this platform strategy so that you are able to integrate all the microservices with all different implementation technologies.

(3) User Interface

• Portal and Portlets are dead. Use Progressive Web Apps for any possible apps. If you need to integrate many Progressive Web Apps just use an integration or tool bar just like what Google did with its products (see the Google+ picture above).
• If you need Native Apps build them with Hybrid Application Framework with Native UI not HTML UI.
• Open Source products to make your life easier for building Progressive Web Apps and Native Apps with Native UI in Java are following: GWT and J2ObjC. Consider them for better productivity and time to market.

A platform strategy today does not need to be based every single implementation on the same language, still if you have a small team emphasis on the same language and Java is still the top programming language available. The next picture at the end of this article shows state of the art implementation technologies for a technical platform based on Java.

Implementation Technologies for a Platform based on Java

Programming Introduction for Primary School with ScratchJr, Pico Projector and Google Chromecast

Invitation

I was lucky that my daughter asked me whether I would answer all the questions of her classmates - most of them are nine years old - about my profession. They had "professions" as the topic of their general knowledge lesson. So my daughter told me that they invited teacher, school caretaker, stewardess, nurse and also me software developer. Her classmates and she would ask the invited person some questions. I directly said yes because I think that the new generation needs to be introduced in software stuff especially that the current professions will change a lot in the near future. Reuters had a very interesting article about how Robots and Artificial Intellegence will cost five millions jobs by 2020. In my opinion software development will be much more important by 2020, so this is my chance to introduce my profession to the kids in my daughter's class.

Preparation

In my preparation I thought that I need to show them something cool so I began to google and found this piece of IDE (Integrated Development Environment). Scratch is a great IDE for doing graphical programming language. With Scratch you can show your kids how to write a program in a simple manner. You also can find a tablet version called ScratchJr.

 

I myself really had a fun with this IDE. Now I need two things to be able to run my introduction.

(1) Content of my presentation: I need to prepare my presentation so that all the kids will understand me. For this purpose I'm lucky to have my wife as a primary school teacher. So I asked her how I could show them Scratch in an easy manner so they understand what software developer is doing the whole day. She told me that I have to involve them and create something cool. I also need to think about what are the requirements to become a good software developer. We took a look at Scratch and I should involve them in some these things:

• I will choose the standard "cat" figure and do some movements with it.
• One of the kids should choose how many steps the cat should walk to the left or to the right.
• They also should record the cat sound alltogether.
• They should choose the second character. 
• Then the second character should walk and meet the cat somewhere and says "hello cat".

 Afterwards we declare what the requirements are to become a good software developer:

• Math is a must.
• Art and creativity are good foundation.
• Endurance will help a lot.

That's it! Now I need to go to the next preparation point.  

(2) Technical possibilities in the classroom: to be able to show ScratchJr and programming in the classroom I need to prepare some technical things. It is a pitty that in the classroom there is no projector so I need to bring all the things by myself. Generally speaking, computer equipments (tablets, internet and projector) in primary schools in Germany look really horrible. In 2014 only six percent of primary schools in Germany has a tablet equipment in their classroom. Following gadgets will help me a lot:

• An Android tablet with WiFi where I could install ScratchJr.
• A small projector something like Aiptek Pico Projector.
• A Google Chromecast: this is an important part so that I can connect from my tablet wirelessly to my small projector, no need to use HDMI cable. My Samsung tablet does not have a HDMI and neither a MHL (Mobile High-Definition Link) connector.
• An Android mobile phone with internet access, so that the tablet and the Chromecast stick can find each other.
• A power bank to supply the power for Chromecast and the Pico projector as I know that it would be impossible to get a power supply in the classroom.

Here is how my technical setup looks like:

I need to re-initialize the Google Chromecast to find the WiFi from my mobile phone but that was quite easy and just in a short time I could mirror my tablet screen with ScratchJr through Google Chromecast to my Pico projector. So I can use my tablet without any cable! Amazing, very easy and I really did not expect this.

One thing I recognize: I need to have a good internet connection from my mobile phone since Google Chromecast needs an internet connection.

At the end of the day I'm prepared with the content and the gadgets so I was really looking forward to show this to my daughter's class.

Execution

At the D-Day I was well prepared, every single gadgets was fully charged, as I know, without power supply I need to be secure that all the gadgets can work independently from the power supply. I also need to put my mobile in the near of the classroom's window to get a good internet connection. I also need helps from the kids to get some books to put the projector on the top of them, so that it can show the ScratchJr user interface just in the middle of their blackboard.

After showing them the ScratchJr and let them decide some things as I planned above, I got an interview round, so they could ask me all their questions about the profession as a software developer. Here are some questions:

• How long do you need to study to be able to execute your profession?
• In what age did you start programming?
• Why do you like your profession?
• What characteristics are important to do your profession?
• Can I use iPad to play with ScratchJr?
• I like to play games, do you know someone who also develops games?
• Could you please tell the developers of Minecraft to solve some of my problems?

I had a lot of fun showing ScratchJr and answering all the questions for about 45 minutes.

End of Story

At the end, I think, I managed to excite the kids to see how easy graphical programming could be. ScratchJr or Scratch is the best IDE I found sofar for this purpose. It is quite similar to Android App Inventor which is designed for Android application development with graphical programming language. Google Chromecast and Pico projector help me a lot to tackle the infrastructure in the classroom. Without a demonstration with ScratchJr I won't be able to explain what a software developer is actually doing the whole day. At the end of this story I want to encourage all fathers and mothers who are software developers to show your children and their classmates that writing software is really cool! As Marc Andreessen said "software is eating the world", so we need more intelligent software developers!

Enterprise Applications Customization with Microservice

Introduction

Today in highly paced enterprise environment you, as the leader of enterprise IT division, need to be fast. Simplicity is the key for the speed. What are the key factors to simplify your IT? Three different areas are very important to take care of: Technology, Organisation and Environment (TOE Framework: http://goo.gl/tQlX5z). Here are some detail points for technology and organisation:

1. Technology: in most enterprises there are already one or more ERP and CRM solutions the so called Enterprise Applications. We need to manage them carefully as they support the business processes. In context of the core compentencies most enterprises customize the enterprise applications to fit their needs. We need to manage the customizations in detail as they represent the core competencies and at the same time the differentiation of our enterprise to other competitors.

2. Organisation: working in a small team with different roles and functions is already proved as the best way today. Scrum or small cross-functional agile team - organised around business capabilities - for one domain e.g. Order Management with its own product manager or product owner, business analysts, IT architect, developers, testers and operation people can work more concentrate and deliver the best result for the business. This type of product organisation is the key to the Microservice Architecture (http://goo.gl/wglXLp). A product organisation does not imply that there is no need for an IT division in the enterprise anymore. IT division is becoming more important in this context since e.g. all the developers spread around the product organisations need to exchange their experiences and learn from each other. Sometimes they also want to move from one product to another product. Also development processes like model and source code versioning, continuous integration and deployment should be centralised so that not each product organisation will have to build its own process. An IT division within the enterprise can be seen as the "home sweet home" of IT architects, business analysts, developers, testers and operators. As we know having a strong home is the base of strong, successfull and brave children.

In this article we will look into the detail of the customization and its relationship to the Microservice Architecture which represents the technology point above.

Enterprise Applications Customization and Integration with Microservice Architecture

Every enterprise needs individual software, no matter how good your standard software are. In many business domains like human resources, accounting and customer relationship standard software like ERP and CRM already offer best practices in business entities, services and processes. Using them are mostly enough since the key processes are similar all over the enterprises. Some of the components are different but only in the configuration of how the processes should be executed. Most of enterprise applications (ERP, CRM, CMS and DMS) offer customization by configuration for this purpose.

Before going any further we should define how customizations can be done. Each enterprise application has it own definition of what customization is. In e.g. SAP ERP customization means actually what we know as configuration. Here are my categories of customization:

A. Customization by Configuration: in this case we can use the internal function of the application to change the character of the application. Example:

• If you use JIRA you can define new fields of an issue as you need it without programming. 
• If you are using SAP ERP you use the Implementation Management Guide (IMG) to configure the processes in SAP.
• If you are using Oracle E-Business Suite ERP you can use personalization to personalize your page.

In this customization type there are no problems if you upgrade your ERP installation because it uses the internal functions of the ERP.

B. Customization by Modification: in this case we make modification of the components within the ERP. To be able to modify we need to have the source code of the components. This customization type is in general not advisable because it will make the upgrade process complex and impossible. It is preferable to use the next customization type.

C. Customization by Extension: in this case we extend the functionality by creating a new component. Some enterprise applications offer the concept of plugins and exit points. In general an extension needs an integration point for example at UI (User Interface) layer, Business Logic and Entities layer and Data layer.

Back to the individual software, in other domains like Order Management the situation looks different. The order entities are very different in each domains. For example SSL certificates order entity has different characteristics than an order for shoes or an order for collecting waste. Also the order process looks quite different. The customization process is in general more complex and Customization by Configuration is mostly not enough. In this situation there are two alternatives as follows.

1. Customization by Extension using the standard mechanism from the ERP software.

Customization by Configuration is mostly not possible in this situation or at least not completely possible. Using the same technologies from the ERP software we can extend or modify the ERP software. This kind of extension is a tightly coupled integration with the ERP software. The deployment would be also done in the same container as the ERP software. Although this type of deployment is for Oracle E-Business Suite not adivisable (https://goo.gl/AJKbHh). If your IT division has no competence in software development this alternative would be mostly done by the company which introduces the ERP software. Figure 1 shows the architecture of this solution using Oracle E-Business Suite as an example. In this figure we can see an extension of iSupplier Portal (https://goo.gl/KWz7Pq) with a simple File Upload feature (File Upload Webapp) using Oracle Application Framework (OAF) (https://goo.gl/me4kT6).

 Figure 1: tightly coupled integration Monolith Architecture of extension

Pros:

• The extension is integrated and tightly coupled within the ERP software. Especially in the UI (User Interface) area this is a huge advantage.
• There are good integrated customization tools within the ERP software. In Oracle E-Business Suite you have the so called Customization Manager: http://goo.gl/qtoBFc. In SAP there is the Transport Management System: http://goo.gl/1sG6Jb. 
• You don't need to take care of single-sign-on and security since the webapp is running within the context of E-Business Suite.
• In the beginning it is easier to handle one big "monolith", all in one place solution, as the First Law of Distributed Object Design says: don't distribute your objects (http://goo.gl/DFnUpG).
  

Cons:

• It uses the technologies of the ERP software and this depends on the vendor of the ERP software. This means higher license cost, high dependency to the vendor, restricted resource to find for the compentence in the vendor know how. In the time that Open Source Software is already mature you are stuck with the vendor solution. Also with new findings like Microservice Architecture you will have to stick with the monolith solution from your ERP vendor. 
• In some ERP software like Oracle E-Business Suite you still need to handle all the software development process on your own like versioning, continuous integration and deployment.
• Deployment in Oracle E-Business Suite shown in Figure 1 is not advisable. You can deploy the File Upload Webapp in an external OC4J similar what this article mentioned (https://goo.gl/AJKbHh). The problem with this approach is that we need to take care of the security and single-sign-on just like the next solution. 
• Until certain point you are in a heavy weight situtation through the monolith architecture. It is difficult to extend and to rework, because you need to test everything in the monolith. You sacrifice flexibility and speed.

The difficulties of updating the ERP software because of the Customization by Extension or Modification cannot be seen as disadvantage since this type of customization always implies the same problem. All the extensions should be retested with the new version of the ERP software. This is just a simple problem as we already know everywhere in software. As a Java developer we know that before we upgrade e.g. our Eclipse IDE we should know whether all our plugins are still working with the newer version of Eclipse.

2. Customization by Extension using external standard and Open Source technologies. 

This solution is loosely coupled integration to the ERP software. We don't need to use the technologies of the ERP vendor and can use the Open Source technologies available. Using the state-of-the-art architecure like Microservice Architecture is also directly possible. The deployment would also be done somewhere else and not in the container of the ERP software (see Figure 2).

Figure 2: loosely coupled integration Microservice Architecture of extension

Pros:

• No tight dependency to the ERP vendor technologies. We can use the resources of our own and build the extension with internal knowledge. Flexibility and speed is the key in this case.
• We can use general best practices and new architectural solutions without waiting until the ERP vendor introduces it.
• Thinking of your extension as a simple service (== Microservice) would decompose the complexity of your applications. This means that we can develop the extensions much more simple and get finished faster (http://goo.gl/Z9PyFE).
• As we still need to handle all the software development process by our own we can use already established internal mechanism. 

Cons:

• We still need an expert who knows the integration point to the used ERP software. Because at some point we need to integrate our solution into the ERP software (UI, business logic and entities or data layer).
• At the UI level this solution could look really different. This could be positive or negative for your user. For Oracle E-Business Suite 12.1.x users with an old Oracle forms look&feel a good looking state-of-the-art UI like Bootstrap has surely positive impact to the users.
• We need to take care of the security and single-sign-on, to be able to have a smooth integration with the Oracle E-Business Suite.

In this alternative we can introduce Microservice Architecture. Each extensions can be grouped as Microservice and mapped to the right product organisation. How we implement the Microservice depends on the available know how. For the organisation with modelling knowledge using BPMN, UML and Open Source products like Camunda and KissMDA could be very compelling to implement the Microservices. The typical advantages of Model Driven Development can be read here: https://goo.gl/CbvWb1.

Some interesting discussions about Microservices and BPMN Integration Platform can be found here:

• Microservices and the Integration Platform: https://goo.gl/4qQuYG 
• Orchestration using BPMN and Microservices - Good or bad Practice?: http://goo.gl/CLHq43 
• German language: Wie lässt sich Ordnung in einen Haufen (Micro-)Services bringen?: https://goo.gl/ibbxym 
• German language: Wer Microservices richtig macht, braucht keine Workflow Engine und kein BPMN: https://goo.gl/NJQgbs 

Using Java and Open Source frameworks like Spring Framework and NetFlix OSS - all together bundled in Spring Cloud - for building Microservice is definitely a standard way for enterprise computing today (http://goo.gl/l5zvWD).

Summary

The customization of your enterprise applications like ERP or CRM software by extension should be managed carefully. Under the condition that the knowledge is available in the enterprise using external and Open Source technologies are the best way for simplicity and speed. You can exploit the advantages of Microservice Architecture now, without waiting too long for the vendors to come up with the same solution. Your customization by extension is also independent of the vendor's technologies. If you don't have the know how, search for it and find it. Don't let the vendor lock your extensions in their technology:

• If you are using Oracle E-Business Suite, don't implement everything in Oracle Application Framework. Try to integrate Open Source frameworks and solutions to build your own Microservice Architecture.
• If you are using SAP, don't implement everything in SAP Java technologies e.g. Web Dynpro and SAPUI5 within Netweaver. Also try to use Open Source frameworks and Microservice Architecture.

One aspect you should not forget is the domain and the ERP integration know how which you need to solve first, but for us as IT leader, this is just business as usual.

Platform as a Service: What Should We Choose?

Today if you want to deploy your webapp or webservice you first think to do this in the cloud by using PaaS (Platform as a Service). The problem is you have many alternatives in this area:

- Microsoft Azure: http://azure.microsoft.com
- Google AppEngine: https://cloud.google.com/appengine
- Amazon AWS (Elastic Beanstalk): http://aws.amazon.com/elasticbeanstalk
- Heroku (from salesforce): https://www.heroku.com
- OpenShift (RedHat): https://developers.openshift.com
- CloudFoundry (Pivotal): https://run.pivotal.io

The problem: what PaaS should you choose? This presentation helps a bit: http://goo.gl/dGnpGP

BTW.: if you want to run Docker, AWS Elastic Beanstalk is the easiest way to do: http://goo.gl/mtMk5J 

It would be nice to hear your opinions!

Cheers,
Lofi

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: 

 <mdmvn.mainClass>com.nomagic.magicdraw.magicreport.CommandLine</mdmvn.mainClass>   

• Include following classpath additionally to the MagicDraw classpath:

 <mdmvn.classpath>plugins/com.nomagic.magicdraw.codeengineering/codeengineering.jar:plugins/com.nomagic.magicdraw.codeengineering/codeengineering_api.jar:plugins/com.nomagic.magicdraw.codeengineering/lib/antlr_2.7.6.1.jar:lib/y.jar:plugins/com.nomagic.magicdraw.diagramtable/diagramtable.jar:plugins/com.nomagic.magicdraw.diagramtable/diagramtable_api.jar:plugins/com.nomagic.magicdraw.reportwizard/reportwizard.jar:plugins/com.nomagic.magicdraw.reportwizard/reportwizard_api.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/avalon-logkit-2.1.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/commons-beanutils-1.7.0.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/commons-collections-3.2.1.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/commons-lang-2.4.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/commons-logging-1.1.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/commons-net-ftp-2.0.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/jsch-0.1.40.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/log4j-1.2.14.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/magicreport.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/oro-2.0.8.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/stax2-api-3.0.1.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/velocity-1.6.2.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/velocity-tools-generic-1.4.jar:plugins/com.nomagic.magicdraw.reportwizard/lib/woodstox-core-asl-4.0.7.jar</mdmvn.classpath>  

• Include the mdreport.properties with following content, customize the directory and package as you need: 

 project=D:\\projects\\project-exporter\\src\\main\\resources\\model\\project.mdzip  
 output=D:\\output\\project-report\\report.html  
 template=Web Publisher 2.0  
 package=Analysis;Architecture;Implementation  
 report=Built-in  
 recursive=true  

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: http://goo.gl/0LW3bK.
• 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!
Lofi

Why Should We Dump Java EE Standard?

Prologue

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:

• 2013 Oracle pulled out OSS Java EE server Glassfish's commercial support. 
• OSS Java EE server Apache Geronimo is going nowhere, because IBM pulled out the commercial support for Geronimo.

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). 

Epilogue

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.


Updates: 

• 27.06.14: The term should be Java EE instead of JEE. Please see: http://goo.gl/8xfMsJ and http://goo.gl/NnCHy4
• 27.06.14: In the mean time you can follow discussions about this topic at: JavaLobby (http://goo.gl/KmqeWm) and TheServerSide (http://goo.gl/oQmWRG)

Smart Home Sweet Home with Gigaset Elements?

Introduction
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 services, web 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:

https://api.gigaset-elements.de/api/v1/me/events?limit=25
https://im.gigaset-elements.de/identity/api/v1/user/info

https://im.gigaset-elements.de/identity/api/v1/openid/provider/?openid.return_to=...
https://api.gigaset-elements.de/api/v1/auth/openid/checkauth?gigaset.return_to=...

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:

https://api-bs.gigaset-elements.de/...

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!