The session “Composite Application Design Patterns” was presented by Jurgen Opgenorth and Patrick Zimmer of SAP AG.

This session was excellent.  Opgenorth and Zimmer discussed common problems that occur when designing composite (i.e. SOA-based) applications, and their solutions.  They defined a pattern by explaining the problem, providing the solution, and listing the consequences of that solution.  The slides will be beneficial for this session, and will be posted when they become available.  I will list the patterns, but not go into any detail on how they were solved.

• Global Data Types: Web services are auto-generated from existing code, data types are arbitrarily defined making it hard to maintain consistency in data mapping.
• Compensation Service: Enterprise services are stateless and atomic.  Transactional rollbacks are impossible.
• Check Service: Related to the compensation service.  There is no way to determine whether a service completed successfully before continuing.
• Service Adaptation: Services are business driven, not consumer driven and may be too complex for th user interface.  The data they contain may need trimmed, filtered, sorted, or flattened before it’s usable.
• Back-End Abstraction Layer: Certain pieces of a service may be used in many other services a change in that piece causes many services to be affected.
• Object Work List: A User needs the ability to do searches with criteria outside of the normal built-in searches.
• Wizard UI: A series of sequential steps executed in one “go”.
• Delayed Write Operation: A persistence of data cannot occur until some other step completes. Writing first may cause the data to be in an inconsistent state.
• Externalized Rules: Business rules change more frequently and are used in many processes.

The session “Java Servlet 3.0 API: What’s New and Exiciting” was presented by Rajiv Mordani, SUN Microsystems.

The Java Servlet 3.0 API is defined by JSR 315 and will become part of the Java EE 6 specification.  This talk focused on the new features of the API.

The “web.xml” file will be optional.  JAR and WAR packages will now be able to contain their own “web fragment” definitions.  A web fragment will have the same structure as a “web.xml” file, but will be surrounded by the  <web-fragment> tag.

A number of ease of development features are going to be included.  Developers will be able initialize Servlets and Filters at run time (i.e. create them in code) instead of at start-up time.  Annotations and generics have been added to make Servlet and Filter creation much easier.  The annotation @Servlet(url-mapping=”/myservlet”) creates a new servlet and mapping.  The standard servlet methods @GET, @PUT, @POST, @DELETE, and @HEAD are also included.  For creating a filter use the annotations @ServletFilter, and @FilterMapping.

There will be new asynchronous servlet support.  Proposed inclusions are “Comet-style” persistent connections from server to client (allows the server to push content to the client).  Also, there is support and events for suspending, resuming and timing out a servlet request.  On the response side, a servlet response can either be enabled or disabled.

In the realm of security, and still under discussion, is the ability to login and logout programatically.  Also, proposed is an HTTP-only cookie that would prevent many cross-site scripting vulnerabilities.

A number of ease of development

The session “Top 10 Patterns for Scaling Out Java Technology-Based Applications” was presented by Cameron Purdy, Vice President, Oracle.  In this discussion, Purdy layed out 10 ways to scale  Java applications.  This session was very good, but the slides were jammed with information.  Purdy said that this was normally a 90 minute discussion crammed into 50 minutes.  He talked very quickly and it was very hard to take notes.  I will try to highlight the 10 “patterns”, but being able to see the slides when they become available will be very beneficial.

10. Understand the problem: Before trying to scale the application make sure that’s really the problem.  A scalability problem exists, if the application is fast for a single user, but slows down as more and more users access the application simultaneously.

9. He blew by this slide so fast, I missed it.

8. Architecture Trumps Technology: Don’t be misled into believing that some technology or language that was selected for the project is causing the scaling problem.  Any technology can be scaled.

7. Understand the Basics: Learn about messaging and distribution instruments and efficient uses of those technologies.

6. Visualize the Network: Understand routing, partitioning, and replication.

5. I missed this one, too … (I told you he was moving fast)

4a. Plan for Overload: Add load balancing where appropriate

4b. Partition for Scalability: Partitioning is the only way to scale in stateful systems.

3a. Plan for Failure: Try to build in fault tolerance.

3b. Replicate for Availability: Replication adds fault tolerance, but it can cost you performance.

2. Tier Where It Makes Sense:

1. Simplify: Unnecessary complexity makes finding problems difficult.

I will post the slides once they become available.

Today’s JavaOne General Session was presented by Intel.  Chris Mellisinos of SUN Microsystems introduced
Doug Fisher, Intel Vice-President

Fisher showed a video from Intel with the theme, “Software Unlocks Hardware”.
He showed a picture of a spiral, and said that innovation in hardware drives innovation in software which drives innovation in hardware.
Software initiatives in SaaS, the open source community, SOA, parallelism, Java, and virtualization all help to drive the hardware market.

Fisher talked about Intel’s “Tick Tock” cadence that they use to set the innovation pace.  The “Tock” is the innovation of a new micro-architecture for their chip set.  After about one year, the “Tick” occurs whereby Intel is able to shrink the current architecture.  The cycle then repeats itself.  Fisher said that if the diameter of the earth represented the first transistor ever made, today the earth would be the size of a marble.

