technoprisoners! some thoughts on how to avoid becoming one of them jim walmsley it specialist, ibm...

TechnoPrisoners! Some thoughts on how to avoid

becoming one of them

Jim WalmsleyIT Specialist, IBM

August, 2002

What’s happening

Complexity increases Control decreases

With the shift to Internet-based apps:

The good old days…

Simple, small transactions Private corporate network Single database Few interfaces One program does it all : UI, logic,

Database handling, printing Centralised development

Now…

Web Portal architecture

Now…

Applications spread across worldwide network (the internet)

No control over the end-user environment

Services (security, messaging) may be provided by completely different systems

Requirement for:

Interoperability Pervasive

access Personalisation Flexibility Yadah yadah

yadah

Driving the change... The user’s desire for:

More function Better access, anything/where/time/how/body Friendly, intuitive interfaces

The business’ desire to: offload data entry to the customer stay in the game create new services/products that exploit the

new possibilities

But...

need greater efficiency in application development

need to manage complexity

more function+ more flexibility

+ more interoperability = greater complexity

How can we deal with complexity?

Use of decoupled, encapsulated components (built or acquired)

Code re-use Careful use of patterns Observe standards Even in the host-

based environment, designing systems based on decoupled components, interfaces and standards yielded benefits.Now, the need is even greater.

Services

Account

Achieving more intuitive apps Object Modeling - modeling the real world so that

apps behave more intuitively OO Development Works well with a component-based approach

Customeropens

AccountAccountAccount

contains

ServicesServicesServices

Another trend: Open Source Emergence of world-wide technical

community Consolidation of standards … and the emergence of robust Open

Source components as a serious alternative to DIY

Build or Acquire? Which components do we build?

(Warning: sacred cows on the road ahead! We may hit some of them.)

Build or Acquire? Rule 1

Don’t build infrastructure Your App = your content + business

rules + IP What creates your presence What makes your business unique

Infrastructure = everything else Needs to be solid & reliable But your customer shouldn’t know it’s there

Build or Acquire? Rule 1 …cont Don’t build infrastructure

It’s been done before It may look simple now, but it will grow There are affordable alternatives Future proofing because of standards:

major builders either follow or establish them

Avoid architectural dead-ends IP may stay with individuals Skills availability Support – vendor or worldwide community

Slings & Arrows Hurled At Rule 1 Short term vs. long term perceived costs

(scope expands over time) #8 wire mentality “Not invented here” Available expertise Architectural preferences Our Standards Preclude This Solution Politics

So, What is Infrastructure? Anatomy of a web app…

…spot the infrastructure

Anatomy of a Web App

1. Server Topology

Also: Systems monitoring Workload management

Anatomy of a Web App

2. App Design

Also: Messaging Utils

You don’t have to build it all yourself.

Rule 2 If what you are doing is getting really

hard, there must be a simpler way. …and it’s probably been solved

before. App/Infrastructure distinction clear? Look to the community (colleagues, fora,

newsgroups, books, Google) Standard not being observed? Check the

next release of the component.

Patterns A Pattern is…

Warning: patterns can become an obsession

One is presented here: Model View Controller

“...a best practice solution to a common recurring problem.”

“It’s all about quality of life.”

MVC/Component Example: Struts

MVC (Struts) continued…

Decoupling makes the following easier: Unit testing Adding new UIs (pervasive computing) Changing the DBMS Implementing using components (eg. Struts)

And Basic engine ready to go Get started very quickly

And It’s free

Another Word on Standards “Good” side...

Makes some of the decisions! Future-proofing Ability to grow and take advantage of new

developments Skills availability Speeds up design

“Bad” side… Alphabet soup!!! (J2EE, WSDL, HTML, XML, SOAP,

W3C…) Where to find…? Revisions can affect best practices “Some are more equal than others”

Example: Decision Made!

J2EE standard Web App Folder Structure – so often not followed

Building Complex Applications…

With components!

References www.theserverside.com/resources/article.jsp?l=J2EE-Deployment

Floyd Marinescu: “EJB Design Patterns” jakarta.apache.org jakarta.apache.org/commons www.w3c.org java.sun.com/j2ee The lego figure-8 knot on the previous page came from:

http://www.lipsons.pwp.blueyonder.co.uk/mathlego.htm