In other words, with PhoneGap, you write a normal web app and then drop it into native app wrappers for the various platforms. With all of the other cross-platform mobile options, you write code based on a proprietary framework that will only run as a native app.

For example, you can write a Titanium Mobile app using Appcelerator’s proprietary framework to create native apps. But Titanium Mobile won’t output your app in a way that will also run in a mobile browser.

Call me crazy, but I see the standards-based mobile web as the future of mobile computing. I don’t advocate cross-platform development approaches that conflict with this view.

Another thing to consider is the number of supported platforms. Titanium Mobile, for example, only supports iPhone and Android. As I write this, PhoneGap supports iPhone, Android, Palm, Symbian, Maemo, Windows Mobile, and Blackberry. And iPad and Windows Phone 7 are coming to PhoneGap soon.

If you have a big mobile project coming up, it would be a good idea to investigate your options. Ultimately, the best approach will depend on your target market and goals. My general advice to developers is that if you can build your app with standard HTML, CSS, and JavaScript, then you probably should leverage standards based technology.

I recently have some good conversation from my visit to Google I/O on the “eventual consistency” model. There is a general design pattern that I want to capture here.

The definition of data integrity

“Data integrity” is defined by the business people. It needs to hold at specific stages of the business operation cycle. Here we use a book seller example to illustrate. The data integrity is defined as …

Sufficient books must be available in stock before shipment is made to fulfil an order.

The application designer, who design the application to support the business, may transform the “data integrity” as …

Total_books_in_stock > sum_of_all_orders

The app designer is confident that if the above data integrity is observed, then the business integrity will automatically be observed. Note here that “data integrity” may be transformed by the application designer into a more restrictive form.

Now, the designer proceeds with the application implementation … There are 2 approaches to choose from, with different implications of scalability.

The ACID approach

One way of ensuring the above integrity is observed is to use the traditional ACID approach. Here, a counter “no_of_books_in_stock” is used to keep track of available books in the most up-to-date fashion. When every new order enters, the transaction checks the data integrity still holds.

In this approach, “no_of_books_in_stock” becomes a shared state that every concurrent transacton need to access. Therefore, every transaction take turns sequentially to lock the shared state in order to achieve serializability. A choke point is created and the system is not very scalable.

Hence the second approach …

The BASE approach

Instead of checking against a “shared state” at the order taking time, the order taking transaction may just get a general idea of how many books is available in stock at the beginning of the day and only checks against that. Note that this is not a shared state, and hence there is no choke points. Of course, since every transaction assumes no other transaction is proceeding, there is a possibility of over-booking.

At the end of the day, there is a reconciliation process that took the sum of all orders taken in the day, and check that against the number of books in stock. Data integrity checking is done here, but in batch mode which is much more efficient. In case the data integity is not maintained, the reconciliation process fire up compensating actions such as print more books, or refund some orders, in order to reestablish the data integrity.

Generalizing the Design pattern of BASE

“Eventual consistency” is based on the notion that every action is revokable by executing a “compensating action”. However, all compensating actions different costs involved, which is the sum of this individual compensation plus all compensating actions that it triggers.

In BASE, the design goal is to reduce the probability of doing high-cost revokation. Note that BASE is a probablistic model while ACID is a binary, all-or-none model.

In BASE, data is organized into two kinds of “states”: “Provisional state” and “Real state”.

All online transactions should only read/write the provisional state, which is a local, non-shared view among these transactions. Since there is no shared state and choke point involved, online transactions can proceed very efficiently.

Real state reflects the actual state of the business (e.g. how many books are actually in stock), which always lacks behind the provisonal state. The “real state” and “provisional state” are brought together periodically via a batch-oriented reconciliation process.

Data integrity checking is defer until the reconciliation process executes. High efficiency is achieved because of its batch nature. When the data integrity does not hold, the reconciliation process will fire up compensating actions in order to reestablish the data integrity. At the end of the reconciliation, the provisional state and real state are brought in sync with each other.