Fisher said that Intel has a strong partnership with SUN, and is focusing work on making Solaris, Java, MySQL, OpenSolaris, NetBeans, and SUN Studio perform better on the Intel platforms.

Intel’s “Threading Building Blocks” API is used by developers to implement multi-core parallelism.  Fisher announced that the “Threading Building Blocks” API is now available for OpenSolaris using the SUN Studio.

Last year, the release of the Xeon processor resulted in a 20% performance gain for the Java VM.  With the new partnership between SUN and Intel, a team of SUN and Intel employees working on the same Xeon hardware were able to optimize the Java VM, and achieve a 68% performance gain.

Fisher then held up a small vial that contained 1000 of Intel’s new Atom processor.  The Atom processor is new architecture chip for mobile devices.  You can watch the “What If…” video at http://moblin.org.

The session “Introduction to Web Beans” was presented by Gavin King of Hibernate.

Web Beans provide a unifying component model for the Java EE platform by defining a program model compatible with EJB 3.0 and an extensible context model.  EJB 3.0 beans can be turned into web beans simply by adding annotations.  The same applies for JSF beans.  Web beans represent a loose coupling but a strong typing, and they unify the web tier with the enterprise tier.

A web bean can be any Java class, an EJB session bean, resolver methods, JMS components, or remote components.  They include a depolyment type, an API type, binding type, and a name.

A binding type is an annotation that lets the client choose between multiple API implementations.

A deployment type is an annotation that identifies a class as a deployed web bean that can be either enabled or disabled.  Deployment type also specifies precedence, and replaces verbose XML configuration.

Web beans can also specify scope and context through the use of annotations.  The built in scopes include @RequestScoped, @SessionScoped, @ApplicationScoped, and for JSF @ConversationScoped

Web beans are only available in Java EE 6 which is probably two years from market saturation.  In my opinion, this technology is a “wait and see”.

The session “The Java Persistence API 2.0″ was presented by Linda DeMichiel, SUN Microsystems. DeMichiel presented some of the features of JSR 317.  These features include more flexible modeling, expanded object relational mapping, additions to the query language, a criteria API, database hints, and validation support.

The Java Persistence API uses annotations in the Java code instead of XML configuration files.  Collections of basic types (Strings, Integers, etc.) can be expressed with the @ElementCollection annotation, and are stored in a collection table.  Collections of embeddable types also use the @ElementCollection annotation, but can be customize with the @AttributeOverride annotation.

Embeddable relationships can be expressed with the annotations @ManyToOne, @OneToOne, @OneToMany, and @ManyToMany and customized with @AssociationOverride annotation.

Ordered lists that are not persistent can use the @OrderBy annotation.  If however, you want to the ordering to persist, you would use the @OrderColumn annotation.

In the 2.0 spec, maps have been generalized both the keys and values can now be basic types, embeddables, or entities.

Automatic orphan deletion was added for related entities logically linked to a parent.  When the parent is deleted so are the children.  It is no longer necessary to specify “cascade=REMOVE”.

The query language has been expanded to include functions in the SELECT list, new modeling enhancements, and restricted polymorphism.

The session “AJAX and JavaServer Faces Technology: Natural Synergy” was pesented by Kito Mann, Virtua Inc.

Mann discussed simple ways to add AJAX to JSF applications without needing to know any AJAX or JavaScript coding.  He recommended “sprinkling a little AJAX in” by adding component libraries that already support AJAX.

Here are some of the vendor that have AJAX enabled components, both in the free and commercial markets: Simplica ECruiser, Infragistics NetAdvantage, ICEFaces, QuipUKit, RichFaces, Tomahawk, MyFaces, and Backbase.

Richfaces bundles the AJAX4JSF libraries.  These libraries allow you to wrap any component inside of AJAX without actually needing to know AJAX using the <a4j:support> tag.

Mann showed demonstrations of some of the vendor libraries that provide AJAX “on the inside” like ECruiser, ICEFaces, and NetAdvantage.

Next he showed products that provide support for AJAX “on the outside”.  In other words, these products wrap AJAX widgets from popular libraries like Yahoo and Google into JSF components.  Some of these include jMaki, YUI4JSF, DOJO Faces, and Mojarra Scales.

The session “Open Standards for SOA and Java Technology” was a panel discussion about Service Component Architecture (SCA). The moderator was David Chappell of Chappell & Associates. The panel included Michael Rowley of BEA, Steve Jones of Capgemini UK, Mike Edwards of IBM, David Chappell of Oracle (not the same person as the moderator, and neither of the David Chappell’s were the comedian of the same name), Mark Little of Redhat, Patrick Leonard of Rogue Wave, Sanjay Patil of SAP, Peter Walker of SUN, and Scott Vorthmann of Tibco.

Why is SCA useful?

