technoprisoners! some thoughts on how to avoid becoming one of them jim walmsley it specialist, ibm...
TRANSCRIPT
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