To minimize the cost of compensating actions, we need to confine the deviation between the provisional state and the real state. This may mean that we need to do the reconciliation more frequently. We should also minimize the chaining effect of compensating actions

For Enterprise developers, the major news is that the first Enterprise OSGi specification is reaching finalization. Although the OSGi Enterprise Expert Group (EEG) website doesn’t give much details about the specs, you can find draft v4 on the Apache Aries, more on that project later. This draft specification also contains interesting annotations from reviewers by the way, recommended to do a quick scan of this document.

The new specification defines how several JEE specs should work in a dynamic OSGi environment. The JEE specs that are chosen are for example the JPA spec (Java Persistence API), JMX (Java Management Extensions), JDBC (Java Database Connectivity), the JTA (Java Transaction API) and JNDI (Java Naming and Directory Interface). Although the OSGi Enterprise specification doesn’t cover all of the JEE APIs, it does cover the most important ones, more than enough for most Enterprise applications.

On top of the OSGi-ified JEE APIs, there are some new concepts introduced in the Enterprise OSGi specs. The most important one is the standardization of .wab files, which are OSGi versions of .war files. You need to add some descriptors, and then you can deploy those .wab files like regular OSGi bundles, including life cycle and dependency management. Regular .war files are also supported, they need to be transformed transparently and on the fly by the OSGi container to .wab files. Last year there were several vendors already experimenting with server side bundles, and using different APIs and even different file extensions (like .par and regular .jar), it’s great to see a standard here.

Another new feature is remote OSGi, which enables you to use exported services from an OSGi bundle in a remote Virtual Machine. This gives new possibilities for distributed solutions, for example to solve scalability or redundancy issues. As a bundle developer you already need to develop with the possibility in mind of not available services, in effect a poor mans ‘design by failure’ approach, which works great in a distributed environment.

To facilitate, experiment and learn from the new specs and its uses, two projects are started: Apache Aries and Eclipse Gemini. Both projects have approximately the same goal: provide implementations of the Enterprise OSGi specifications, create examples and create a community. Apache Aries is in incubation and sponsored by IBM and SAP, Eclipse Gemini is sponsored by Oracle and SpringSource.

To top it all of, SpringSource is in the process of donating its open source OSGi container to Eclipse, and renamed it from SpringSource DM to Eclipse Virgo. This container serves as the reference implementation for the Enterprise OSGi specification. This also means that the license is moved from the restrictive GPL to a more open EPL license.

Almost all Enterprise container vendors like JBoss, Glassfish, Oracle and IBM were already building the application server on top of OSGi, but didn’t expose OSGi to the enterprise application developer, or did expose it, but with proprietary APIs, therefore locking in the developer and hindering further adoption in the larger Java EE space. With the new Enterprise OSGi specification, developers can use the power of OSGi, without being locked in, which is great.

So all new specifications to get rid of vendor lock in, various implementations of these standards, open and closed source, community to work with, is this all good news then? No, sadly it’s not.

Adoption from ‘old’ Java EE users is slow. In part because of the technical challenge: Java has been monolithic of nature from the very beginning, and adding modularization to a very stable, mature platform is hard. It will take time and determination to solve all the problems while in the mean time keeping an upgrade path for JEE users.

Another problem is that the Java industry has been taught for 15 years to think in monolithic architectures. Thinking in components and services architectures is a revolutionary, disruptive trend, which will take time and effort for those affected to learn and understand.

And the last issue is of more political nature: There is still tension between the JCP and the OSGi consortium. Both are defining standards, and are not necessarily in agreement of each others approach. With the takeover of Sun by Oracle, this might change. There is a real risk that new JEE specifications are defined without taking OSGi into account, and that would create the possibility of forking the Enterprise standards.

But even with the above remarks it’s clear that modularization is on the brink of a breakthrough in Java Enterprise Development. Especially for architects, this means thinking in complete new ways about their work and responsibilities.