SCA makes you think SOA. It helps with team organization, and it makes it easier to deliver SOA apps. When a team thinks SOA, they have a better clarity of communication.

What SCA products exist?

There are about five vendors in the market offering free open source solutions including Apache Tuscany and Fabric 3. There are commercial SCA products available from every vendor represented on the panel.

Why does the SCA specification overlap with Java EE 5?

SCA is not trying to compete with Java EE. Java EE is about a pure Java solution. SCA strives to allow deployment of components in an language neutral fashion.

What is open source’s role in SCA?

The open source community helps to promote technology saturation through its community of users. The open source reference implementations become the test beds for the API specifications.

Now that SUN is not in control of Java anymore, is there a fear that fragmentation will benefit Microsoft?

Many companies, including Microsoft, are combining heterogeneous technologies for their SOA solutions. With Microsoft, you get what Microsoft wants you to have (”Plato’s benevolent dictator”). In the Java world everyone is capable of contributing to the specification through the JSR process.

Are JBI and SCA competitors?

JBI sits at a lower level than SCA, handling more of the communication and protocol layer. There is some overlap, but SCA works well inside of a JBI container.

What are the best practices for doing SCA?

Define services first! SCA is an architectural and operational tool. You ultimately need to code the solution, but thinking about it first is the most important thing.

The birds-of-a-feather presentation “Designing and Building a Real-World Service-Oriented Architecture” was presented by Eben Hewitt of Discount Tire.

In my opinion, this was the best session that I have attended yet. The purpose of this presentation was to show how a service-oriented architecture (SOA) was implemented at Discount Tire.

Hewitt’s first slide simply said “SOA != SOD”. In other words, Service-Oriented Architecture is not the same thing as Service-Oriented Development.

Hewitt indicated that SOA is a kind of architecture that uses services as building blocks to facilitate enterprise integration and component reuse through loose-coupling. His company’s goals for SOA was to leverage existing code, reduce time to market, reduce complexity, and clarify maintainability.

The approach to SOA that Hewitt and his team took was to start with well-defined business initiatives and outcomes, deliver architecture and pilot services concurrently, and integrate, communicate, and educate developers every step of the way.

Their strategy was to create a central team that represented their “center of excellence”. This team would be fully responsible for the initial pilot, but they would educate and evangelize to the rest of the community through a reference architecture web site and a blog.

They had a three-year plan involving services, infrastructure, and governance. The services came first ignoring infrastructure and governance for the time being. The services encompassed the platform, tools, the bus, services, and data services. Once the services were established and functional, the infrastructure was defined that allowed for a repository of services, composites, and business process modeling. Finally, the governance piece was considered, which would determine real-time monitoring and change control.

Hewitt talked next about pilot selection. He recommended thinking about the following questions when deciding upon what to pilot:

• Does it create business value?
• Is it limited in scope?
• Would it be a good service?
• Would it be useful, but not mission critical?

Next, Hewitt talked about the toolset used for the SOA implementation. They chose Java SE 6 and Java EE 5 because it had JAX-WS 2.1 built-in. They also selected Glassfish, Open ESB, NetBeans 6 and Eclipse. All of these tools are free and provided an easy exit strategy, if things “went south”.

The team chose to use SOAP and WSDL instead of REST because it had wide industry support, free add-ons, a strong interface, and it was simplified with JAX-WS.

Open ESB was chosen because it was based on JBI. It had support for BPEL, and it was free.

Hewitt and his team decided that they wanted the architecture to be schema-based meaning that all communication mechanisms would be via XML. They introduced BPEL early, and it was used to totally decouple the business process from the code.

The team toyed with the idea of using UDDI for discovery of services, but that idea was “deferred to never”, because there is no one using UDDI. Even SUN couldn’t give them the name of anyone using UDDI. They realized they needed a repository of services so others would know what was available, but UDDI was definitely NOT the answer.

Only after they had a working model and design, did they even start talking about governance. The governance group was responsible for enforcing organizational policies and standards about services. It was very important to maintain a strategy with the business areas.

The session “Closures Cookbook” was presented by Neal Gafter of Google. Gafter is one of the proposers of the BGGA closures spec which is currently under review via JSR-166y to add closures to the Java 7 language.

A closure is an object represented by a code body and a lexical context. It’s an instance of an interface with very few restrictions. It can access local variables and “this”, and may return a value. Here’s a trivial example of the syntax in the BGGA closure spec:

Runnable r = {=> doWhatever();};
r.run();

One of the big benefits of closures is that you can replace large amounts of “boiler plate” code required to implement some interfaces (i.e. the same code needs to be written the same way in many places in an an application for such functionality as logging or a timing).

Another benefit is performing bulk computations over data in aggregates (arrays, lists, maps, etc.).  These computations are automatically parallelized.  Examples of these include sort, filter, map, reduce, and fold.

Closures also allow a developer to take advantage of concurrency without needing to code for it.

This session used many code examples, making it difficult to blog, but I will be sure to post the presentation slides as soon as they become available.