Digital Walkabout

SOA success, or lack thereof

<<Burton Group analysts spent the first few months of the year looking into SOA implementations and what they found was a landscape devastated by petty territorialism, lack of governance and the failure to involve the business.

According to Burton Group vice president and research director Anne Thomas Manes, some users had executed nearly perfectly in terms of doing SOA on the IT side, but the initiative had yielded no increased
agility, quicker time to market or project savings because the business remained completely oblivious to the initiative. Yet the study also found that users who do break down artificial corporate barriers, install proper governance and involve the business have runaway success stories to tell.

"The successes we found are just incredibly inspiring," Manes told attendees at last week's Burton Group Catalyst Conference.

She listed key attributes common to SOA success stories:

* Business and IT reorganization, usually with a new CIO coming on board
* Sponsorship at the C-level or by the Board of Directors
* Agile/iterative development methodologies put into place
* Projects tied to and measured by business goals, not IT drivers
* Well-defined funding and maintenance models that balance the needs of service providers and consumers
* A simplified architecture, making it easier to access and manage quality data
* A culture of trust between business and IT

Manes repeatedly returned to the issues of trust and culture. She placed the burden for creating that trust on the shoulders of the IT department.

"You're going to have to create some kind of culture shift," she said. "And you know what? You've been breaking their hearts for so many years, it's up to you to take the first step."

Cigna fails, then succeeds with SOA Chad Roberts, architecture director at Cigna Group Insurance, presented his company's experience with SOA. It started in 2004 with a technical focus mostly based on integration and rolled out its first successful project in 2005. Yet in 2006 a key project got cancelled
and the initiative ground to a halt.

"The perception of SOA being an IT thing was loud and clear," he said.  Then a new CIO got hired in 2007 and made culture change a priority.

"We had to realize that we have to think about the business first and technology second," Roberts said. "Whether we like it or not, we are order takers to the business. … If I'm a claims guy, the last thing I
want to do is talk to an IT guy about SOA and how that's going to help me in the future when I've got systems that are failing today."

Manes found repeatedly in her research that the "if you build it, they will come" approach to SOA wound up a failure and Roberts confirmed that, saying, "We stopped trying to build business cases for SOA, it
wasn't working. Instead use SOA to strengthen the existing business case."

What Cigna did was "nail the basics," making sure the acute pain points of the business were being addressed and that projects delivered as promised. Architects also visited the various business units to gain intimate knowledge of how the business actually works.

"We had to be able to act and communicate like a business person," Roberts said.

The IT department was reorganized by function across business domains and it identified which domains were service providers and which ones were service consumers. The result has been a full slate of SOA
projects rolling into production with real business gains attached to them.

Common factors in SOA failure Burton Group found a 50% complete failure rate in the 20 companies
that took part in the study. Another 30% were considered neither successful nor wholly failed.

"Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem," Manessaid. "It was just a bunch of Web services. … The service is only
built for one application and it's never going to be used again."

She noted that such projects amount only to a less efficient method of doing EAI. Instead she recommended users focus projects around quality data, systems modernization or business process automation.

Kinam Peter Kim, vice president of IT strategy and architecture, echoed Manes' disillusionment with integration-centric SOA, noting that his company did an inventory of its IT vendor products and
stopped counting when it reached 7,000.

"We decided to weed out and stop doing so many integration projects," he said. "What we needed was a simplified architecture."

Steven Warner, technical director at Northrop Grumman, emphasized that SOA, ideally, enables the technical implementation of a well-planned business process.

"BPM and SOA are like the peanut butter and the chocolate in the commercial the way they go together," he said.

Manes listed numerous other failure factors during her presentation, including:

* Lack of defined service models
* Infrastructure focus
* Governance only of SOAP-based systems, if that
* Failure of developers to leverage the runtime governance in place
* Initiatives led by and solely involving the app dev group
* Roadmaps lacking specificity
* Inability to measure ROI
* Project-centric culture
* An "I'm special" attitude

Manes mentioned that last point a few times during her presentation, noting that such a mindset can be "really devastating" to an SOA implementation.>>

You can read this at:

http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1319609,00.html?track=NL-110&ad=649093&asrc=EM_NLN_3958312&uid=5532089

Benefits of a Data Abstraction Layer

<<Abstract: Enterprises have complex information structures as a result of evolving applications and databases deployed through the years. In addition to modern databases, environments commonly include mainframes, outdated storage technologies and custom data sources.

Companies seeking increased agility and reuse through service-oriented architecture quickly find that making sense of widely distributed and disparate data is a major roadblock to achieving the benefits of SOA. To build a successful SOA, architects need to pour the foundation first – they need to begin with a data abstraction layer that makes sense of an otherwise chaotic data landscape.

Data abstraction leads to the ability to leverage physical data, no matter how it's structured, as new, logical schemas that exist only in middleware – creating a common data layer that architects can restructure as needed, rather than making costly changes to the physical database or core services.

This article examines the use of a common data layer leveraged through data abstraction, its key advantages, and the value and ROI it generates for enterprises that deploy a SOA.



Introduction

Companies use information technology to automate business processes in an effort to reduce costs, increase efficiency and provide better service to their customers. Over the years, new systems and applications have been deployed to address specific needs, most often without an overarching design. The result is a wildly diverse sea of data, spread across multiple systems, in different formats, and often times duplicated. This data is the lifeblood of a company and the core of any new business process.