While this deeply ingrained “technology mess” is too overwhelming to be dismantled and replaced, the truth is out there that and can be disentangled. By mapping physical data to logical information objects and technical functions to business activities, a canonical information and operational model can be elicited. To this end,  a business has to define its own, consistent ontology, which may partly be adopted from the normative nomenclature of this respective industry vertical (Health care, Financial and Insurance, etc..). The data in the underlying information systems (both silo’ed and horizontal), can be mapped to these canonical concepts using appropriate integration technologies and exposed as data or process centric SOA services. By analyzing the functional requirements of business processes, a set of logic centric services can also be identified.

In Service Oriented Architecture (SOA), the intricacies of applications and technology infrastructure are encapsulated behind well defined, self-describing service interfaces that exposed the contained information and functionality as reusable, context independent services. The underlying implementation of a service can be changed as long as the service contract is maintained. SOA services provide modular building blocks that can be composed to higher level constructs, e.g., orchestrations or composite applications. The coarse-grained modularity reduces inherent complexity of the enterprise architecture and improves business agility. The service abstraction insulates business changes from IT development and thereby bring more synergies between the business and IT life-cycles.

I will be writing on how to enable an agile SOA with BPM and Event Driven architectures in the next segment. Good day.

Spring enables you to enjoy the key benefits of JEE, while minimizing the complexity encountered by application code.The essence of Spring is in providing enterprise services to Plain Old Java Objects (POJOs). This is particularly valuable in a JEE environment, but application code delivered as POJOs is naturally reusable in a variety of runtime environments.

Spring in Context

Spring is a manifestation of a wider movement. Spring is the most successful product in what can broadly be termed agile JEE.

Technologies

While Spring has been responsible for real innovation, many of the ideas it has popularized were part of the zeitgeist and would have become important even had there been no Spring project. Spring’s greatest contribution — besides a solid, high quality, implementation — has been its combination of emerging ideas into a coherent whole, along with an overall architectural vision to facilitate effective use.

Inversion of Control and Dependency Injection

The technology that Spring is most identified with is Inversion of Control (or IoC), and specifically theDependency Injection flavor of IoC. Spring is often thought of as an Inversion of Control container, although in reality it is much more.

Inversion of Control is best understood through the term the “Hollywood Principle,” which basically means “Don’t call me, I’ll call you.” Consider a traditional class library: Application code is responsible for the overall flow of control, calling out to the class library as necessary. With the Hollywood Principle, framework code invokes application code, coordinating overall workflow, rather than application code invoking framework code.

IoC is a broad concept, and can encompass many things, including the EJB and Servlet model, and the way in which Spring uses callback interfaces to allow clean acquisition and release of resources such as JDBC Connections.

Spring’s flavor of IoC for configuration management is rather more specific. Consequently, Martin Fowler, Rod Johnson, Aslak Hellesoy, and Paul Hammant coined the name Dependency Injection in late 2003 to describe the approach to IoC promoted by Spring, PicoContainer, and HiveMind-the three most popular lightweight frameworks.

Dependency Injection is based on Java language constructs, rather than the use of framework-specific interfaces. Instead of application code using framework APIs to resolve dependencies such as configuration parameters and collaborating objects, application classes expose their dependencies through methods or constructors that the framework can call with the appropriate values at runtime, based on configuration.

Dependency Injection is a form of push configuration; the container “pushes” dependencies into application objects at runtime. This is the opposite of traditional pull configuration, in which the application object “pulls” dependencies from its environment. Thus, Dependency Injection objects never load custom properties or go to a database to load configuration — the framework is wholly responsible for actually reading configuration.

Push configuration has a number of compelling advantages over traditional pull configuration. For example, it means that:

• Application classes are self-documenting, and dependencies are explicit. It’s merely necessary to look at the constructors and other methods on a class to see its configuration requirements. There’s no danger that the class will expect its own undocumented properties or other formats.
• For the same reason, documentation of dependencies is always up-to-date.
• There’s little or no lock-in to a particular framework, or proprietary code, for configuration management. It’s all done through the Java language itself.
• As the framework is wholly responsible for reading configuration, it’s possible to switch where configuration comes from without breaking application code. For example, the same application classes could be configured from XML files, properties files, or a database without needing to be changed.
• As the framework is wholly responsible for reading configuration, there is usually greater consistency in configuration management. Gone are the days when each developer will approach configuration management differently.
• Code in application classes focuses on the relevant business responsibilities. There’s no need to waste time writing configuration management code, and configuration management code won’t obscure business logic. A key piece of application plumbing is kept out of the developer’s way.

