| By Coach Wei |
Article Rating: |
|
| September 19, 2006 03:45 PM EDT |
Reads: |
40,290 |
Nexaweb enables application logic to be written using standard Java:
/**
*
*/
package com.nexaweb.test;
import com.nexaweb.client.ClientEvent;
import com.nexaweb.client.ClientSession;
import com.nexaweb.client.mco.AbstractMco;
import com.nexaweb.client.mco.McoContainer;
/**
* @author cwei
*
*/
public class MyTestMco extends AbstractMco {
public void handleOnCommand() {
ClientSession clientSession = McoContainer
.getClientSessionFromMco(this);
ClientEvent clientEvent = clientSession.getEventHandler()
.getClientEvent();
//additional business logic here...
System.out.println("Hello, you clicked the button!");
}
}
Choosing the Right RIA Solution
Given the various
RIA approaches and solutions available, selecting an RIA solution can
be confusing. There's no universal "right" RIA solution. It depends on
the application's requirements.
Enterprise Application Requirements
For the
purposes of this discussion, it's useful to categorize the full
spectrum of software applications that enterprise IT departments build,
deploy, and maintain across two related dimensions: business
criticality and application complexity.
Business criticality concerns the degree to which an
application is critical to running the business or meeting business
objectives. Disrupting access to a business-critical application, or
even unacceptable performance, has an immediate and significantly
negative impact on the business. Other applications are less critical
to operations; if there's a problem, the user can wait a few minutes to
perform a task without major consequences.
Application complexity refers to its feature richness and
sophistication from a user's perspective. Some enterprise applications
have thousands of screens, with usage metaphors characterized by
multi-path, non-linear state transitions. (In other words, you might
rarely use them exactly the same way twice.) Other applications have
rather linear state transitions and fixed usage paths - using them is
comparatively routine.
Classified as either "high" or "low" across both these dimensions, an application falls into one of four categories as Figure 5 illustrates.
The applications in quadrant A are business-critical and less complex.
Users rely on these "helper" applications to do simple but highly
important business operations (e.g., an employee portal, partner
extranet, or e-commerce Web site). These applications are used less
frequently and/or for shorter durations ("casual usage level") than
more complex applications. The workflow is typically linear; users do
the same tasks in roughly the same order each time they interact with
the application. From a development perspective, the client-side
development team typically comprises fewer developers than a more
complex application would require.
A classic example of a high-criticality/low-complexity application is
an airline's online ticketing application. Most users interact with it
only occasionally, for a short duration, and in a step-by-step fashion.
Applications in quadrant B are both business-critical and complex.
These applications are used for many hours each day to do complex
non-linear tasks that are central to business operations. The
performance, availability, and scalability of these applications are
extremely important. From a development perspective, maintenance is
important and may cost more than the initial development. The
development team comprises many developers who require close
collaboration.
Examples of high-criticality/high-complexity applications include the
trading applications used by portfolio managers, call center
applications and banking applications accessed by tellers.
The applications in quadrant C are complex but less business-critical.
As a result, they are managed much more cost-consciously.
High-complexity/low-criticality applications include some legacy
applications in which companies wish to minimize further investments,
as well as some corporate R&D projects.
The applications in quadrant D are less complex and less
business-critical. They are typically written by a small development
team of one or two people. Developers' individual experimentation would
fall into this category.
Different RIA Technology for Different Applications
Seen against the backdrop of business criticality and UI complexity,
different RIA technologies are appropriate for implementing or
re-architecting the various classes of enterprise applications.
As Figure 6
illustrates, the applications in quadrants B and C are much better
suited to OOP-based RIA development approaches like Java and .NET,
because these technologies offer better maintainability and support for
team development. Scripting-based approaches are more suited for
applications that fall into quadrants A and D where programming tasks
are simpler, development teams are smaller, and maintainability is a
less mission-critical concern.
Table 3
provides details on how different RIA approaches fit with different
enterprise requirements for application profiles and developer skill
sets.
Subscribe to .NET Developer's Journal Email News Alerts
Subscribe via RSS