Historically, the practice of automating a business process involved a large investment of time and money. If the business environment was stable and unchanging, then this large investment would deliver business value year after year, indefinitely. Today's businesses, however, face constant change caused by new regulatory requirements, fluctuating market expectations, mergers and acquisitions, and the desire to continually improve their overall operational processes. Because of the high reliance on IT, such changes in the business environment lead to changes in IT. As a result, the value of IT in this environment is largely measured by how quickly it can satisfy these new requirements.

The evolving architectural style of SOA offers hope for providing rapid implementation of new business requirements, enabling a company to be agile in the face of a changing market environment. An agile business is one that is not afraid of new requirements; rather, it sees change as an opportunity to surpass the competition by exploiting its ability to rapidly adapt to new environments and circumstances. It achieves market advantage by efficiently retooling to meet new challenges, avoiding impending business obstacles, and increasing its market share by competing and winning against less nimble competitors.

The single most important aspect of SOA is its ability to enable access to the enterprise data that powers the business processes. Without efficient access to data, the entire business suffers. A data abstraction layer reduces the architectural complexity required to provide access to enterprise data, and allows organizations to create and leverage services that support critical business objectives.



Managing Data for SOA

While the need to manage data is nothing new, recent IT trends have been emphasizing traditional techniques. Adoption of SOA in particular, while showing great promise for increased agility and reuse in the enterprise, calls into question old methods of accessing data.

The premise of SOA is that processing capabilities are built into callable chunks that roughly align with business operations such as "get auto policy," "process order," or "verify credit limit." Then, processes and applications are constructed by "orchestrating" these services into compositions that automate business processes. When this vision is realized, businesses can react to change quickly by simply re-orchestrating services rather than succumbing to the traditional six, 12 or even 18 month development cycles that are common with silo-based application delivery.

There are three main characteristics of services that drive the value of SOA: they are typically defined in business terms, loosely coupled, and coarse-grained. Specifically, this means:

•		Defining services in business terms helps align IT with business needs, allowing the business to use IT services as well-understood building blocks for business processes. For example, you might define a service as "update customer record" instead of "send MQ update."
•		Loose coupling is the notion that services should have minimal dependencies on one another. Loosely coupled services generally have a defined "contract" under which they interoperate. One service may change its implementation without affecting the other, as long as it continues to abide by the contract.
•		A service is coarse-grained when it delivers a significant piece of data given a limited interface. A service with a coarse-grained interface intentionally inhibits flexibility in favor of formalizing and standardizing a well-defined behavior and data set. For example, a service that provides a "get auto policy" operation might take a single parameter, the policy number, and return the policy document using the company's standard format.

The need for services to be loosely coupled, course-grained, and defined in business terms presents several important problems that must be solved for a successful SOA. Somehow, architects and developers must find a way to deal with the complexity and diversity of data in the back-end systems, develop representations of data at a suitable granularity, and define information objects in business terms, like "order," "customer," and "invoice."

It is worth noting the distinction between simply exposing data as services and truly building an SOA. Many applications are written without a data abstraction layer. Indeed, modern development environments for Java and .Net make it very easy to bind an application or service directly to a physical data source. While data services can often be quickly developed and delivered in this manner, this approach predictably results in services and consuming processes becoming tightly coupled to the underlying data. Any change in the data or the consuming processes causes a ripple effect throughout the entire stack.



Managing Complexity with a Data Abstraction Layer

Data abstraction hides the complexity of data by letting you define a new, better organized structure that exists only in the middleware. The result is that an application (or another service) can request the data in a well-organized, logical format, without having to worry about its actual physical layout. As an example, an application may request a customer record from the data abstraction layer. Data is fetched from potentially many data sources, transformed into the agreed logical structure, and returned to the calling application.

Various types of data abstraction layers are possible, each suitable for a particular purpose. Examples include a virtual database that presents a relational model of data that is "queriable" using SQL, and virtual spreadsheets that present back-end data for easy manipulation in a spreadsheet form. Broadly speaking, a virtual relational database maximizes the flexibility in the types of queries that can be issued, due to its rich query language. To provide data to services, however, the natural implementation of a data abstraction layer is to model the data in XML, which makes it an ideal fit for contemporary SOA implementations because the richness of data defined via XML Schema fully supports the creation of coarse-grained and loosely coupled services, defined in business terms.

An XML-based data abstraction layer solves both of our problems simultaneously: we hide the complexity of the back-end systems so that applications can avoid the messy details, and we provide data structures at an ideal level of granularity in support of SOA.

		Figure 1: A data abstraction layer hides complexity and supplies appropriate data to higher layers.

Modeling Data Using XML Schema

One of the obstacles to defining a data abstraction layer is the ability to properly model the data using XML Schema. Like any data modeling activity, this task carries a degree of difficulty requiring input from both technologists and business experts. In effect, the business messages that drive operations need to be defined. This is generally done through an internal XML modeling effort, resulting in a set of XML Schemas defining pertinent business messages, each of which becomes the subject matter of a service. As an example, a business analyst responsible for order processing knows what data elements are required as input to the order process. Working with a data modeler knowledgeable in XML Schema, they define an appropriate structure and data set representing the order.

Many industries have defined standard business structures using XML Schema (for example, ACORD for insurance, MDDL for capital markets, HR-XML for human resources). These standards have incorporated the "wisdom of the masses" to achieve comprehensive XML-based definitions of business information. Using industry-defined XML Schemas has the additional benefit of being able to leverage well-documented business vocabularies. Since these standards are achieved through consensus, the tradeoffs include the potential for bloated messages, and the need to customize elements specific to your business. All things considered, implementing a data abstraction layer based on industry standard XML definitions leads to quicker implementations and better interoperability.

