1. TechnoPrisoners! Some thoughts on how to avoid becoming one of them Jim Walmsley IT Specialist, IBM August, 2002

2. What’s happening Complexity increasesControl decreases With the shift to Internet-based apps:

3. 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

4. Now… Web Portal architecture

5. 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

6. 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

7. But... need greater efficiency in application development need to manage complexity more function + more flexibility + more interoperability = greater complexity

8. 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.

9. 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 Customer opens Account contains Services

10. 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

11. Build or Acquire? Which components do we build? (Warning: sacred cows on the road ahead! We may hit some of them.)

12. 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

13. 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

14. 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

15. So, What is Infrastructure? Anatomy of a web app… …spot the infrastructure

16. Anatomy of a Web App 1. Server Topology Also: Systems monitoring Workload management

17. Anatomy of a Web App 2. App Design Also: Messaging Utils You don’t have to build it all yourself.

18. 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.

19. 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.”

20. MVC/Component Example: Struts

21. 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

22. 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”

23. Example: Decision Made! J2EE standard Web App Folder Structure – so often not followed

24. Building Complex Applications… With components!

25. 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