Java é o novo COBOL?

Claro que o título é provocativo. Antes de mais nada deixo claro que já fui programador Java (desde as primeiras versões) e sou um defensor da linguagem. Penso porém que vale a pena um pouco de reflexão sobre o futuro desta plataforma.

Sempre argumento com o time de arquitetura da empresa onde trabalho sobre as opções que temos de desenvolvimento ágil. Utilizamos Java em nossos projetos mas sempre tento provocar uma discussão no sentido de avaliarmos as alternativas de linguagens mais "leves" (lightweight frameworks).

Ruby, PHP, JRuby (Java + Ruby, óbvio não?), são opções que devemos sempre considerar partindo da premissa que nenhuma linguagem/plataforma pode solucionar todos os problemas. O mais importante é termos o "fecho" da arquitetura e garantir a interoperabilidade entre os aplicativos. No nosso caso, com a nova arquitetura SOA implantada e a utilização de Web Services, isto fica muito mais fácil.

Bom, voltando ao Java. Esta discussão de que o Java não é mais o mesmo vem e volta sempre. É difícil argumentar quando sabemos que existem mais de 5 milhões de desenvolvedores Java atualmente. Por outro lado, mais e mais "cool kids" estão escolhendo alternativa a Java para implementar seus web sites. É o que argumenta Coach Wei neste artigo no JDJ.

Ele questiona se seria a falta de frameworks? Certamente não. Como ele mesmo cita, "I bet there are more Java frameworks than the population in China". A questão é que muitos web sites são simples, sem muita complexidade; e isto talvez seja uma tendência. Neste ponto, scripts e lógicas lightweight no lado do servidor, que é a "praia" do PHP e Ruby/JRuby etc.

O que está faltando no mundo Java?

Ele aponta três alternativas:

1. JSP/Servlet com um Java Servlet engine (or mesmo um application server): Esta é a arquitetura predominante para aplicações Web-based nas corporações. Mas não tem nenhuma vantagem na contrução de web sites quando comprados com PHP ou Ruby;

2. JavaServer Faces: JSF é "the new kid on the block". Vai facilitar a construção de sites? Provavelmente não! JSF foi desenvolvido para simplificar a contrução de aplicações form-based.

3. Utilização de um Java based content management system (CMS)? Segundo o autor, nenhum Java-base CMS tem o apelo e inovação suficiente para ser um "killer".

A propósito, o título do post vem deste outro artigo: "Java, the Cobol of the 90's?", escrito por Quinton Wall (BEA).

JAVA EE 5, SOA, the bad, the good... (Part 2)

+
This is the Part 2 This Special Report from WebServices.com about JavaEE 5 and Enterprise SOA.

1. The Bad (by Bruce Snyder, co-founder and developer for the Geronimo project and a senior architect at LogicBlaze Inc., an open source SOA provider)

Snyder said enterprise-grade SOA should have flexibility on the back end as well as on the developer side, and by that he means making it easier to do things. "There's a portion of Java EE trying to standardize on that," he said, such as the move toward annotations with the JAX-WS spec. "It's good in terms of standardization, but in terms of flexibility and simplifying things, I'm not sure Java EE 5 does that. I still see people going outside of Java EE to look for solutions."

2. The Good (by Michael Bechauf, vice president of industry standards at SAP AG)

All this said, organizations have to be asking themselves, just how much work is involved in taking existing enterprise apps and componentizing/service-enabling them? And does Java EE 5 make it easier?

"Java EE 5 as a technology platform has made it dramatically easier to service-enable an existing Java application," said SAP's Bechauf. "For example, Java annotations can easily service-enable a Java method. Tools also may help a great deal with the service-enabling. If you wanted to do this with a bare-bones IDE and had to write all of the code yourself using Web service APIs, it could be a fair amount of work. If you were to use a tool which helped automate this process, it would be much easier.

3. A sensate opinion (from J.Bloomberg, ZapThink.com)

