Wednesday, March 30, 2011

Oracle speaks at The Server Side Java Symposium (TSSJS): Part Two - JEE

My apologies for the delay in getting this one out there.  My personal life has been a little crazy lately.  Anyways, today I will share some of the direction Oracle shared with us for Java Enterprise Edition at the Server Side Java Symposium, as well as my take on these items.  So read on!

This part of the presentation was done by Steve Harris.  He began with a recap of why JEE "won" on the internet server side (Oracle's points in bold, mine in italic text):

  • Easy to deliver compelling content - Most definitely in the early years of everything coming onto the net.  Servlets and JSPs were way better than ASP and CGI of the time.
  • Easy to couple content to business data - I still love the overall simplicity of JDBC connections...adding an ORM to that makes it even better because it further decouples your code from implementation details in the DB.
  • Architectural foundation for huge scale - Architecturally sure...in practice, I have no experience with huge scale.  After all, architecturally, communism works too!
  • Reproducible Results - The whole "Write Once, Run Anywhere" worked a hell of a lot better than it did in the past, and still works better than a lot of others out there today (<ahem>...Mono, anyone?)
Then, Steve went on to say, Java went on to make it easier to connect to Other Businesses and Partners, in ways such as:
  • SOA and JEE - Yeah, they both work and are wonderful in theory, however, they crumble a bit more than people would like when put into implementation.  I think this is due to the complexity of full implementations.
  • Make communications secure, manageable, reliable and interoperable - He has a point here, because much of this is done over fairly well defined (like CORBA) and ubiquitous (like HTTP) protocols, and by using simple easy to exchange data formats.
Then, for the second time in this presentation, Oracle admitted to their (well Java's) failures:
  • Functionality was added over time leading to bloat and complexity- How many of you have actually used every piece of JEE?  I haven't and I have been doing Java stuff since 1.2.
  • This led to:
    • Possibility to solve complex problems, but made simple problems difficult - Java has part to blame here, but I also think it has to do with developers, architects and designers overengineering software.  I'll be the first to admit I have done it.
    • Developers turned to simpler solutions - This is where a lot of people started to see that Oracle may be admitting that Spring got it right...read on for more evidence of this.   
Steve finished off this part by stating what would become a recurring theme throughout the rest of the presentation: Oracle has listened to the community about all of this and learned from it!

As he continued on, it became apparent that they like what Spring has done.  Below is what he stated needed to be fixed and has already begun in JEE6:
  • POJOs - (how come I picture a scene from Animal House here with the chant "POJO! POJO! POJO!").  A welcome sight.  Playing with reflection over the past number of years, all I can say is that POJOs rock!
  • Annotations overridable by XML - XML as configuration has always slightly bugged me, but it is nice to see that some of the annotation-only config is now being fixed (IMO, annotations are only useful for configuration for sensible default values, coupling configuration and code like some of the JEE5 stuff did was just annoying).
  • Simplify APIs and reduce coding effort- Not much info was given about this, except to say that things like EJBs have gotten easier to do, so I guess we will see.  A lot of this will depend on the language enhancements in JSE.
  • Dependency injection - Um, did Oracle just almost fully admit that Spring got it right?
  • Restful Services - These seem to be taking off, but I admittedly know little about the implementations of these.  So all I have to say is that this is likely a good thing since the web services world is kind of split between SOAP and REST at the moment.
To summarize, the presentation went on to discuss what Oracle has learned from JEE:
  • Deliver real value, not just something that looks good on paper - EJBs anyone?
  • Watch for other innovations - JEE got smoked in this area by things like Spring, Hibernate, Toplink, etc. Steve did talk about things like watching Spring blaze the trail and then adopting those technologies that were successful (like Dependency injection) into the JEE.  This kind of worries me.  Think about logging.  We finally have logging in Java, but does anyone actually use it?  Everyone I know still uses Log4j, and all of the APIs we use are using Log4j or commons-logging or slf4j. I think the same thing may happen with the Spring technologies. However, he did give another example, which is the new language feature of closures...these have been implemented for a long time in languages like LISP and Erlang.  Java can now learn from these mistakes and implement the features properly.  I think this is an example that is respresentative of when it is good to wait.  So overall I dislike Oracle's stance of let's wait for others to figure it out before we implement it (Debian Linux has a similar stance, and they are so far behind, that I don't use it).  Instead I'd like to see them take a more balance approach between "wait-and-see" and "trail-blazing".
  • Move or die -  Kind of like a game of dodgeball or asteroids, huh?
  • Customers win when vendors compete on a standard platform - Pardon me if I don't believe you Red...Your quest to buy up everything you can to compete with Microsoft is not that well hidden.  While this has been true under Sun's stewardship, I'll believe it when I see it from Oracle.
At this point, we changed pace and began hearing about "the cloud" (to quote the diabolical developer's presentation..."The Cloud...meh.").  There were some interesting thoughts in this part of the presentation, but we'll see what sticks to the wall and what doesn't:
  • Enterprise Devs want internal cloud solutions - I kind of agree with Richard M. Stallman's view of the cloud.  One of the biggest issues with the cloud today is that someone else (usually a nebulous entity) is in control of your data and not you yourself.  I don't think that it is just devs that want this, I think it is all of Enterprise IT.
    • Devs really like the elastic nature of a lot of cloud services - if I still lived in the same city where I worked, I'd actually consider ditching my car and only renting one when I needed it.  Even though the per unit cost is quite a bit higher, it would be cheaper for me, because I would likely drive a lot less. Many cloud services, like Amazon's EC2 follow this pay for only what you use model, and I think it actually has value.
  • Virtualization is a tool not a solution -  Boy how I wish many Technical Architects and server admins realized this.
On this cloud note, Steve began to explain how the current model of supporting Java EE tech consists of three roles:
  • Dev - the team who designs and writes the apps
  • Deployer/Administrator -  the teams responsible for keeping the live system going.
  • Container Provider - Usually server admins.
He sees this changing to the following roles:
  • Devs - same as above, except that these people are now tenants in the Containers provided, instead of having their own.
  • App Admin - The team responsible for the ongoing care and feeding of the system.  Also part of an enterprises tenancy in the container.
  • Application Deployer - This may become someone no longer part of the enterprise that owns the application, but rather someone who is part of the PaaS (Platform as a Service) provider.
  • Container/Service Provider - Again instead of necessarily being someone who is part of the enterprise owning the application, it may be someone that is part of the PaaS organization.
  • PaaS Administrator - The team on the PaaS Provider's side that is responsible for the care and feeding of the elastic infrastructure.
Java is going to need to adapt to these new roles.  In addition, we need to make the switch from thinking APIs to thinking cloud services.  Java is currently built around APIs, and these need to be updated to be service-enabled and tenant aware. 

I think that the shift to services is going to be a struggle for a lot of organizations, based on what I have seen in my own. People are so used to writing their own APIs and not re-using services already available.

JEE 7 will apparently be the "Cloud Foundation" release of JEE.  However, JEE will continue to be dependant on the parallel JSE version being release first, so that JEE can take advantage for the new features in the base language and APIs.

Steve then surmised that JEE 8 may be about cloud maturity and interop.

Steve and Adam then pretty much finished off with "Oracle's Eeeeeeeeeeevil Plan For Java":

I think overall it is going to be an exciting time to be into Java.  I am far less worried about the future of the platform than I was when the Oracle deal was first announced.  Thoughts anyone?


- Munky

No comments: