The Past, Present and Future of

acceptableseashoreΑσφάλεια

5 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

70 εμφανίσεις

The Past, Present and Future of

Rich Internet Applications

Anders Norås

Solutions Architect, MCSD

http://dotnetjunkies.com/weblog/anoras/

Speaker.getDetails();

Solutions Architect for Objectware.

Ten years of experience developing business
applications.

Mainly using J2EE & Microsoft .NET technologies.

Agenda

What are Rich Internet Applications?

Ajax’ history.

How can I use Ajax to build ”Chubby Clients”?

Creating an agile ”Chubby Client” architecture.

The future of Rich Internet Applications.


The Ebb and Flow of Client Technologies

1992

1998

2005

Richness

Reach

Rich Internet Applications (RIA)

& Smart Clients

Why Rich Internet Applications?

Users and IT
-
organizations frustrated with the
limitations of HTML.

Providing a superior customer experience is a
key business differentiator.

The “boom” resulted in web applications that are
difficult to use, costly to support and ineffective.


Elements of Rich Internet Applications

Asynchronous capabilities.

Gives more responsive applications.

Multi
-
step processes.

Interaction
-
support aid users.

Proper client side validation.

Helps users fill in forms with greater speed and
accuracy.

Direct manipulation.

Enables more intuitive user interfaces.

Key RIA Technologies

Macromedia Flex

Microsoft Extensible Application Markup
Language (XAML)

Mozilla XML User Interface Language (XUL)

Java Networked Desktop Components (JNDC)

Windows Forms Smart Clients (.NET)

Plain old HTML pages


”Chubby Client”?

Smart vs.
“Chubby”

Network

Dependency

Limited User

Experience

Complex To

Develop

Fragile “DLL/

CLASSPATH

hell”

Tough To

Update

Tough To

Deploy

Easy To

Update

Easy To

Deploy

Easy To

Manage

Rich User

Experience

Offline Capable

Responsive &

Flexible

High Developer

Productivity

Smart Data

Management

Smart Connection

Management

Smart Clients

Thin Clients

Rich Clients

“Chubby” Clients

Examples of ”Cubby Client” Applications

Outlook 2003 Web Access

Custom CRM application

Examples of ”Cubby Client” Applications


Microsoft SharePoint


Amazon A9


Google.*

Ajax’ History

Netscape 2.0 released
.

First browser to support

Java, frames and JavaScript

The Browser Wars

Revenge of the ”Smart Client”

96

97

98

99

05

00

01

02

03

04

The Birth of “Ajax”:

Frames
-
Based RPC

Application Page (HTML)

Hidden Frame (JSP)

Biz Logic

RPC Stub

Callback

Function

HTTP Get

Ajax’ History

The Browser Wars

Revenge of the ”Smart Client”

96

97

98

99

05

00

01

02

03

04

Netscape 2.0 released
.

First browser to support

Java, frames and JavaScript

Netscape 4.0
ß1 released.

DHTML is born.


Microsoft Remote

Scripting released

SOAP 98.

Microsoft Web Service

Behavior released

Sun advocate

thin clients

ASP.NET 2.0

Macromedia Flex

released

.NET released
.

Strong focus on

WinForms &

Web Services

Java WebStart

First “Smart Client”

framework

AJAX

JDNC

A new birth for

desktop Java

Ashley IT

Continues develop

MSRS

JS Phone Home: XMLHttpRequest

Using Ajax to Build ”Chubby Clients”

Ajax as seen today is great for enriched user
experiences…

…but most web based business applications can
be radically improved by adopting client / server
like features.

Java Script Object Notation (JSON)

Lightweight data
-
interchange format.

Based on ECMA 262 object literal, but is
language independent.

Built on two data structures:

Name/value pair collections.

Ordered lists of values.

Implementations exist for a variety of
programming languages.

JavaScript, Java, C#, Ruby, Perl amongst others.

Remote Procedure Calls using JSON
-
RPC

JSON
-
RPC

function

doStuff()

{


var

sql=“SELECT *


FROM users WHERE


clue > 0”;

}

JSON RPC