Vendors that are part of the EE 5 ecosystem like SAP and JBoss are offering broader capabilities than just Java EE 5, said Jason Bloomberg, a senior analyst with ZapThink LLC. "You still need scalable, transactional Web sites, and if you want [IBM] WebSphere or [BEA] WebLogic that makes sense, but if you're looking to do SOA you're not going to focus on the same priority. It's what BEA is struggling with as it moved to SOA 360 º, for example. [Vendors] are rethinking what it means to provide a SOA platform."

4. A word from Bill Roth, Vice-President of BEA

While Roth said the company is not looking to distance itself from the Java platform, "are we saying things other than J2EE? Yes, for example an ESB is a useful way to think. There's no J in SOA, it opens up whole new world for us. The SOA world is not necessarily Java. Is Java the most productive platform for creating building blocks in SOA? Of course. Is it the best way to build everything? No.

Roth said he views building composite applications and Java EE 5 as orthogonal. "There are new technologies like Service Component Architecture, which describe how larger services are woven together and BPM [business process management], which talks about how services talk to each other. Java EE 5 [is about] how to build better services, but the process of weaving them together as an SOA is at a much larger level and might not involve Java."

5. And finally, the Importance of Service Component Architecture (SCA), by Richard Monson-Haefel, a senior analyst at Burton Group Inc.

Monson-Haefel said the Service Component Architecture (SCA) initiative "is supported by all the big players in EE space and SCA has little or nothing to do with EE."

SCA supports service implementations written using a variety of programming languages, including object-oriented languages, as well as Java, PHP, C++, and Cobol; XML-centric languages such as BPEL and XSLT; and declarative languages such as SQL and XQuery.

The fact that SCA is implemented on top of Java EE, but "doesn't reference Java EE specifically," is telling, Monson-Haefel said. "I don't have a lot of confidence that SCA will go anywhere, but all the vendors [involved] is indicative they're hedging their bets.

JAVA EE 5, SOA, the bad, the good... (Part 1)

This Special Report from WebServices.com brings some light to recurrent discussion: at the end, JAVA EE 5 is too complex? EE would be a good option to implement SOA-based project? How well suited is Java EE style to implement lightweight services?

According to this report:

The good:

• Java EE 5 includes several key specifications intended to improve and simplify Web services support. These are: Java API for XML-Based Web Services (JAX-WS) 2.0, Java Architecture for XML Binding (JAXB) 2.0, Web Services Metadata for the Java Platform 2.0 and SOAP with Attachments API for Java (SAAJ) 1.3.
• The core tenet of SOA is loose coupling within Web services and without," Kassem said. "In Web services, our [J2EE 1.4] initial foray was very RPC-centric. That dramatically shifted with JAX-WS 2.0, it was an important programming model shift. It enables us to build more loosely coupled Web services that will scale very well for the Web. [It] was a significant SOA-centric initiative. Simultaneously, we [made] significant improvements in the JAXB 2.0 spec to enable better quality data bindings. The quality of bindings is really important. If you don't get the bindings right, you have round-tripping problems in the SOA world that you never get right. We're not completely there, but it's a big improvement.

The Bad:

(from Richard Monson-Haefel) "What we're seeing are the last few years of Java EE as a leading choice in doing enterprise development, which is pretty obvious with the rise of rebel frameworks like Hibernate, Spring, Tapestry and Struts, which don't fall directly under the EE spec. These are indications that programmers are looking for platforms that are easier to work with. There are solutions you can use with Java EE like Struts, and many claim these reinforce EE as a good platform, but they're actually raising the abstraction so developers are working with the framework and not the EE platform programming model."

Jason Bloomberg, senior analyst at ZapThink LLC, said, "In the big picture in the SOA world, people are moving away from Java EE 5. It's becoming less and less relevant. EE is essentially an architecture for building scalable, transactional Web sites. It's not designed for SOA. More people are understanding the limitations, and realizing there are other Java-based approaches. We're not seeing anybody interested in JAX-WS and JAXB. We are seeing open source Java suites as appropriate for SOA. It depends on what you're trying to accomplish, but we see a lot of use of elements of open source ESBs and Hibernate for various parts of the Java infrastructure. What we're not seeing is interest in Java EE."