Each business message defined using XML Schema becomes a contract between a service implementation and its consumers. The data abstraction layer is simply the combination of these services. To that end, anybody that can build a service which conforms to an XML Schema can build a data abstraction layer and reap its benefits. Many tools and technologies are available to assist in this effort, and generally the selection criteria shifts to secondary considerations, such as ease of use, design time metadata management, and runtime management support.



Data Abstraction Benefits

The potential cost savings for building a data abstraction layer for your SOA fall into a number of categories. First, if you are convinced that SOA in general provides the benefits that you are looking for, it only makes sense that you'll want "SOA done right." The mandate to deliver data aligned with business definitions requires that logic be defined and exposed in a data abstraction layer. A properly defined logical layer leads directly to increased reusability opportunities, perhaps the most fundamental of all SOA-related benefits. ROI analysis has convincingly shown that using a data abstraction layer dramatically reduces the cost of systems in the long run.

Perhaps the greatest benefits accrue due to the loose coupling achieved through a well-designed data abstraction layer. Alternate approaches of accessing data sources directly from applications, however easy development toolkits make this, inevitably lead to tight coupling and changes to the data or the application cause a ripple effect through many systems.

In contrast, the loose coupling available through a data abstraction layer provides long term cost savings by isolating many of these changes to the appropriate architectural layer. Physical data can be reorganized without affecting applications, as the "contract" between applications and data remains the same. Also, changes to the application can often be accomplished with modifications only to the data abstraction layer implementation. For example, if a new source is added to a customer's activity history, then that new source can be incorporated using the exiting formats, extending the implementation of the service without changing the interface contract.



Conclusion

As companies continue to pursue SOA benefits, implementers struggle with the fundamental mismatch between the logical data organization that a service should expose, and the diverse and often chaotic nature of data in its physical form. The solution to this dilemma is a data abstraction layer that hides the complexity of back-end data sources while providing a common information model better organized and positioned to meet the needs of service-oriented architecture.>>

You can find this at:

http://www.soamag.com/I19/0608-2.asp

SOA Case Studies

<<We at SearchSOA.com have a number of SOA user stories in the works at the moment and it strikes me that we could just about churn out a case study a day at this point in time. Last month at the IBM Impact conference, I blogged that seemingly every type of business imaginable has been embracing service orientation.
We’re encountering more big SOA projects than ever before and you’ve got to wonder what the working rationale is these days for an app dev project that isn’t loosely coupled and conformant with an enterprise architecture. What’s the counter argument? Obviously it can be less expensive in the short term and less complex to throw applications together in piecemeal fashion, but over time that approach becomes costly. It’s also a mess from an engineering standpoint.
Here are some of the most recent examples:
Cars.com turned to SOA to help it with rapid growth
Deutsche Post used service orientation to blend Java and .NET apps in a CRM system
Con-way plans on building mobile apps for its transportation fleet based on the composite development its pursued over the past decade
Business process orchestration has become a key for online real estate company Move Inc.
SOA taught the Delaware Electric Cooperative the importance of BPM
Insurance industry information provider MIB Inc. rebuilt its entire business around SOA
You can find links to 18 other SOA case studies in our top stories of 2007 compilation. The number of users who can document proven success with SOA is exploding. Does it deliver as advertised in every situation? No, nothing does and that’s why we go out and try to find the users with best practices to share. This is a complex field, but the ranks of users who’ve found the benefits justify tackling the complexity are growing almost daily.
Here’s a question for those who don’t count SOA as a core competency in their app dev shop: why?>>

You can find this at:

http://soa-talk.blogs.techtarget.com/2008/05/19/look-whos-using-soa/?track=NL-130&ad=641022&asrc=EM_USC_3674889&uid=5532089

What is SOA?

I have encountered a number of debates across various fora, the latest dealing with "WOA" vs. "SOA".

It is fair to say that in the wider IT community, never mind the business, many are confused by all the different acronyms, conference topics and marketing initiatives that are around. In the USA at least, it seems to have reached the stage where "Companies hire SOA consultants, sue SOA consultants for being over-priced and over-promised, and now both companies have to hire SOA consultants to define SOA in court..."

A blog post from Paul Wallis of Stoma Software struck me in this respect, as it covered the basic concepts of SOA quite well: http://www.keystonesandrivets.com/kar/2008/04/understanding-s.html. Paul explains simply how SOA works, how it can be used and, with the use of a real-world example, describes why a properly planned and implemented Service Oriented Architecture can create a flexible way of aligning business and IT.

MAX 2008 Call for Topics is open

The official Adobe MAX 2008 Call for Speakers and Sessions has been opened - the best and most innovative topics and presentations are being sought for MAX 2008 in North America, Europe, and Japan. The event will take place in San Francisco, Milan and Tokyo. This is a great opportunity to present and discuss the bleeding edge in Adobe RIA, Web and SOA technologies and their application. As such, post a session that you would like to present or attend at Adobe MAX 2008.

Thanks for helping making Adobe MAX 2008 a success.

Architecting a Flex app

Architecting a Flex App