Developers who try Dependency Injection rapidly become hooked. These advantages are even more apparent in practice than they sound in theory.

Spring supports several types of Dependency Injection, making its support more comprehensive than that of any other product:

• Setter Injection: The injection of dependencies via JavaBean setter methods. Often, but not necessarily, each setter has a corresponding getter method, in which case the property is set to be writable as well as readable.
• Constructor Injection: The injection of dependencies via constructor arguments.
• Method Injection: A more rarely used form of Dependency Injection in which the container is responsible for implementing methods at runtime. For example, an object might define a protected abstract method, and the container might implement it at runtime to return an object resulting from a container lookup. The aim of Method Injection is, again, to avoid dependencies on the container API.

Uniquely, Spring allows all three to be mixed when configuring one class, if appropriate.

Enough theory — take look at a simple example of an object being configured using Dependency Injection.

Assume that there is an interface — in this case, Service — which callers will code against. In this case, the implementation will be called ServiceImpl. However, of course the name is hidden from callers, who don’t know anything about how the Service implementation is constructed.

Assume that this implementation of Service has two dependencies: an int configuration property, setting a timeout; and a DAO that it uses to obtain persistent objects.

With Setter Injection you can configure ServiceImpl using JavaBean properties to satisfy these two dependencies, as follows:

public class ServiceImpl implements Service {
 private int timeout;
 private AccountDao accountDao;

   public void setTimeout(int timeout) {
     this.timeout = timeout;
   }

   public void setAccountDao(AccountDao accountDao) {
     this.accountDao = accountDao;
   }

With Constructor Injection, you supply both properties in the Constructor, as follows:

public class ServiceImpl implements Service {
 private int timeout;
 private AccountDao accountDao;

