Você Está Pronto Para O Próximo Update do Java?

Oracle criou dois novos recursos, o 
Java RIA Security Checklist e o Java Security Resource Center para ajudar você a se preparar para a próxima atualização do Java SE, Java SE 7 update 51 (agendado para Janeiro de 2014). Esta versão modifica os requisitos de deployment para aplicações em Applet & Web Start com dois novos requisitos: 

1. Uso do atributo Manifest, chamado Permissions
2. Assinaturas de código válidas

Estas mudanças não afetarão desenvolvedores de aplicações back-end, ou cliente standalone; o escopo é limitado somente para Java Applets & Java Web Start (RIAs). Leia alguns destes detalhes no meu post anterior Mudanças no Java SE 7u51 para Applets e Web Start.

Java RIA Security Checklist


A mudança agendada para o Java SE 7u51 irá fazer com que o controle de segurança "default" (security slider) requererá o atributo Permissions no Manifest, e que o código esteja assinado devidamente com um certificado de código válido. O Java RIA Security Checklist
 provê as melhores práticas para ajudar os times de desenvolvimento a identificarem as tarefas necessárias para atender a estes novos requisitos.

Security Resource Center


A Oracle lançou o novo Java Security Resource Center para agrupar informações relacionadas a segurança para a comunidade Java, de acordo com o perfil de cada profissional: desenvolvedor, administrador de sistemas, usuário doméstico, ou especialista em segurança.

Recursos Adicionais

• Java Platform Group Product Management blog – Oferece informação, boas práticas, e exemplos relacionados a Java SE, segurança, e usabilidade.
• Java SE 7 Security Documentation

• Java Tutorial for Signing Code
• Jar File Manifest Attributes for Security

Nota:
 Para garantir que sistemas de usuários finais (end users) estejam protegidos quando usando conteúdo baseado em Java, a Oracle recomenda que você esteja sempre atualizado para a mais recente versão. Você pode remover versões antigas do Java seja durante o processo de atualização, ou com usando a ferramenta Java Uninstall Tool em Java.com.

O futuro do WebLogic 12c

Antes de falar do WebLogic 12c, uma informação importante é que prorrogamos o suporte do WebLogic 11g (versão 10.3.6) até 2018, e o suporte estendido até 2021. Isto dará maior tranquilidade aos clientes a planejarem suas migrações, reduzindo assim riscos e custos, principalmente aos clientes de Fusion Apps e SOA Suite/BPM. 

A versão atual do WebLogic 12c é a 12.1.2, lançada este ano em Junho, juntamente com todo o Cloud Application Foundation 12c (Coherence, Oracle HTTP Server, Tuxedo, etc). A versão anterior 12.1.1 já era certificada em Java EE 6, e agora esta nova versão traz uma série de recursos e funcionalidades para integrar suas aplicações com o banco de dados Oracle 12c, facilitar o operacional através de Dynamic Clustering e Elastic JMS, mais otimizações para Exalogic e JMS, administração do Oracle Coherence pelo console administrativo do WebLogic, plugins para desenvolvimento de projetos com Apache Maven, geração automática de serviços REST para seus projetos JPA com o TopLink RESTful Data Services, e muito mais.

O WebLogic 12.1.2 também substituiu o antigo instalador da BEA e os utilitários de patch BSU com o Oracle Universal Installer e o utilitário opatch para a aplicação de patches. Muitos clientes Oracle já conhecem estas ferramentas, que já eram utilizadas para outros produtos, como o próprio Banco de Dados.

Ou seja, uma série de novidades que justificam a liderança do WebLogic no mercado de Application Servers. Mas ao olhar os próximos passos e o roadmap para as versões do WebLogic 12.1.3 e 12.1.4, há motivo de sobra para se interessar na versão 12c.