Web developers who take Flex for a spin may initially be confused by the user interface model. Although a typical, servlet-style, request-response model will work in Flex, There Is A Better Way. Thanks to the "[Binding]" tag in the Actionscript language, you can bind your view to your model data so that changes to the model are automatically reflected in the view. The Cairngorm microarchitecture formalizes this approach, and is a great starting point for developers who want to figure out how to "make it all work together". In this post I'll describe how variable binding, feature-driven development, and Cairngorm all work together for NoteTag.

Here's how a typical, non-trivial Flex app might be architected:

Domain

The classes that make up the domain model. In NoteTag, this includes Notes, Tasks, and Subscriptions. (A Subscription is a collection of related Notes or Tasks.)
Model

A Singleton that holds bindable instances of the domain model. In NoteTag, the ModelLocator Singleton holds the user's list of Subscriptions, the user's Connections, the current Subscription, the current Note, etc.

View

The UI components (generally, though not always, MXML files). The UI components that are state-dependent are bound to instance variables in the ModelLocator. Any changes to data in the ModelLocator will cause the UI to automatically update, provided that that data is marked as "[Bindable]". An example in NoteTag is the NoteListView, which presents the list of Notes in the current Subscription. If the current Subscription or any of its Notes change then the NoteListView will automatically update to reflect the changes.

Controller

Infrastructure for implementing features as event-driven Commands. Examples in NoteTag include GetSubscriptionCommand, GetNoteCommand, etc.

Business

Business logic classes perform operations on Domain objects, often making calls to remote services and returning the results asynchronously. The SubscriptionManager class is the entry point for most of NoteTag's business logic.

Service

The services layer, which holds all classes that are used to make remote service (HTTPService, RemoteService, and WebService) calls. NoteTag uses a set of service factory classes, which decouple the configuration of specific HTTP services from the components that make calls to HTTP services.
Most application features touch on some or all of these components. Here's the workflow for a typical feature:

• The View broadcasts an event.
• The singleton Controller receives the event, maps it to its corresponding Command, and executes the Command.
• The Command delegates to the appropriate Business object to perform the business logic.
• The Business object performs the business logic, possibly making one or more asynchronous calls to various Services, and returns the result by dispatching a new event to the Command.
• The Command assigns the result to the singleton Model.
• Any Views that are bound to the data in the singleton Model are automatically updated.

So how would this work for a specific feature? When the user selects a Note from the list of Notes (at the top of the screen, below), the Note is loaded from the appropriate repository (Blogger or TypePad) and displayed in the editor (at the bottom of the screen, below):

1. Broadcasting the Event

When the user clicks on the first Note in the list, NoteListView dispatches an event, as follows:

// NoteListView.mxml
private function getSelectedEntry(event:ListEvent) : void {
    var selectedEntry:TagBasedEntry =
    TagBasedEntry(currentFeed.entries[event.rowIndex-1]);

    Application.application.dispatchEvent(
    new GetNoteEvent(selectedEntry.metadata,true));
}

2. Responding to the Event

Because NoteTag's Front Controller has registered itself to listen for all Command Events, it will be notified when GetNoteEvent is dispatched:

// NoteTagController.as
public class NoteTagController extends FrontController {
    public function NoteTagController() {
        addCommand(LoginEvent.EVENT_LOGIN, LoginCommand);
        addCommand(GetNoteEvent.EVENT_GET_NOTE, GetNoteCommand);
        addCommand(GetTaskEvent.EVENT_GET_TASK, GetTaskCommand);
        addCommand(PostNoteEvent.EVENT_POST_NOTE, PostNoteCommand);
        // more commands...
    }
}

Cairngorm's FrontController provides the infrastructure for listening for events and responding to them by executing the appropriate command.

3. Executing the Command

To retrieve the Note, NoteTag needs to make a call to the blog server that stores the user's notes. The GetNoteCommand, which implements Cairngorm's Command interface, takes care of this:

// GetNoteCommand.as
internal class GetNoteCommand extends ChainedCommand {
    public override function execute(event:CairngormEvent):void {
       var initialEvent:GetNoteEvent = GetNoteEvent(event);

        var subscriptionManager:SubscriptionManager =
            ModelLocator.getInstance().subscriptionManager;

        setNextEventHandler(subscriptionManager,
                                        handleLoadNote,
                                        LoadNoteEvent.EVENT_LOAD_NOTE,
                                        onSubscriptionFault,
                                        SubscriptionFaultEvent.EVENT_SUBSCRIPTION_FAULT);

        subscriptionManager.loadNote(initialEvent.metadata);
    }

    private function handleLoadNote(event:LoadNoteEvent):void {
        // handle result here...
    }

    // ...
}

