Just a quick note… PWS are conducting PostgreSQL Administration training (official training) on 26th-28th July 2011. The course includes hands-on and is a preparation for the PostgreSQL Associate Certification exam (includes voucher etc.). The details and registration landing pad can be found here: PostgreSQL Administration
To quote a line from a famous film …
“I love the smell of napalm in the morning” (Apocalypse Now).
To me those pearl handled pistols characterize Larry’s attitude toward all things great and small. We are kind of lucky that he doesn’t own any really critical infrastructure (like water or sewage). There is hardly a business partner in the world that remains unscathed by Oracle’s all or nothing attitude. So where does that leave our dear old friends Hewlett Packard? (… I can just imagine Bill and Dave turning in their graves RIP).
I am not a big fan or Itanium personally and I never have been but interestingly Intel as well as HP have never backed away from it and if we all remember, HP made a huge commitment to that platform when they announced that Itanium will replace their PA RISC architecture servers a few years back. Fact is that Intel remains committed to Itanium beside HP along with Huawei and Inspur announcing that they will also start producing Itanium based servers.
So therein lies the pivotal question… why would Larry want to leave this party?
If I had to meet HP to discuss this (unapologetically) on Oracle’s behalf then I could put it to HP that Itanium remains a smallish server platform by sales volume and that the Unix server market is kind of flagging and being slowly replaced by Lintel (Linux x86). This is a phenomenon that is in part to do with the fact that the relative power of x86 based systems has increased substantially with 64bit systems emerging at an unbeatable price point. Still feeling unapologetic…
In actual fact for the database world the current market situation for Unix servers is partially to do with Oracle themselves and their continuous evangelic marketing around Linux x86… (then they go and buy a Unix vendor! … work that one out).
I remember working with Oracle a few years back when they ramped up the Linux x86 marketing engine. Back then I was heading up pre-sales for Oracle in South Asia. During the 9i and 10g campaigns you could hardly hear anything but Unbreakable Linux being shouted from the podium. I also shouted it quite a few times myself on their behalf.
The years pass… and after a long hard endless winter in the business world you would have to be blind, dumb or both not to realize that a lot of your hard earned cash is being wasted on IT systems with a good portion of it now landing in Larry’s bank account. Many companies and people have awaken and started down the path of financial and functional enlightenment toward open source adoption. Obviously this trend is yet to completely change the landscape of IT vendor revenue but the vendors are definitely preparing for an inevitable tsunami. That is what cloud computing is designed to help them with (anyway… drifting a little off topic).
After spending 7.4 billion on Sun Microsystems (probably not just a favor to bail out Scott) I guess Larry may have suddenly realized that monetizing Java may not really be quite that easy after all (other than suing Google over Android… which gets some of his cash back). I get the distinct feeling that Larry thinks he needs to shift a bit of industry momentum back to Sun servers and try to polarize the database end of the whole server market with IBM (as well as taking HP down a few notches). Now that does sound more than just a little anti-competitive… I can just imagine every sales deal that they walk up to now starting to sound more like their friends at IBM used to sound (… hardware, software, services… and err… hardware).
So in summary… given the current server market situation, whipping the mat out from underneath HP’s feet seems like the logical path for Larry and is also consistent with the way in which our friends from Redwood Shores always like to do business (just ask some other recipients of this treatment… for example Red Hat).
Let’s face it sir… if you are not buying HP databases, applications or middleware then why the hell would you want to buy HP servers? It is time to wake up and smell the industry for what it is folks.
To quote another not so famous but nonetheless entertaining movie, if you are not taking open source database seriously then…
“your situational awareness kind of sucks” (The Perfect Getaway).
I believe that it is also high time to take a serious look at open source database and put some distance between your bank account and Larry’s. Of course we are more than just a little biased in this matter but we do believe that EnterpriseDB/Postgres is a natural choice for anyone seeking a DBMS platform on HP servers (or any other server) going forward. There has never been a better time to start. It is also a very good time to start looking at open source middleware (we like Geronimo… so does IBM) too before Larry decides to de-support WebLogic on Itanium too.
God save us all if Larry decides to walk away from Java on Itanium (… and other non-Larry hardware). Or at the very least god save HP.
I had searched high and low for a solution to this. Seems like all the solution examples on Geronimo’s web site were using annotations and everything else I looked at seemed to draw a complete blank. Never being one to give up that easily I decided to hack my way through it. The first trick to be aware of is that like all the other services in Geronimo, the OpenEJB services are installed into the server by means of a resource adapter GBean. This doesn’t matter that much other than that you need to consider this when searching for a solution. So the first thing I did was set up an initial context in my EJB client code (the scenario is Session EJB calls another session EJB using local interface). The following code fragment shows how to set up the initial context call:
Code:
Properties props = new Properties(); | |
props.setProperty("java.naming.factory.initial", | |
"org.openejb.client.LocalInitialContextFactory"); | |
| |
Context ic = new InitialContext(props); |
Note that I use “org.openejb.client.LocalInitialContextFactory” as the JNDI context factory class.
The second interesting fact has to do with the way in which OpenEJB exposes JNDI resources. When an EJB is deployed with both local and remote interfaces in most containers the java:comp/env namespace is used to provide access to local interface EJB resources. In Geronimo 2.2 with OpenEJB this definitely does not work at all. What actually happens is that an additional EJB interface is exposed as a “Local” interface. For example if I had deployed an EJB with the following components:
1) FooSessionEJBLocal - local interface
2) FooSessionEJBRemote - remote interface
3) FooSessionEJBBean - the actual session bean
… then OpenEJB will expose FooSessionEJBBean (the remote bean) and another curiously named EJB FooSessionEJBBeanLocal (the local bean). Only the latter can be cast to the FooSessionEJBLocal interface so for example when performing a lookup your code should look like this:
Code:
try { | |
Properties props = new Properties(); | |
props.setProperty("java.naming.factory.initial", "org.openejb.client.LocalInitialContextFactory"); | |
Context ic = new InitialContext(props); | |
FooSessionEJBLocal localFoo = ic.lookup("FooSessionEJBBeanLocal"); | |
localFoo.bar(); | |
} catch (Exception e){ | |
... do whatever | |
} |
Note that the lookup is for “FooSessionEJBBeanLocal” and not “FooSessionEJBLocal". Also note that if you try to bind the remote EJB (FooSessionEJBBean) you can do so but that transactional context of using local EJB will not be managed by JTA (this is important if your code is dependent on operations within the context of the current container transaction).
Truth be told I was amazed that nobody on any of the Geronimo mailing lists had figured this out or had posted a workable solution.
Just thought I would drop you all a not on my blog to let you know that PWS is organizing a day of free EnterpriseDB/PostgreSQL training around 9th/10th June 2011 in JAKARTA INDONESIA. If you are interested in attending this training then please contact PWS with the following details:
1) Your Full Name
2) Your contact details (telephone and email)
3) Your company name
4) What you would like to get out of the training.
If you can’t decypher the contact details above then just email me directly david(at)pwsindonesia.com … obviously replace the (at) with an @ sign.
One would assume that this is a simple thing at the outset but… not quite so fast. This actually took me a couple of days of hard slogging and debugging. The bottom line is that the the time is worth it for getting a value object mapping framework in place for one of the major applications we are building but there is a moderate amount of pain getting it going.
The major issue I struck with Dozer 5.3.2 is that the documentation on installation and configuration is non-existent for application servers. It also seems there have been so0me challenges with the class loader that Dozer uses internally. This relies on Apache Commons Lang 2.5 (the ClassUtils package). Once I had all of the minor stuff sorted out (XML mapping… BTW I recommend that you build a java main() to test your mappings out, especially if you are mapping a deep and complex structure as we are. There are a number of the advertised features of Dozer that are not well documented and also at times just do not work as expected. So you will need to play around with the XML mapping file and learn all of the constructs (which also takes a little time). What I ended up doing was downloading the Dozer sources and modifying the class loader because it was having problems in Geronimo (probably due to Geronimo’s class loading scheme). Anyway… a simple Class.forName() instead of using the CLassUtils calls to create the DefaultCLassLoader in Dozer and the problems were more or less solved.
I also ended up bundling everything up into a single JAR so that the dozer.properties, dozerBeanMapping.xml and the required XSD schema was on the classpath of the application… BTW, prior to this I tried all sorts of things (building a Geronimo adapter, deploying to the repository, placing the Dozer JAR file in the /lib/endorsed etc… all to no avail.
A few months back I mentioned that we were developing an A2A integration framework that acts as a low cost replacement for JCA that provides a far simpler architecture for integration whilst decoupling enterprise applications from each other. Anyway I just though I would attach the data sheet to my blog. The product is very well tested and pretty much ready for mainstream now.
The framework is Web Services based and supports many features guaranteed message delivery and can be deployed to pretty much any JEE application server with pretty much any JMS stack. The current build is targeted at Geronimo Application Server (which we think is a very cool AS by the way) but we will provide builds for WebLogic, WebSphere and jBoss upon request and probably default builds longer term. We are still not sure how we are going to license the product. We may go for an open source or a full source commercial license. We really have not decided. It would be great if anyone has feedback about the product feature set and where we are going with it. The itch we had to scratch was the overall complexity and expense of large commercial enterprise integration solutions and their general lack of leadership in the SOA space with asynchronous A2A. We think we are on a winner.
Anyway here is a link to the data sheet in PDF format. It is about 1.6Mb so not large at all:Pathway Data Sheet
So if anyone is interested then drop us a line via our contacts page at http://www.pwsconsulting.com
The massive vendor drive toward cloud computing had me wondering for a while but I guess it is here to stay. SAAS, PAAS… pick your flavor. Whilst there are some potential benefits for users of cloud locally there is a large hanging question in my mind about the tangible benefits. These days it is bad enough when vendors serve up some of the most archaic and outdated software as the next big thing. Whilst this is going on the industry innovators happily capitulate and sell out to the nearest rich mega vendor (whom like all mega-vendors is struggling to modernize and maintain their existing software portfolios, let alone a whole lot of brand new stuff that they don’t have the capability to manage). This is especially so after they annihilate anyone from the acquired company that has more than quarter of a brain. We live in interesting times for IT. To top it all off now they want us to trust them with all of our data and systems. Maybe we should think long and hard about how earnest and reliable they really are along with the last sensible conversation you ever managed to get out of an enterprise sales person (when he wasn’t reading off the slides). Having been in this industry for nearly 30 years I think I can say I have seen most of it (up close and brutal many times).
Anyway just a quick opinion… mega-vendor cloud computing… thanks but no thanks for me.
I remember the very first time I used WebLogic. It was back in around 1998 not long after BEA first acquired it. At the time I was doing a whole lot of work using Tuxedo and C on a Dynix (dinosaur Unix ![]()
) in a large government department. During that year BEA set up operations in Australia and the country managing director of the time (Mr. David Moles) offered myself and my team free training on the first WebLogic training course to be run in Queensland Australia. Back in those days I was somewhat of a Linux nut and decided to run the training on Linux so within an our or so I managed to get WebLogic running on Caldera Open Linux 1.3 with the Linux Blackdown JDK (quite an achievement in those days).
Here we are 14 years later with a lot more choice of J2EE application servers at our disposal, the most interesting of these being the open source J2EE containers. Having significant experience with J2EE over many years as a programmer and analyst it is interesting to reflect on the salient characteristics of all these servers. My own experience includes WebLogic, OC4J, Apache JServ, WebSphere, SilverStream, Geronimo and JBoss. Other servers such as Glassfish have built a very credible reputation for themselves also. Not having used Glassfish in anger it is hard for me to include it in my list so I will omit it to be fair. Also since SilverStream has been acquired (by Novell) some years back and may have changed significantly I shall omit it also. The dead products have also been omitted (i.e. JServ and OC4J)… OC4J is somewhat dead even though it is still on Oracle’s price list. Just goes to show what Larry thinks I guess.
Anyway… without going into a horrific amount of detail (actually extremely brief) it is my belief that these servers generally stack up as follows in order of best to worst from a pure usage and deployment standpoint:
1) Developer Productivity: 1:WebLogic, 2:Geronimo, 3:WebSphere, 4:JBoss
2) Implementation of Key J2EE Standards: 1:Geronimo, 2:WebSphere, 3:JBoss, 4:WebLogic
3) Management and Monitoring Features: 1:WebLogic, 2:WebSphere, 3:Geronimo, 4:JBoss
4) Performance and Stability: 1:WebLogic, 2:Geronimo, 3:WebSphere, 4:JBoss
5) Installation and QuickStart: 1:Geronimo, 2:JBoss, 3:WebLogic, 4:WebSphere
6) Tooling and 3rd Party Support: 1:WebLogic, 2:WebSphere, 3:Geronimo, 4:JBoss
7) Overall Happiness 1:WebLogic 2:Geronimo, 3:WebSphere, 4:JBoss
It should be noted that the open source containers (generally) have far less features for management and monitoring etc. than the commercial platforms. Many of these features are also commonly flawed in design or broken in implementation in open source servers. For example the console in the latest production builds of JBoss will not even add data sources properly without problems and developers/admins are forced to resort to the XML configs etc.. These types of features generally work better and are more complete in the commercial products. Anyway, evaluate yourselves and form your own opinion. Feel free to post it here and you are bound to get a response from me.
The intention of this blog is to collect thoughts on the issues, paradigms, process, vendors, solutions, project and any other item related service oriented architecture in South East Asia.