A versão WebLogic 12.1.3 deverá ser a primeira homologada para diversos produtos 12c do FMW como SOA Suite 12c. Além disso, alguns novos recursos serão incluídos para melhorar ainda mais a experiência do administrador de infraestrutura para escalar ambientes com mais servidores. Por exemplo, a feature de Elastic JMS permitirá o uso do Server Migration sem perder mensagens durante esta execução. Estamos trabalhando para oferecer na versão 12.1.4 o suporte para auto-scaling de clusters dinâmicos, com base em limites e métricas definidas pelo usuário. O WebLogic 12.1.4 também deverá ter uma API para controlar os clusters dinâmicos. Desta forma, os usuários poderão facilmente programar a hora de parar, iniciar ou remover nós de um cluster dinâmico.

O WebLogic 12c conta com o driver JDBC 12c, oferecendo melhor integração com o Oracle DB 12c, e uma destas features é chamada de "Application Continuity". Esta feature permite que após uma falha de comunicação com um nó de um Oracle RAC, a transação com o banco de dados seja transferida sem qualquer efeito colateral para outro nó do cluster, garantindo disponibilidade. Na versão WebLogic 12.1.4, será introduzido também um novo recurso chamado de Multitenant Applications. Desta forma usuários poderão definir um modelo WebLogic para uma aplicação, para um ou mais clientes desta aplicação, que terá o seu próprio cluster, etc.

O conteúdo acima foi originalmente postado aqui.

AVISO LEGAL: O texto acima visa delinear nossa direção geral dos produtos. Destina-se apenas para fins informativos, e não pode ser incorporado em qualquer contrato. Não é um compromisso e não deve ser usado na tomada de decisões de compra. O desenvolvimento, lançamento e tempo dos recursos ou funcionalidades descritos para os produtos da Oracle permanecem a critério exclusivo da Oracle.

Reality of Open Source Users in Mobile and Cloud Era

- "I built my Android app entirely with Open Source products, both in the app, and in the backend server running on Amazon. I'm charging US$ 1,99 for it in the Google Play Store" 

- "That's wonderful! Where is the source code of your app? Have you contributed back to these Open Source products? Will you release your product as Open Source?"

In this new era of Cloud Computing and Mobile apps, there's an increasing number of for-profit products that takes advantage of Open Source products, but barely contribute anything back to them, either by buying support, or non-expensive things such as reporting bugs, fixes, or helping documentation. Developers are building SaaS applications for Salesforce.com, or Mobile apps for Android and iOS devices, and usually charge for these. Of course, they want to make money as anyone else.

Whenever I ask someone that makes money with _their_ software built on top of Open Source, if they will ever release the source code, they usually answer: "my case is different". Well, why is your case different? Why can't I buy your app from Google Play Store, and still access the code on GitHub? Or build it on my own, customize it, etc? That's the point of Open Source, right? Wrong, in their minds.

Majority of software developers actually tend to think that Open Source is free as in free beer. And that's it. No matter how hard you try to explain otherwise, the industry will almost always see Open Source software as free software. And due to the new way to sell software, I really think that Mobile apps and Cloud SaaS/PaaS offers will, sooner or later, kill good Open Source softwares, and leave this space only for conceptual and initial implementations for Open Standards and APIs, or for general use and development platforms and languages such as Java, Ruby, etc.

Perhaps you want to read Will Cloud kill Open Source? Is the Future Open Standards? Your thoughts are welcome :-)

6 Facts About GlassFish Announcement

Since Oracle announced the end of commercial support for future Oracle GlassFish Server versions, the Java EE world has started wondering what will happen to GlassFish Server Open Source Edition. Unfortunately, there's a lot of misleading information going around. So let me clarify some things with facts, not FUD.

Fact #1 - GlassFish Open Source Edition is not dead

GlassFish Server Open Source Edition will remain the reference implementation of Java EE. The current trunk is where an implementation for Java EE 8 will flourish, and this will become the future GlassFish 5.0. Calling "GlassFish is dead" does no good to the Java EE ecosystem. The GlassFish Community will remain strong towards the future of Java EE. Without revenue-focused mind, this might actually help the GlassFish community to shape the next version, and set free from any ties with commercial decisions.

Fact #2 - OGS support is not over