(You may have noticed that GetNoteCommand extends ChainedCommand -- this class chains asynchronous calls together using the setNextEventHandler method. In another post, I'll go into greater detail on ChainedCommand, and asynchronous responders in general.)

4. Executing the Business Logic

The SubscriptionManager handles the loading of the Note by executing a series of HTTP service calls to the tag server and the blog server. When the note has been loaded, the SubscriptionManager will dispatch a LoadNoteEvent, which will be handled by GetNoteCommand.handleLoadNote (see the next item).

5. Updating the Model

GetNoteCommand responds to the event by assigning the loaded Note to the appropriate data member on the ModelLocator:

// GetNoteCommand.as
internal class GetNoteCommand extends ChainedCommand {
    // ...

    private function handleLoadNote(event:LoadNoteEvent):void {
        ModelLocator.getInstance().currentNote = event.note;
    }

    // ...
}

6. Updating the View

Any views that are bound to the ModelLocator's currentNote member will automatically update themselves to reflect the new data. NoteView, the component that's responsible for displaying the Note in an editor, is one such view:

// NoteView.mxml
xmlns:view="com.adobe.kiwi.notetag.view.*"
xmlns="*">

note="{model.currentNote}" />

Every other feature -- publishing a Note, fetching a Subscription, updating a Task -- is implemented with the same Event-to-Command-to-Model-to-View approach. Command-specific Events can be dispatched from multiple contexts, without knowing which Views will be affected. Views can bind to Model changes without knowing where the originating Event was dispatched from. Loose coupling leads to cleaner, more maintainable code.

Stating the obvious - "Enterprise 2.0"

The article "The Connected Generation" takes something most of us have known for years and brings it to the attention of the broader audience - business applications need to support instant and text messaging, the tool of choice for teen communications.

However, I see a more subtle message - Web 2.0 and Mashups which include the IM/SMS *paradigm* are the choice for new business applications. We have already seen this with BPM environments such as that from Vitria, Collaboration environments such as Adobe Connect, C2C systems as the eBay Desktop, and virtual/mobile CRMs as SalesForce. The ability to apply IM/SMS workflows to business applications - not speaking specifically to IM/SMS protocols - through feeds (e.g. Twitter, Pownce) - has been proved an essential collaboration capability.

In BPM, the ability to instantly communicate across roles in the development of business processes (Business analyst <-> Technical analyst <-> IT) while working on the same model (filtered through different perspectives) is an order of magnitude more efficient than what many businesses practice (whiteboard <-> visio diagramme <-> excel spreadsheet <-> word document, all in some non-electronic form, and with plenty of room for interpretation at each boundary).

The collaborative BPM environment is essentially a mashup of a 'chat' feed with other RIA components such as an unified modelling environment, policy and resource management, lifecycle management and MDA/EDA information architecture. Providing an unified model structure from which each role can analyse their particular focus in the process yet work with the same underlying artefacts and easily communicate amongst one another is a very powerful concept.

Similarly, we have had some time to digest power collaboration environments such as Adobe Connect, which provide the same IM/SMS workflows to Collaboration and eLearning. The ability to use 'chat' capabilities combined with bots which enable polling and decision taking, along with multiple parties to interact with the same content take the ability to collaborate to the next level. For aglilies, imagine being able to buddy review code as if you were right next to your buddy, without having to be there, since you both can control the shared environment.

I do suspect that it will take more of the "teen" presence in technology to drive this. The current generation of software professionals coming in from the universities will have enough experience with Web 2.0 communications to see their value. Together with technical leadership which is quite on top of Web 2.0, they can prompt the middle tier - the previous generation of engineers who are still fond of "sneakernet" - to take a second look at things. Change can be good. If outsourcing has proved anything, it is that with proper operating mechanisms, remote workforces can function efficiently. If you can rely on engineers working remotely at the other end of the earth, there's no reason you can't rely on engineers working remotely in the same time zone. And with "teen"s bred on network gaming, IM and SMS on a global, we can expect more of Web 2.0 driving a more adaptable and flexible workforce.

Using Flex, BlazeDS and Spring

Flex is rapidly becoming the preferred technology for building groundbreaking internet applications delivered in the browser and on the desktop (using the AIR runtime). For several years, Spring has been one of the most popular frameworks for building the Java back-end of internet applications. In this post is described how to use BlazeDS Remoting to seamlessly integrate the two technologies and build state-of-the-art internet applications made of a Flex front-end and a Spring back-end. To leverage the examples therein, download and install BlazeDS, the Spring framework and the Adobe Flex 3 Sample files.

Whether you are a Flex developer with limited knowledge of Spring, or a Spring developer with limited knowledge of Flex, you can benefit from the powerful integration of these products. This post describes how BlazeDS enables a tight integration between Flex and Spring, and provides background information on the technologies at play.

Spring is one of the most popular Java frameworks. The foundation of the Spring framework is a lightweight component container that implements the Inversion of Control (IoC) pattern. Using an IoC container, components don't instantiate or even look up their dependencies (the objects they work with). The container is responsible for injecting those dependencies when it creates the components (hence the term "Dependency Injection" also used to describe this pattern). The result is looser coupling between components. The Spring IoC container has proven to be a solid foundation for building robust enterprise applications. The components managed by the Spring IoC container are called Spring beans. The Spring framework includes several other modules in addition to its core IoC container. These modules are not covered in this document even though we will be using the Spring JDBC abstraction framework in the second sample application below. More information on the Spring framework can be found at http://www.springframework.org.

Flex is an environment for building Rich Internet Applications. The Flex programming model is made of:

• ActionScript, an ECMAScript compliant, object-oriented programming model. With some syntactical differences, ActionScript looks and feels similar to Java, and supports the same object-oriented constructs: packages, classes, inheritance, interfaces, strong (but also dynamic) typing etc.
• MXML: an XML-based language that provides an abstraction on top of ActionScript, and allows parts of an application (typically the View) to be built declaratively with an extensive set of class libraries.

The Flex source code (.mxml and .as files) is compiled into Flash bytecode (.swf) that is executed at the client-side by the Flash virtual machine using a Just-In-Time compiler. The Flex SDK is an open source project. It includes the Flex component library, the compiler, the debugger, and the documentation. A complete discussion of Flex is beyond the scope of this document. You can find more information and download the Flex SDK at http://opensource.adobe.com.

BlazeDS is a set of data services that give your Flex applications additional options for data connectivity. Without BlazeDS (or, without deploying any Flex-specific component at the server-side), Flex applications can access back-end data using either the HTTPService or the WebService: You use the HTTPService component to send HTTP requests to a server, and consume the response. Although the HTTPService is often used to consume XML, it can be used to consume other types of responses. The Flex HTTPService is similar to the XMLHttpRequest component available in Ajax. You use the WebService component to invoke SOAP-based web services. BlazeDS adds the following services: The Remoting Service allows your Flex application to directly invoke methods of Java objects deployed in your application server. The Message Service provides a publish/subscribe infrastructure that enables your Flex application to publish messages and subscribe to a messaging destination, enabling the development of real-time data push and collaborative applications. The Proxy Service allows your Flex application to make cross-domain service requests in a secure and controlled manner. In other words, it allows your Flex application to access a service available on a different domain than the domain from where the application was downloaded (without having to deploy a crossdomain.xml policy file on the target domain). BlazeDS is deployed as a set of JAR files as part of your web application. Like the Flex SDK, BlazeDS is an open-source project. More information is available at http://opensource.adobe.com.

In this post, I focus on the Remoting service. The Remoting Service provides a tight and natural integration with Spring. There is no need to transform data, or to expose services in a certain way: the Flex application can directly access the beans registered in the Spring IoC container. How does Flex use BlazeDS to access Spring beans? So, if Flex clients can remotely access Java objects, and if Spring beans are Java objects, aren't we all set and ready to start accessing Spring beans from Flex clients? Almost… There is one simple element to configure. The whole idea behind Spring IoC is to let the container instantiate components (and inject their dependencies). By default, however, components accessed remotely by a Flex client are instantiated by BlazeDS on the server. The key to the Flex/Spring integration, therefore, is to configure BlazeDS to let the Spring container take care of instantiating Spring beans. BlazeDS supports the concept of a factory to enable this type of custom component instantiation. The role of a factory is simply to provide ready-to-use instances of components to BlazeDS (instead of letting BlazeDS instantiate these components). The supporting files available with this article include a factory class (SpringFactory) that provides BlazeDS with fully initialized (dependency-injected) instances of Spring beans. Note: The SpringFactory was developed by Jeff Vroom (Flex Data Services architect) and is also available on Adobe Exchange. The remainder of this post describes how to configure your web application to use BlazeDS and Spring, how to configure the Spring Factory, and how to put the pieces together and start invoking Spring beans from Flex applications.

Environment: Configuring your web application is simple and merely requires installing and registering the necessary components.

• Step 1: Install the BlazeDS turnkey server The BlazeDS turnkey server is a ready-to-use version of Apache Tomcat in which the Blaze data services have already been deployed along with sample applications. The goal of the turnkey server is to give developers an easy way to run samples and tutorials out of the box. To install the BlazeDS turnkey server: Make sure that you have the JDK 1.5 or higher installed, and that you have a JAVA_HOME environment variable pointing to your Java Development Kit installation. Download blazeds-turnkey-.zip. Unzip blazeds-turnkey-.zip in /blazeds. Note.You can unzip blazeds-turnkey-.zip anywhere else. Just make sure you adjust the path in the instructions provided in this document accordingly. Start the samples database. Open a command prompt. Navigate to /blazeds/sampledb. Execute startdb.bat (Windows) or startdb.sh (Unix-based systems) Start Tomcat. Open a command prompt. Navigate to /blazeds/tomcat/bin. Execute the following command: catalina run Access http://localhost:8400/samples to make sure the installation is successful: you should see the BlazeDS samples home page. As an alternative to using the turnkey server, you could use one of the following options: Download blazeds-.war and deploy it in your own application server. Blazeds-.war is a blank web application configured to use the BlazeDS data services. Note: samples-.war includes everything included in blazeds.war, plus a series of samples. Download blazeds-.war and merge its content in your own web application. The instructions in this document assume that you use the BlazeDS turnkey server. If you are using one of the alternative options, you will have to adjust the instructions accordingly.
• Step 2: Install the Flex SDK You need the Flex compiler to compile the client-side (Flex-side) of the sample applications discussed in this document. The Flex compiler is part of the Flex SDK. As a convenience, the Flex SDK is available as part of the BlazeDS installation in blazeds/resources/flex_sdk/flex_sdk_3.zip. Note: The Flex SDK can also be downloaded at http://opensource.adobe.com. It is also available as part of Flex Builder. To install the Flex SDK: You can skip this step if Flex Builder 3 is installed on your system. Unzip /blazeds/resources/flex_sdk/flex_sdk_3.zip in /flex_sdk_3. Note: You can unzip flex_sdk_3.zip anywhere else. Just make sure you adjust the path in the instructions provided in this document accordingly.
• Step 3: Install Spring Note: A complete discussion of the Spring installation process is beyond the scope of this article. Refer to http://www.springframework.org for more information. The steps below describe a basic configuration that is sufficient for the purpose of this article. Download the Spring framework at http://www.springframework.org/download (the version without dependencies is sufficient to complete the examples in this article). Note: The examples below have been developed and tested using Spring 2.x. However the integration approach described in this document (and the SpringFactory class) should work fine using Spring 1.2.8 (some of the examples might not work because they use Spring 2.x features). Unzip the downloaded file. Locate spring.jar in the dist directory and copy the file to /blazeds/tomcat/webapps/blazeds/WEB-INF/lib Open /blazeds/tomcat/webapps/blazeds/WEB-INF/web.xml and add the context-param and listener definitions as follows: contextConfigLocation /WEB-INF/applicationContext.xml org.springframework.web.context.ContextLoaderListener
• Step 4: Install the supporting files Download flex-spring.zip here Unzip flex-spring.zip in /flex-spring Flex-spring.zip includes the Spring factory as well as the supporting files for the examples below.
• Step 5: Register the Spring factory Copy SpringFactory.class and SpringFactory$SpringFactoryInstance.class from /flex-spring/factory/bin/flex/samples/factories to /blazeds/tomcat/webapps/blazeds/WEB-INF/classes/flex/samples/factories. Register the Spring factory in /blazeds/tomcat/webapps/blazeds/WEB-INF/flex/services-config.xml:

Example 1: Mortgage Calculator: This first application is intentionally simplistic to provide an uncluttered example of wiring Spring beans together and invoking them from a Flex application.

• Step 1: Examine the application source code Examine the Flex source code: Open MortgageCalc.mxml located in /flex-spring/samples/mortgage/flex in a code editor to familiarize yourself with the application. The application enables the user to enter a mortgage amount. When the user clicks the "Calculate" button, the application obtains the value of the monthly payment for that mortgage by invoking the calculate() method of the remote object identified by a logical name: "mortgageService". "mortgageService" is mapped to a fully qualified Java class name in the remoting-config.xml file (see Step 3 below). Examine the Java source code: Open RateFinder.java, SimpleRateFinder.java and Mortgage.java located in /flex-spring/samples/mortgage/java in a code editor. Notice that Mortgage has a dependency to a RateFinder object. Mortgage doesn't instantiate a RateFinder object itself, doesn't lookup up for a RateFinder object, and doesn't even know the exact type of the object it will be dealing with (RateFinder is an inteface). An instance of a class implementing the RateFinder interface will be injected by the container (using the setRateFinder method) when it instantiates the component (see step 2 below).
• Step 2: Register Spring beans If it doesn't already exist, create a file named applicationContext.xml in /blazeds/tomcat/webapps/blazeds/WEB-INF. Register the rateFinderBean and mortgageBean beans in applicationContext.xml as follows: Notice that in the mortgageBean definition, we tell the container how to inject the rateFinder dependency: the rateFinder property is mapped to rateFinderBean, which defines an instance of the SimpleRateFinder class.
• Step 3: Configure the Flex Remoting destination Open remoting-config.xml in /blazeds/tomcat/webapps/blazeds/WEB-INF/flex. Add a mortgageService destination as follows: spring mortgageBean Notice that we use the Spring factory defined above (see "Register the Spring Factory"), and we provide the name of the Spring bean as defined in applicationContext.xml as the source.
• Step 4: Build the project The Flex SDK includes ANT tasks that make it easy to compile Flex applications and create HTML pages to host them as part of a build process. The support files include build scripts to compile and deploy each sample application. Note: You need the Apache Ant build tool to build and deploy your applications as described in this document. If Apache Ant is not installed on your system, visit http://ant.apache.org and follow the download and installation instructions. To build the Mortgage Calculator project: Edit /flex-spring/samples/mortgage/build.xml: Make sure the FLEX_HOME property points to the location of the Flex SDK on your system. Make sure the CONTEXT_ROOT property matches the context root of your web application. Open a command prompt. Navigate to /flex-spring/samples/mortgage. Execute the following command to compile and deploy the client and server of the application: ant The build process deploys the client side of the application (the compiled flex application) in /blazeds/tomcat/webapps/blazeds/mortgage and the server side (the compiled Java classes) in /blazeds/tomcat/webapps/blazeds/WEB-INF/classes/flex/samples/spring/mortgage.
• Step 5: Run the client application Restart Tomcat. Open a browser, access http://localhost:8400/blazeds/mortgage/index.html, and test the application: Enter a loan amount and click "Calculate" to get the monthly payment for a 30-year mortgage.

Example 2: Inventory Management Using Flex Remoting: This second example is more sophisticated and includes database connectivity. To keep the application simple and avoid dependencies on other products or frameworks, the Spring JDBC abstraction framework is used to access the database. You could use the Spring support for ORM data access (using Hibernate, JDO, Oracle TopLink, iBATIS, or JPA) as an alternative: the specific Spring data access strategy you choose has no impact on the Flex/Spring integration. This sample application has two modules: a database maintenance module (storeadmin) and a customer-facing product catalog with filtering capabilities (store).

• Step 1: Examine the application source code Examine the Flex source code: Open store.mxml located in /flex-spring/samples/store/flex in a code editor to familiarize yourself with the store application. Notice the RemoteObject declaration pointing to the "productService" destination. "productService" is mapped to a Spring bean in Step 3 below. When the application starts, it invokes the findAll() method on the remote bean to retrieve the list of products (see the createComplete event on the Application tag). Open storeadmin.mxml and ProductForm.mxml located in /flex-spring/samples/store/flex in a code editor to familiarize yourself with the storeadmin application. Notice that the storeadmin application uses the same remote Spring bean (productService) as the store application to retrieve the list of products using the findAll() method, and update changes using the updateProduct() method. Examine the Java source code: Open ProductDAO.java, SimpleProductDAO.java and Product.java located in /flex-spring/samples/store/java in a code editor. Notice that SimpleProductDAO extends org.springframework.jdbc.core.support.JdbcDaoSupport. JdbcDaoSupport has a dependency to a javax.sql.DataSource object (javax.sql.DataSource is an interface).
• Step 2: Register Spring beans Register the dataSource and productDAOBean beans in applicationContext.xml as follows: Copy hsqldb.jar from blazeds/tomcat/webapps/samples/WEB-INF/lib to /blazeds/tomcat/webapps/blazeds/WEB-INF/lib.
• Step 3: Configure the Flex Remoting destination Open remoting-config.xml in /blazeds/tomcat/webapps/blazeds/WEB-INF/flex. Add the productService destination as follows: spring productDAOBean
• Step 4: Build the project Edit /flex-spring/samples/store/build.xml: Make sure the FLEX_HOME property points to the location of the Flex SDK on your system. Make sure the CONTEXT_ROOT property matches the context root of your web application. Open a command prompt. Navigate to /flex-spring/samples/store. Execute the following command to compile and deploy the client-side and the server side of the application: ant The build process deploys the client-side of the store and storeadmin applications in /blazeds/tomcat/webapps/blazeds/store and /blazeds/tomcat/webapps/blazeds/storeadmin respectively, and the server-side (the compiled Java classes) in /blazeds/tomcat/webapps/blazeds/WEB-INF/classes/flex/samples/spring/store.
• Step 5: Run the client application Restart Tomcat Open a browser, access http://localhost:8400/blazeds/storeadmin/index.html, and test the storeadmin application. Open a browser, access http://localhost:8400/blazeds/store/index.html, and test the store application.

WebManiacs 2008 - Early Bird Ending Soon

Building on the success of last year's FlexManiacs, the new WebManiacs, to be held May 19-23 2008 in Washington, D.C., is 2 events in one - CFManiacs and FlexManiacs,. With more than 50 speakers, 200 sessions, hands-on sessions, and more, WebManiacs is an excellent opportunity to get the latest on ColdFusion, Flex and AIR. Early-bird discounted pricing closes on March 14th, so register now. Meanwhile I'll refrain from any Early Bird humour. :-)