Pros and Cons

Elegant, lightweight, human readable format.

Good framework support.

The technology isn’t widely adopted.

Applications can become chatty if used without
caution.

Building Manageable ”Chubby Clients”

Write JavaScript code as if it was Java code.

Separate features in different libraries instead of writing one “big
ball of mud”.

Use JSUnit to test your code.

Use platform features, such as XMLHttpRequest.

Use common design patterns to ”abstract away” browser
differences.

Be careful what you bring into your projects from the web.

Avoid passing overly complex types between server code
and the browser.

Keep the service boundaries explicit.

Serializing Beans Using XMLEncoder &
XMLDecoder

XMLEncoder / XMLDecoder
-

Pros and Cons

Lightweight

Streams are small

Few lines of code in both client and server application

Proprietary

Tightly coupled

XML representation isn’t self contained

Server


Client is a breeze; Client


Server
isn’t.

Using Web Services from the Browser

Microsoft Web Service Behavior

Gecko WSDL proxying



How Stuff Works: SOAP Style XML Serialization

Customer

<Customer>

</Customer>

Customer

<Firstname>..</Firstname>

<MiddleName>..</MiddleName>

<Surname>..</Surname>

<Address>..</Address>

<Postalcode>..</Postalcode>

<City>..</City>

<Country>..</Country>

Address

Address

City

City

Country

Country

Firstname

Firstname

MiddleName

MiddleName

PostalCode

Postalcode

Surname

Surname

XML Serialization: Passing a JavaScript Object as
an Argument to an Axis Web Service

How Stuff Works: Xml Deserialization

<Customer>


<Address>..</Address>


<City>..</City>


<Country>..</Country>


<Firstname>..</Firstname>


<MiddleName>..</MiddleName>


<Postalcode>..</Postalcode>


<Surname>...</Surname>

</Customer>

Postalcode

Postalcode

Where do

I belong?

What

am I?

What am

I supposed to do?

I NEED

HELP!!!!!

XML Schema

Returning an Object from an Axis Web Service to
a Java Script Client

XmlSerialization


Pros and Cons

SOAP Document Literal is the de facto data
-

interchange format.

Web Service endpoints can easily be reused
across a variety of applications.

Messages are self
-
contained when paired with
WSDLs.

Integration code can be “heavy”.

The aftermaths of the browser wars make cross
browser development difficult.

Creating an Agile “Chubby” Architecture

Leverage existing business logic.

Decompose presentation, integration and data.

Rely on browser features and third party
controls before rolling your own.

Write script code as if it was server code.

Ensure Document / Literal style when
developing web services.

Use self
-
contained, disconnected entities as
often as possible to avoid chatty RPC interfaces.

The Future of “Chubby” Clients

The rumors of the browser’s death are greatly
exaggerated.

The emergence of Smart Clients will increase the
demand for intuitive web UIs.

“Chubby Clients” enables a gradual transition to
richer UIs for key applications in your portfolio.

Exploit SOAs in web clients.



Summary

Increasing demand for more intuitive UIs.

If you can; create Smart Clients, otherwise
fatten thin clients.

“Chubby Clients” are trivial to develop in modern
browsers.

Resources

JSON

JSON:
http://www.json.org

JSON for Java:

http://www.crockford.com/JSON/java/index.html

JSON
-
RPC Java ORB:

http://oss.metaparadigm.com/jsonrpc/

Web Services

Apache AXIS:
http://ws.apache.org/axis/

Microsoft Web Service Behavior:

http://msdn.microsoft.com/workshop/author/webservice/overview.asp

Gecko WSDL Proxying:

http://developer.mozilla.org/en/docs/Accessing_Web_Services_in_Mozilla_Using_WSDL_Prox
ying

XML Serialization:

JavaScript XML Serializer:
http://dotnetjunkies.com/WebLog/anoras/archive/2004/08/13/21962.aspx

Tools

Fiddler HTTP Debugger:
http://www.fiddlertool.com/fiddler/


MindReef SOAP Scope:
http://www.mindreef.com

JSUnit:
http://www.edwardh.com/jsunit/