Every architecture is formed based on certain design principles and Microservices is no different. This article will not talk about what Microservices is all about. There are already plenty of articles and blogs to do that. In this article, I will talk about what it takes to devise a Microservices based architecture. We will take a look at some of the design principles one should take into account to design a Microservices based applications.


Services must be designed to work in isolation. When you break up a monolithic system into set of services, it is necessary that these services are decoupled from one another, are made more cohesive and self sufficient. Each service should be able to handle its failure without breaking the whole application or system. Isolating and decoupling enables service to recover itself from the failure condition very quickly. The isolation characteristic of the service has the following benefits: easy adoption of continuous delivery, better scaling, effective monitoring and testability.


Isolation paves the way for autonomy. Services must be designed to be autonomous. It must be cohesive and able to fulfill its function independently. Every service can be independently invoked using a well defined API (URI). The API in a way identifies the service function. Autonomous service must also deal with its own data. More popular term is polyglot persistence where each service has its own persistence store. Autonomy also ensures resiliency. An autonomous service has the following benefits: Effective service orchestration and coordination, better scaling, communication through well defined API, faster and controlled deployment.

Single Responsibility

Service must be designed to be highly cohesive. A single responsibility principle is where the service performs only one important function. The single responsibility aspect gels well with the term ‘micro’. Micro indeed means small, fine grained and only relevant within its scope of responsibility. The single responsibility feature has the following benefits: Services composition is seamless, better scaling, reusability, extensibility and maintainability.

Bounded Context

How big or small your services should be? Million dollar question? Well the answer lies in what is called as Bounded Context design principal. It is a key pattern while devising a Domain Driven Design (DDD) modeling approach. Bounded context is all about defining a context in which your Microservices will be providing its services. It is about evaluating your domain model and identifying discrete boundaries and accordingly designing your Microservices to make it more cohesive and autonomous. That also means communication across boundaries becomes more efficient and your service in one bounded context need not be dependent on service in another bounded context for too many things.

Asynchronous Communication

While drawing discrete boundaries and designing services with its own bounded context, it is necessary that service communication across boundaries must be asynchronous. The asynchronous mode of communication naturally leads to loose coupling between services and allows for better scaling. With synchronous communication, you are blocking a call and waiting for the response. A service in a blocking state cannot perform another task until the response is received and the underlying thread is released. It leads to network congestion and impacts both latency and throughput. Asynchronous communication can also bring in the notion of implementing a well defined integration or communication pattern to achieve a logical workflow involving different services.

Location Independent

Microservices, by design, are good candidates to be deployed in a virtualized environment or docker containers. With the advent of cloud computing, we can have plethora of service instances that can take advantage of dynamic scaling environment. The services could be running on multiple nodes across small or large clusters. Services itself can be relocated depending upon the availability or efficiency of the underlying computing resource. One must be able to address or locate the service in a location independent manner. Often different lookup discovery patterns can be used to consume your service. The client or consumer of the service does not have to bother about where a particular service is deployed or configured. It just uses some kind of logical or virtual address to locate the service.

Microservices is not a technology, framework or a solution. It is an architectural style that provides you an approach or methodology to deal with the complex nature of a monolithic application. The approach starts with the above design principles that you can use to architect Microservices based application.

Reference cards (cheat sheets) collection.

The WebLogic Server 12c has very nice support for Maven now.

The doc for this is kinda hidden though, so here is a direct link http://docs.oracle.com/middleware/1212/core/MAVEN To summarize the doc, Oracle did not provide a public Maven repository manager hosting for their server artifacts. However they do now provide a tool for you to create and populate your own. You can setup either your local repository (if you are working mostly on your own in a single computer), or you may deploy them into your own internal Maven repository manager such as Archiva or Nexus.

Here I would show how the local repository is done. First step is use a maven plugin provided by WLS to populate the repository. I am using a MacOSX for this demo and my WLS is installed in $HOME/apps/wls12120. If you are on Windows, you may install it under C:/apps/wls12120.

$ cd $HOME/apps/wls12120/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.2/
$ mvn install:install-file -DpomFile=oracle-maven-sync.12.1.2.pom -Dfile=oracle-maven-sync.12.1.2.jar
$ mvn com.oracle.maven:oracle-maven-sync:push -Doracle-maven-sync.oracleHome=$HOME/apps/wls12120 -Doracle-maven-sync.testingOnly=false