Silverlight 2 Beta

I wanted to get my hands on Silverlight 2 beta, writing a sample app to understand the experience. I half expected Silverlight to be an enormous, complex, sophisticated platform rivaling WPF - after all, it was initially named WPF/E. On the contrary, I was surprised to see the number of simplifications to the framework. Here is a brief list of WPF features that are not available in SL 2.0:

• Standard controls; like Button, TextBox, ListBox, CheckBox, etc.
• Layout panels
• Data binding
• Templates
• Styles
• Commands
• Routed events
• A majority of events on elements (available in WPF)
• A resource system based on merged resource dictionaries
• Visual and logical trees (no programmatic construct represents them, at least)

Once I got past all those missing bits I found that what does currently exist is actually quite cool and useful.  The set of controls that are supplied look great and in the demo app they seem to work quite well.

I must admit, though, I really miss routed events.  With events such as tunneling and bubbling, working with normal CLR events is really limiting.  However, if I am correct, Microsoft intends on adding routed events into Silverlight 2.  The EventTrigger class exposes a RoutedEvent property as in WPF - it is possible that they named Siverlight’s EventTrigger’s property “RoutedEvent” to ensure that the Silverlight XAML compiles in WPF, but perhaps they actually intend on implementing routed events in the future.  Think about it, what sense would it make to have a property called RoutedEvent if routed events do not exist in Siverlight?