As I said before, GlassFish Server Open Source Edition will continue. Main change is that there will be no more future commercial releases of Oracle GlassFish Server. New and existing OGS 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy. In parallel, I believe there's no other company in the Java EE business that offers commercial support to more than one build of a Java EE application server. This new direction can actually help customers and partners, simplifying decision through commercial negotiations.

Fact #3 - WebLogic is not always more expensive than OGS

Oracle GlassFish Server ("OGS") is a build of GlassFish Server Open Source Edition bundled with a set of commercial features called GlassFish Server Control and license bundles such as Java SE Support. OGS has at the moment of this writing the pricelist of U$ 5,000 / processor. One information that some bloggers are mentioning is that WebLogic is more expensive than this. Fact 3.1: it is not necessarily the case. The initial edition of WebLogic is called "Standard Edition" and falls into a policy where some “Standard Edition” products are licensed on a per socket basis. As of current pricelist, US$ 10,000 / socket. If you do the math, you will realize that WebLogic SE can actually be significantly more cost effective than OGS, and a customer can save money if running on a CPU with 4 cores or more for example. Quote from the price list:

“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name (with the exception of Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.”

For more details speak to your Oracle sales representative - this is clearly at list price and every customer typically has a relationship with Oracle (like they do with other vendors) and different contractual details may apply.

And although OGS has always been production-ready for Java EE applications, it is no secret that WebLogic has always been more enterprise, mission critical application server than OGS since BEA. Different editions of WLS provide features and upgrade irons like the WebLogic Diagnostic Framework, Work Managers, Side by Side Deployment, ADF and TopLink bundled license, Web Tier (Oracle HTTP Server) bundled licensed, Fusion Middleware stack support, Oracle DB integration features, Oracle RAC features (such as GridLink), Coherence Management capabilities, Advanced HA (Whole Service Migration and Server Migration), Java Mission Control, Flight Recorder, Oracle JDK support, etc.

Fact #4 - There’s no major vendor supporting community builds of Java EE app servers

There are no major vendors providing support for community builds of any Open Source application server. For example, IBM used to provide community support for builds of Apache Geronimo, not anymore. Red Hat does not commercially support builds of WildFly and if I remember correctly, never supported community builds of former JBoss AS. Oracle has never commercially supported GlassFish Server Open Source Edition builds. Tomitribe appears to be the exception to the rule, offering commercial support for Apache TomEE.

Fact #5 - WebLogic and GlassFish share several Java EE implementations

It has been no secret that although GlassFish and WebLogic share some JSR implementations (as stated in the The Aquarium announcement: JPA, JSF, WebSockets, CDI, Bean Validation, JAX-WS, JAXB, and WS-AT) and WebLogic understands GlassFish deployment descriptors, they are not from the same codebase.

Fact #6 - WebLogic is not for GlassFish what JBoss EAP is for WildFly

WebLogic is closed-source offering. It is commercialized through a license-based plus support fee model. OGS although from an Open Source code, has had the same commercial model as WebLogic. Still, one cannot compare GlassFish/WebLogic to WildFly/JBoss EAP. It is simply not the same case, since Oracle has had two different products from different codebases. The comparison should be limited to GlassFish Open Source / Oracle GlassFish Server versus WildFly / JBoss EAP.

But the message now is much clear: Oracle will commercially support only the proprietary product WebLogic, and invest on GlassFish Server Open Source Edition as the reference implementation for the Java EE platform and future Java EE 8, as a developer-friendly community distribution, and encourages community participation through Adopt a JSR and contributions to GlassFish.

In comparison

Oracle's decision has pretty much the same goal as to when IBM killed support for Websphere Community Edition; and to when Red Hat decided to change the name of JBoss Community Edition to WildFly, simplifying and clarifying marketing message and leaving the commercial field wide open to JBoss EAP only. Oracle can now, as any other vendor has already been doing, focus on only one commercial offer.

Some users are saying they will now move to WildFly, but it is important to note that Red Hat does not offer commercial support for WildFly builds. Although the future JBoss EAP versions will come from the same codebase as WildFly, the builds will definitely not be the same, nor sharing 100% of their functionalities and bug fixes. This means there will be no company running a WildFly build in production with support from Red Hat.

This discussion has also raised an important and interesting information: Oracle offers a free for developers OTN License for WebLogic. For other environments this is different, but please note this is the same policy Red Hat applies to JBoss EAP, as stated in their download page and terms. Oracle had the same policy for OGS.

TL;DR;

GlassFish Server Open Source Edition isn’t dead. Current and new OGS 2.x/3.x customers will continue to have support (respecting LSP). WebLogic is not necessarily more expensive than OGS. Oracle will focus on one commercially supported Java EE application server, like other vendors also limit themselves to support one build/product only. Community builds are hardly supported. Commercially supported builds of Open Source products are not exactly from the same codebase as community builds.

What's next for GlassFish and the Java EE community?

There are conversations in place to tackle some of the community desires, most of them stated by Markus Eisele in his blog post. We will keep you posted.

Will Cloud kill Open Source? Is the Future Open Standards?

Before you think I'm FUD'ing here, please note that there are already plenty of articles discussing this. Do a search for Open Source vs Open Standards on Google. You might be surprised. The oldest article I found in the first result page is one by Jonathan Schwartz from 2003, titled Open source versus open standards. Then there's another one called ZDNet: Open source vs open standards from 2004. Then there's another interesting one called Open Source vs. Open Standards, by Bob Sutor, from 2006-2009. There's another more recent one from this year, titled Open Standards And Open Source.

But if you payed attention, you might have noticed that none of these articles have the word CLOUD in it. And that's what differs from this blog post you are about to read.

Here is an interesting trend from Google to start this discussion.

Clearly, the interest in Cloud is going up, where interest of Open Source is going down in an almost equivalent proportion. Is the Cloud Computing era going to kill Open Source? I dunno. But this should warn us of one thing: that the Cloud era is not about Open Source. It is about Open Standards (and APIs).

As we all know, APIs expose functionality, not implementation, where the beauty of Open Source is that we all can look at the source code and be sure of how the implementation works, how the pieces are put together to make our application run. If you are a truly defender of Open Source, you are probably thinking right now that there is a company that offers a Cloud platform based on an Open Source software. But do you have access to the runtime? Can you be sure that they are running the exact same code as they tell you? Will they give you access to the server to check if the MD5 is the same? Even the Linux they say they are using might be different. You just cannot be sure. You don't own the infrastructure.

If we take the main 3 types of Cloud offers: SaaS, PaaS, and IaaS, only the latter we can be *more* sure, but still not 100% sure that our applications are running on top of Open Source software. Do you have access to the provisioning code that Amazon AWS uses to create your Linux instance? Do you have access to the source code of the network configuration utility? No. You say your project runs on top of 100% Open Source software. Then you tell me you are running your application at Amazon, or Azure, Oracle, Jelastic, CloudBees, CloudFoundry, etc? You are not running over only Open Source code. You are not. Your application relies on closed-source code to run on that Cloud. There will always be at least one component of that cloud that is not open sourced. And if the cloud provider tells you it is, "and here's the source code", you can't simply believe because you can't make sure of it, you can't see it in the runtime machine. You don't own that.

Now everyone is talking about moving to the Cloud. What will happen if everyone moves their application to some kind of Cloud? In a very extremist view, there would be no more software for on premise deployments, including Open Source. Or at least these would reduce drastically. There would be only... Open Standards.

Which in fact is what developers need these days for Cloud Computing: Open Standards. We all want to be able to move applications from a vendor to another, all it takes is to the other vendor support the same APIs that I require. Are Open Standards the future for Cloud Computing? APIs for SaaS (REST APIs), platforms for PaaS (Java EE), and standards for IaaS (OpenStack)?

Here's another interesting article that also talks about this: Open Standards are the key to True Cloud. Not Open Source Stacks.

I agree with Bruno Souza, where we quickly discussed the ideas I shared here. Open Source will live forever, and it will be the place where Open Standards will probably come up from. It is a de facto. This is how the JCP already works for example.

Which brings us to another question: will Cloud drive the openness characteristic of Open Source less open, and focus more on ideas for Open Standards? Will the Cloud business suggest Open Source as initial implementations for those ideas? What do you think?