The artifacts are placed under your local $HOME/.m2/repository/com/oracle. Now you may use Maven to build Java EE application with these WebLogic artifact as dependencies. Not only these are available, the push also populated some additional maven plugins that helps development more easy. For example, you can generate a template project using their archetype plugin.

$ cd $HOME
$ mvn archetype:generate \
-DarchetypeGroupId=com.oracle.weblogic.archetype \
-DarchetypeArtifactId=basic-webapp \
-DarchetypeVersion=12.1.2-0-0 \
-DgroupId=org.mycompany \
-DartifactId=my-basic-webapp-project \

Type ‘Y’ to confirm to finish. Notice that pom.xml it generated; it is using the “javax:javaee-web-api:6.0:provided” dependency. This is working because we setup the repository earlier. Now you may build it

$ cd my-basic-webapp-project
$ mvn package

After this build you should have the war file under the target directory. You may manually copy and deploy this into your WebLogic server domain. Or you may continue to configure the maven pom to do this all with maven. Here is how I do it. Edit the my-basic-webapp-project/pom.xml file and replace the weblogic-maven-plugin plugin like this:


With this change, you may deploy the webapp into WebLogic server (well, assuming you already started your “mydomain” with “myserver” server running locally. See my previous blog for instructions)

$ cd my-basic-webapp-project
$ mvn weblogic:deploy -DoracleMiddlewareHome=$HOME/apps/wls12120 -DoracleServerName=myserver -DoracleUsername=admin -DoraclePassword=admin123

After the “BUILD SUCCESS” message, you may visit the http://localhost:7001/basicWebapp URL.
Revisit the WLS doc again and you will find that they also provide other project templates (Maven calls these archetypes) for building EJB, MDB, or WebService projects. These should help you get your EE projects started quickly.

The term ‘java developer’ covers a wide range of individuals. It starts with fresh graduates looking for jobs and goes up till experienced Java Enterprise Edition developers. There are a wide range of concepts and skills that Java developers must posses in order to be important in the industry. It is highly advisable to know the language fundamentals thoroughly, rather than specific frameworks or syntax. The following websites will offer professional Java developers a storehouse of valuable information as also a platform to interact and prosper!

1.DZone - DZone

Place where community members discover and share the latest and most popular news from around the web. This community-driven page is carefully moderated by an expert editorial staff to ensure the content remains interesting and relevant.

2.LeetCode - LeetCode

LeetCode is a social platform for preparing IT technical interviews. The website provides code solution using the Online Judge system, high quality article featuring in-depth thought process and more.

3.Stackoverflow - Stackoverflow

Stack Overflow is a question and answer site for professional and enthusiast programmers. It’s 100 per cent free, no registration required.

4.Java SE Technical Documentation - Java SE Technical Documentation

Contains all documents you will need to use API of Java SE. It’s a one-stop shop for everything recent in the world of Java and it’s Oracle’s official website, so all the material here is 100 per cent geniune and update very frequently.

5.Coursera - Coursera

Coursera is an education platform that partners with top universities and organisations worldwide, to offer courses online for anyone to take, for free.

6.Java World - Java World

JavaWorld is the leading independent resource for enterprise Java technology developers, architects, and managers who want to learn more about Java and related technologies from professional developers and trusted industry experts. JavaWorld reaches the core audience of IT professionals who are planning, developing, deploying, and integrating Java-based solutions on an enterprise level.

7.Github - Github

Apart from hosting your projects for free, Github is also an excellent resource for learning popular Java libraries and frameworks with corresponding examples.

8.Program Creek - Program Creek

The website contains some very interesting articles written by people from different areas. The articles here are supported by relevant diagrams and code examples.

9.Wikipedia - Wikipedia

Our discussion will be far from over without the mention of this particular website that has been a store house of immense resources on practically any topic out there. You may just want to know some concept, but not learn much and the website will do you loads of good. Frequently updated information is available for free.

We’ve all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on “Oracle killing GlassFish”. Oracle did a decent job in nurturing the community and keeping their stuff together. I’ve written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn’t have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren’t there and nobody is consequently taking care of them … they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don’t know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn’t a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON’T have any insights here and I’m just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn’t covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can’t confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don’t having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you’ve been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn’t a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish’s turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.