- les journées Microsoft Techdays 2010 : présentation des nouveautés,
- Visual Studio 2010 met la barre très haute : Microsoft à écouté les remarques de ses utilisateurs,
- les 10 raisons (de la part de Microsoft) pour lesquelles HTML 5 ne remplacera pas Silverlight,
- interview de Mark Reinhold au sujet du JDK 7, les objectifs sur la JVM,
- sortie d'un COTS de transaction mémoire : Multiverse STM, c'est une solution qui implémente les propriétés ACID, et qui gère le thread safe à la place du développeur. Un projet à suive de près.
- Les technologies du cloud computing ont besoin d'un service de notification : une API d'événement.
- des articles au sujet de la réunion des architectures SOA et EDA : ED-SOA.
- Java Enterprise Edition 6 avec les EJB 3.1 : un très bon exemple qui illustre le principe qu'il vaut mieux avoir une convention plutôt qu'une configuration (convention over configuration).
- Les règles de compatibilité ascendante en Java : compatibilité au niveau code, binaire et exécution. Ce sont des règles écrite par IBM et proposées sur le site d'eclipse.
Microsoft Techdays 2010 (1/3)
Les Techdays sont l'occasion pour Microsoft de présenter chaque année à ses utilisateurs, du plus geek au plus boss, sa gamme de produits, d'outils sous forme de présentations, d'ateliers ou de retour d'expérience. Difficile de couvrir complètement cet événement tant l'offre de sessions est pléthorique, nous vous proposons donc, à travers une série de posts, sur les sessions que nous avions choisi et de partager avec vous notre ressenti. Ce premier post revient plus particulièrement sur le lancement des nouveaux frameworks.
VS 2010 met la barre très haute
Cette semaine, Microsoft a rendu disponible la tant attendue Release Candidate de VS 2010. Pour avoir testé la béta 2, je faisais partie de ceux qui étaient en faveur d'une révision générale des performances. Après avoir testé intensivement cette nouvelle mouture, je crois qu'on peut le dire haut et fort : Microsoft a écouté la communauté. Cette RC est un vrai bijou.
Top 10 Reasons why HTML 5 is not ready to replace Silverlight
Note: I know this topic is controversial, so I want to preface that this article is meant to be a conversation. If you don't agree with something or I have information incorrect, please add a comment or e-mail me. As the HTML 5 spec evolves, I will update this article. HTML 5 is the next update to the HTML standard that powers the web. There are many new exciting features being added like the the canvas element, local offline storage, drag and drop and video playback support. HTML needed to evolve and added these features in order to stay relevant as the de facto markup language that can provide a rich web experience.
OTN Tech Cast LIVE: Justin Kestelyn Interviews Mark Reinhold
Yesterday, in a live Tech Cast event on the Oracle Technology Network (OTN), Justin Kestelyn interviewed Mark Reinhold. The interview is currently available in full bandwidth, and it will be available in Brightcove and audio-only versions within the next few days. [Note: a lower bandwidth edition is now available athttps://channelsun.sun.com/media/show/15028.] If you are familiar with Mark's work, you'll not be surprised to find that Java 7 was the central topic of conversation.
Attendance at the live event peaked at about 80 people. The interview occupied about 30 minutes, and included a question and answer period where Mark addressed questions from the audience that were submitted via Facebook or Twitter.
Mark cited four primary objectives for Java 7:
1. Modularity - make Java scalable downward, for customizable use on small devices; this will also address the "jar hell" problem once and for all
2. Multilingual support
3. Make Java a more productive language, through improvements like Project Coin, the new diamond operator, strings and switch, and JSR-203 (NIO.2)
4. Performance improvements - Hotspot and JRockit VM development, parallel array, closures (which will make implementation of parallel array structures much more convenient)
In response to a question from Justin, Mark said that upcoming Milestone 6 release will likely include the diamond operator and strings and switches, and subsequent near-term milestone releases will include a new Python-like syntax for initializers and elements from Project Jigsaw (modularity).
After a brief discussion of the history of the closures debate, the floor was opened to questions.
Multiverse STM 0.4 released
Multiverse is an Open Source (Apache 2 License) Software Transactional Memory implementation for the Java platform that has been under development for the last 18 months. One of the big goals for the 0.4 release was to move from a cool project to a really usable product.
Although traditional lock based concurrency control is very powerful (the internals of Multiverse rely on it), it also is very complex and error prone. The idea of (Software) Transactional Memory is to rely on transactions to prevent isolation problems and I see STM's as filling the gap between traditional lock based concurrency and traditional databases.
* optional readonly transactions
* optional read tracking
* blocking primitives like the retry/orelse for creating blocking data-structures likes stacks or queues.
* optional field level granularity
* optional writeskew prevention
* compensating and deferred task execution
* nested transactions
* basic Scala integration
* commit barriers to realise lightweight 2 phase commits.
* transactional data-structures (List, BlockingQueue, BlockingDeque)
* transactional executor
* transactional references and primitives
The goals for the 0.5 release (expected in 8 to 12 weeks):
* commuting operations (needed for better scaling data structures)
* more transactional data-structures (tree e.g.)
* non blocking transactions; similar to non blocking io where one thread can execute more than 1 transaction.
* compile-time bytecode transformation (so no need for a javaagent)
* lots of performance improvements
Long term goals:
* many more performance improvements
* transparent persistence
* distributed transactions and distributed transactional objects.
* JEE integration (JTA/JPA etc)
* entering the eXtreme Transaction Processing arena
* contention Management
* seamless Scala & Groovy integration
Check out the site for more information:
The Need for an Event-based API in the Cloud
Events/alerts/notifications have been a central concept in IT management at least since the first SNMP trap was emitted, and probably even long before that. And yet they are curiously absent from all the Cloud management APIs/protocols.
Event-Driven Architecture and Service-Oriented Architecture
This paper explores what event-driven architecture is, and how it relates to service-oriented architecture and enterprise service bus.
Event-Driven SOA Architecture Overview
Event-Driven SOA. In the first interaction, the occurrence of an event (a notable thing that happens inside or outside your business) can trigger the invocation of one or many services. Those services may perform simple functions, or entire business processes. This interaction between events and services is commonly referred to as event-driven SOA.
(1) the fusion of SOA and EDA into ED-SOA (event-driven, service oriented architecture) is the way of the future,
(2) building processes is greatly facilitated by ED-SOAs,
(3) conversely ED-SOAs can be constructed as layered architectures using BPM systems.
(4) CEP principles must become an integral component of both ED-SOAs and business processes because of the ever increasing quest for control of our business processes, real time autonomous operation, and the need to gather business intelligence from the events flowing through our IT systems.
Java EE6: EJB3.1 Is a Compelling Evolution
The Enterprise Java Bean 3.0 (EJB 3) specification marked a very important way-point in the long march of Java in the enterprise. The specification was built very apparently with input from the community. It represented a much more consistent services paradigm, one that was more POJO-friendly and generally less complicated. The level of indirection afforded by Java 5's annotations made the paradigm more powerful while requiring less of the developer. The willingness to forsake bad legacy decisions for different, new solutions, made the framework interesting to people who might have previously shunned EJB. EJB Entity Beans disappeared, replaced with JPA Entities. The handful (or more) of Java classes and interfaces required for your average bean in EJB 2.1 or before became 2+ Java classes or interfaces. Convention-over-configuration based defaults were put into place to make it more straightforward to get up and running. EJB 3.0 was a revolution.
New Features in EJB 3.1
- The EJB Timer
- No-Interface Views
- Asynchronous Services
- Simplified Deployment
Evolving Java-based APIs
This document is about how to evolve Java-based APIs while maintaining compatibility with existing client code. Without loss of generality, we'll assume that there is a Component with a Component API, with one party providing the Component and controlling its API. The other party, or parties, write Client code that use the Component's services through its API. This is a very typical arrangement.
Achieving API Binary Compatibility