Programming

The application server battle glassfish and wildfly

Writing few lines on the endless battle that I never understood. In my humble opinion, we shouldn’t stand behind the barracks of companies nor targets. Lately  I decided to leave the comfort of my cell and go public with some open projects that I follow for quite a while know. 2 major are the JBoss Application Server, currently renamed Wildfly and Mule ESB. In parallel I was always watching the Oracle side , since the acquiring of Sun it became the major vendor of the java programming language, which is the foundation of what we do. Soon I hook up in twitter with great guys like , Bruno Borges, Arun Gupta, David Blevins and other guys that promote the java technology as a full stack solution to solve everyday information systems problems.

Earlier this year Oracle decided to drop support on Oracle Glassfish Open Source Edition , and will only contribute to it as a reference implementation to the new JavaEE specifications that will be coming out from the JCP commity. This created a big fuz in our community. People started talking about the death of what used to be a very nice project and start talking about why RedHat is doing better than Oracle on that subject and that the one implementation is better on the other. Talking with guys online my only concern is not to see people behind baracks. The loss of backing up an open source from a major vendor, for me is bad. Look what is happening to the GWT project once Google decided to drop support. People tend to feel more safe when a major vendor is backing up an open source project. But I will come back to this later.

Wildfly

So to set some things straight. Wildfly is a full fledged JEE7 application server offering clustering and all these nice things you want to have in an application server when you want to use it as a deployment platform and you want to go live in production and be able to scale without tips and tricks. Also RedHat is using the majority of the code base to create the JBoss EAP version, which has a full commercial support from RedHat. Please be advised, Wildfly is an open source project, thus no commercial support is offered,but with a big BUT , is that the community is really big and sometimes you get responses from persons delving with problems in the commercial versions. Of course you don’t get patches and security fixing you would get having the commercial version. Being in the community since the 4.0 version, I have to admit that most of the times the solution is there available even if you don’t have the commercial support.

Oracle Glassfish

Here is a total different story. The code base between the commercial product, that is Weblogic Application Server, and the Oracle Glassfish is really different. Having used both , I have to admit the maturity of the interface on handling both of them is far superior compared to any product out there. Glassfish is a project that has my respect, but we don’t all like the same kind of tea. I have seen telecom systems based entirely in Glassfish and they worked perfectly. Still that clustering is something greatly missed by the open source version. That’s my only problem with it, and the tons of scepticism when Oracle took over , when I saw major evangelists leaving the company.

Reality and the Caveat

So the question after the announcement of Oracle, isn’t if the project is dead or not. The question isn’t who is better application server, but what consequences the dropping from Oracle will have for the innovation in the jee scene. Going back to my paradigm, GWT was criticised alot, but it bloomed and slowly dies in vain due to the lack of support by a major vendor. We have to be realistic, an open source not backed up by a big vendor doesn’t have as big adoption as the contrary. Also how open source community driven is the development of open source projects? That was always a big question for me and the answer was really astonishing once looking up the commits on the kernel.org. Major commiters are Intel(yes the company has an army of developers maintaining, developing and porting new stuff on the kernel)  and Microsoft..o yes. You thing that Linux would be that a big hit if it only relied on the community. For me community will bring to surface a really cool idea and will help it to bloom the first days. But in order to be accepted and be used in production and not from technology enthusiasts, the hard reality says that you need a big vendor backing things up.

Working in the private sector and doing stuff not as cool as my night projects, I have to admit that the serious problem I see, is that when a company has in it’s payroll people working on an open source project, it gives the opportunity to several people to put to the test their creativity and come up with beautiful and imaginary solutions, which in any other case you couldn’t. After working for 10 – 12 hours being creative late at night isn’t that cool. Struggling myself on where my heart belongs, I can see the problem clear. It would be more fun to work on an open source project and being paid by a big vendor, so that I can pay my bills. This opportunity is offered once you have someone big backing up your open source project.

The debate shouldn’t be who is better. It’s company decides it’s strategy based on it’s internal needs and ambitions. My thought is that we should bring more big vendors backing up really cool open source projects, allowing creative people to work on them and excel. That’s the major problem I see from the drop of support from Oracle’s side. So bundle up guys and start working on open source projects another hand is always welcome.

regards

\n\m

Advertisements
Programming

A full SMS Environment using Mule ESB and SMPPSim(Step 1-Configuration)

Introduction

After spending time trying to figure out how to use services like Clickatell,Twilo etc.So I decided that is better to use mule to emulate a scenario of a typical SMSC service that communicates with several other services for distributing messages to end clients. The other services can spawn from simple reading from a queue using MuleESB and forwarding the payload of the message as an SMS to an end user using a custom smpp connector which is defined using the mule dev kit. If you have to many unknown words be patient and everything will be explained later on.But let’s kick start with what you will be needing.The list isn’t exclusive but refers to tools of my choice and isn’t limited by them.Frameworks and tools providing the same functionality can be used but is up to you to configure them. My “lab” consists of:

Laboratory configuration

Wildfly 8.0.0 Final as  Application Server

As always a JBoss fun the new 7.1.1 version coded dname Brontes(after the greek word Βροντες which imply the sounds you hear in the atmosphere before the rain) or the latest javaee7 compatible appserver by JBoss named Wildfly. We will use the JMS module of the application server. We need to define a queue in which we will be injecting our payload to be route.To do so, open we will use the standalone full configuration of the application server. So we go in our $JBOSS_HOME/standalone/configuration/ and edit the file stanalone-full.xml. Find the lines of the jms destination definition and add the following lines:

<jms-queue name="HighInOne">
<entry name="queue/HighInOne"/>
<entry name="java:jboss/exported/jms/queue/HighInOne"/>
</jms-queue

This will create the necessary queue, where Mule will reroute messages. This can allso be created by using also the jboss-cli.sh found in the bin/ folder of your application server. After you have setup the queue fire app the application server with the following command : ./standalone –server-config=standalone-full.xml -b 0.0.0.0

Fire up your favourite browser and point to localhost:8080 and voila, the magic is there. A small tip is for accessing the console you need to create the necessary users by utilizing the ./add-user.sh script in the /bin/ folder of your application server. This finishes the necessary part of the application server.

Mule ESB 3.4.0 – ESB deployment platform

Few years now my ESB of choice is Mule ESB. The reason really straightforward: Easy of use. Taming the Mule can be really easy my using a mule-config.xml file in a folder under the apps/ directory. Here we will use it, deploy also Camel. Thus copy the necessary camel jars under the $MULE_HOME/lib/user and you are done. Go to $MULE_HOME/bin/mule.sh and fire up mule and there you are done.

SMPPSim – smslib

The first one is an smpp gateway simulator. The configuration rather straightforward.Unzip and run. Some configuration if you want to handle difference users and level of security.But simply unzip and fire it up. As a replacement these days I use an SMPP implmenentation by Twitter which uses the new Netty NIO and is lightning fast called cloudhopper. Take under consideration that I prefer building the jsmpp library that the library has as dependency because the one provided by the maven repositories are corrupted. So build and enjoy

These tools will be the base working stuff of our lab. In the next step we will define specific configuration so that we can use them send messages around.