Another thing is that it is difficult, if not possible to use inheritance in a UserControl. According to the Silverlight.net forum, this is a "limitation". Even if the Base class inherits the UserControl class, you will see this error:

"Partial declarations of 'CLASSNAME' must not specify different base classes" in the file CLASSNAME.g.cs (g = generated). 

When you open the .g.cs file and remove the base class from it, the project compiles fine and also seems to work fine.

To address this issue, see this thread: http://silverlight.net/forums/p/10970/34988.aspx. As such, while it is possible, it has some peculiarities. For instance, when opening a file in Blend, it throws an error. When you have no need for that, it's no problem, but IMHO designers should still have the ability to change things in the design after I used inheritance on the control.

Additionally, when having multiple Silverlight pages (or applications as they are called now) in a single Silverlight Project it seems impossible to load any other than the default Page.xaml:   

- When using the "html" <object> method: it expects a parameter with a xap file, xaml files are not allowed
- asp:Silverlight control also needs a xap file. asp:xaml doesn't work
   
This could be my lack of experience in Silverlight 2, but again, it's my first impression. If I find a way this does work, I'll add it as a comment to this post. There is an option by setting an initParam with the name of the startup control you want to use. I'm not sure if I like this option, but it's a workaround.

I am also uncertain as to whether the Webclient is an improvement over the Downloader. For a simple thing as loading an image from a zip file: 

1.1 alpha code:

2 beta code: 

More lines of code, which doesn't necessarily mean that it's a worse solution than the SL1.1 one, but it definitely makes it more error prone. 

I think that MSFT wants to support bitmap effects such as those provided by Flash (blurring, etc). Maybe that's the reason they chose for the addition of a bitmap object. Time will tell.

Silverlight 2 beta is also inconsistent when it comes to relative URI.    The relative path should be the path from the root of the website, as it is in Silverlight 1.0 and 1.1.

In Silverlight 2 beta , the path in design is relative to the root of the site, but when running the app, it is relative to the location of the XAP file. So when downloading "thumbnails.zip" using the WebClient it looks for thumbnails.zip in the ClientBin folder instead of in the root of your website. 

Setting the WebClient.BaseAddress to the root of the site doesn't seem to work either.