   public ServiceImpl (int timeout, AccountDao accountDao) {
       this.timeout = timeout;
       this.accountDao = accountDao;
   }

Either way, the dependencies are satisfied by the framework before any business methods onServiceImpl are invoked. (For brevity, there are business methods shown in the code fragments. Business methods will use the instance variables populated through Dependency Injection.)

This may seem trivial. You may be wondering how such a simple concept can be so important. While it is conceptually simple, it can scale to handle complex configuration requirements, populating whole object graphs as required. It’s possible to build object graphs of arbitrary complexity using Dependency Injection. Spring also supports configuration of maps, lists, arrays, and properties, including arbitrary nesting.

As an IoC container takes responsibility for object instantiation, it can also support important creational patterns such as singletons, prototypes, and object pools. For example, a sophisticated IoC container such as Spring can allow a choice between “singleton” or shared objects (one per IoC container instance) and non-singleton or “prototype” instances (of which there can be any number of independent instances).

Because the container is responsible for satisfying dependencies, it can also introduce a layer of indirection as required to allow custom interception or hot swapping. (In the case of Spring, it can go a step farther and provide a true AOP capability. Thus, for example, the container can satisfy a dependency with an object that is instrumented by the container, or which hides a “target object” that can be changed at runtime without affecting references. Unlike some IoC containers and complex configuration management APIs such as JMX, Spring does not introduce such indirection unless it’s necessary. In accordance with its philosophy of allowing the simplest thing that can possibly work, unless you want such features, Spring will give you normal instances of your POJOs, wired together through normal property references. However, it provides powerful indirection capabilities if you want to take that next step.

Spring also provides many hooks that allow power users to customize how the container works. As with the optional lifecycle callbacks, you won’t often need to use this capability, but it’s essential in some advanced cases, and is the product of experience using IoC in many demanding scenarios.

The key innovation in Dependency Injection is that it works with pure Java syntax: no dependence on container APIs is required.

Dependency Injection is an amazingly simple concept, yet, with a good container, it’s amazingly powerful. It can be used to manage arbitrarily fine-grained objects; it places few constraints on object design; and it can be combined with container services to provide a wide range of value adds.

You don’t need to do anything in particular to make an application class eligible for Dependency Injection — that’s part of its elegance. In order to make classes “good citizens,” you should avoid doing things that cut against the spirit of Dependency Injection, such as parsing custom properties files. But there are no hard and fast rules. Thus there is a huge potential to use legacy code in a container that supports Dependency Injection, and that’s a big win.

Aspect-Oriented Programming

Dependency Injection goes a long way towards delivering the ideal of a fully featured application framework enabling a POJO programming model. However, configuration management isn’t the only issue; you also need to provide declarative services to objects. It’s a great start to be able to configure POJOs-even with a rich network of collaborators-without constraining their design; it’s equally important to be able to apply services such as transaction management to POJOs without them needing to implement special APIs.

The ideal solution is Aspect-Oriented Programming (AOP). (AOP is also a solution for much more; besides, this article refers to a particular use of AOP, rather than the end all and be all of AOP.)

AOP provides a different way of thinking about code structure, compared to OOP or procedural programming. Whereas in OOP you model real-world objects or concepts, such as bank accounts, as objects, and organize those objects in hierarchies, AOP enables you to think about concerns or aspectsin your system. Typical concerns are transaction management, logging, or failure monitoring. For example, transaction management applies to operations on bank accounts, but also to many other things besides. Transaction management applies to sets of methods without much relationship to the object hierarchy. This can be hard to capture in traditional OOP. Typically you end up with a choice of tradeoffs:

• Writing boilerplate code to apply the services to every method that requires them: Like all cut-and-paste approaches, this is unmaintainable; if you need to modify how a service is delivered, you need to change multiple blocks of code, and OOP alone can’t help you modularize that code. Furthermore, each additional concern will result in its own boilerplate code, threatening to obscure the business purpose of each method. You can use the Decoratordesign pattern to keep the new code distinct, but there will still be a lot of code duplication. In a minority of cases the Observer design pattern is sufficient, but it doesn’t offer strong typing, and you must build in support for the pattern by making your objects observable.
• Detype operations, through something like the Command pattern: This enables a custom interceptor chain to apply behavior such as declarative transaction management, but at the loss of strong typing and readability.
• Choosing a heavyweight dedicated framework such as EJB that can deliver the necessary services: This works for some concerns such as transaction management, but fails if you need a custom service, or don’t like the way in which the EJB specification approaches the particular concern. For example, you can’t use EJB services if you have a web application that should ideally run in a web container, or in case of a standalone application with a Swing GUI. Such frameworks also place constraints on your code-you are no longer in the realm of POJOs.

In short, with a traditional OO approach the choices are code duplication, loss of strong typing, or an intrusive special-purpose framework.

AOP enables you to capture the cross-cutting code in modules such as interceptors that can be applied declaratively wherever the concern they express applies — without imposing tradeoffs on the objects benefiting from the services.

Spring AOP allows the proxying of interfaces or classes. It provides an extensible pointcut model, enabling identification of which sets of method to advise. It also supports introduction: advice that makes a class implement additional interfaces. Introduction can be very useful in certain circumstances (especially infrastructural code within the framework itself).

Here, the interest lies in the value proposition that Spring AOP provides and why it’s key to the overall Spring vision.

Spring AOP is used in the framework itself for a variety of purposes, many of which are behind the scenes and which many users may not realize are the result of AOP:

• Declarative transaction management: This is the most important out-of-the-box service supplied with Spring.
  * It can be applied to any POJO.
  * It isn’t tied to JTA, but can work with a variety of underlying transaction APIs (including JTA). Thus it can work in a web container or standalone application using a single database, and doesn’t require a full J2EE application server.
  * It supports additional semantics that minimize the need to depend on a proprietary transaction API to force rollback.
• Hot swapping: An AOP proxy can be used to provide a layer of indirection. (Remember the discussion of how indirection can provide a key benefit in implementing Dependency Injection?) For example, if an OrderProcessor depends on an InventoryManager, and theInventoryManager is set as a property of the OrderProcessor, it’s possible to introduce a proxy to ensure that the InventoryManager instance can be changed without invalidating theOrderProcessor reference. This mechanism is threadsafe, providing powerful “hot swap” capabilities. Full-blown AOP isn’t the only way to do this, but if a proxy is to be introduced at all, enabling the full power of Spring AOP makes sense.
• “Dynamic object” support: As with hot swapping, the use of an AOP proxy can enable “dynamic” objects such as objects sourced from scripts in a language such as Groovy or Beanshell to support reload (changing the underlying instance) and (using introduction) implement additional interfaces allowing state to be queried and manipulated (last refresh, forcible refresh, and so on).
• Security: Acegi Security for Spring is an associated framework that uses Spring AOP to deliver a sophisticated declarative security model.

• Alternate models for acquiring and delivering systems — such as the Web for global deployment — have begun to emerge, forcing organizations to rethink how they fulfill their needs for those systems.
• BPM-enabling technologies are making business processes explicit, addressing the increased business requirement for operational transparency.
• Open source has illuminated the value of having large groups of people working independently to solve software problems in a community fashion and won greater acceptance in corporate world.
• Web 2.0, SOA and cloud computing have broken up our systems into autonomous pieces, which can be stitched together to form solutions that break the constraints of what we formerly thought of as “applications (using concepts such as orchestration of services using BPEL and Service Component Architecture and rule based workflow decision making).”

About Services

Services should be designed by simplifying the components of your enterprise and making them easy for business to own them and reference them in their day-to-day business processes. Simplicity should be the key aspect and should not be confused with buzz words (vendor originated) and truly aligned with business key words. Simplification could take some effort but achievable with clear decomposition mind set.

Data

Service design should always consider the importance of Data and its context of usage. I have seen too many times where canonical models were established only to be withdrawn due to poorly federated design practices. One size doesn’t fit all is the key.  The data aspect ideally should be standardized amongst the business groups or domains. For e.g., P.O (purchase order) can potentially have 3 canonical forms in an enterprise along the lines of its decentralized units.

The key thing is to have a centralized or federal model for some services and demonstrate loose coupling by having shared services for others.

WS-* or REST

This is one topic that hits me the most… Both WS-* and REST are applicable models for distributed computing models that promote agnostic call-ins. The answer is “It Depends” approach based on what you are trying to solve.  REST provides an uniform interface approach and in my opinion, there are advantages to develop features in a quicker manner to things such as Micro-formatting, late binding and dynamic content negotiation approaches, etc. Either WS-* or REST, a fundamental design-first approach is essential for any successful SOA initiative.

Contract design

The new Bean Validation specification (JSR 303) makes validation simpler and reduces the duplication and errors. It provides a standard framework for validation, in which the same set of validation rules can be shared by all the layers of an application (web, controller, service, and domain layers).

I believe this feature will give completeness to the JSF spec and makes EJB 3.1.

• No-interface view: This simplifies the creation of an enterprise bean using only a bean class without having to write a separate business interface.
• Singletons: The new Singleton design, using the @Singleton annotation, lets you easily share state between multiple instances of an enterprise bean component or between multiple enterprise bean components in an application.
• Asynchronous session bean invocation: Using the @Asynchronousannotation, the session bean methods can now be invoked asynchronously.
• Simplified Packaging: The new packaging mechanism removes the restriction that enterprise bean classes must be packaged in an ejb-jar file. The EJB classes can now be directly placed in a WAR file.
• EJB Lite: This model is a subset of EJB 3.1 for inclusion in the Java EE profiles.

JAX-RS specification enables the development of lightweight web services that conform to the REST style of software architecture. It provides the API for building RESTful web services in Java with a set of annotations and associated classes and interfaces. Overall impressive considering the evolution from earlier versions of EJB 3.o and 2.x.