High-Scale Enterprise OSFlash Projects Carlos Rovira

Page 2 © Bull 2004 Enterprise ITC: Today Traditional web development based mainly in Java (J2EE) and web thin clients (DHTML). Enterprise demands Web Applications with rich features: RIA.  RIAs must maintain the reach of Web Apps.  They want all kind of new rich new features to interact with : Dynamic charts Diagram workflows Drag’n drop data Mouse driven application workflow vs keyboard …

Page 3 © Bull 2004 Flash Platform: The Promised Land Flex  PROS: *Ideal* Workflow. *dream* framework.  CONS: Very Expensive (Maybe in 2006?). Flash Authoring Tool  PROS: Produces what we’re looking for…  CONS: Very dificult adoption by ITC departments(workflow and skills requiered are very diferent). Slow Compilation as project increases its size. …and what about AJAX???

Page 4 © Bull 2004 The Open Source Flash *necesity* Open Source is a *necesity* for Flash technology to get mass adoption.It provides:  Other ways to produce SWF (and AS code).  A wide number of developers that supports the platform (they share codebase, create base projects,…)  Technology Recognition -> Enterprise Investment.  OS can be free of commercial dependendies or support/complement commercial tools or packages

Page 5 © Bull 2004 Introducing OSFlash In The Big Enterprise Our Project:  Hybrid: About 90% Open Source.  Flash IDE still there -> MM v2 Components dependency.  Flash Remoting classes -> Free but not OS. Very Big Project.  More than 12 modules  More than 100 EJBs  Code: AS: More than 5200 lines Java: More than lines  Time / Person : about 22 Month / Man

Page 6 © Bull 2004 OSFlash Production Tools Eclipse IDE Platform.  Base enviroment. Provides the functionality to develop a software project within a team.  Manages all parts and technologies in a project. ASDT(ActionScript Development Tool)  Eclipse based plugin similar to JDT(Java Development Tool).  Provides great productivity while coding. (Still in Alpha, but very usable tool) MTASC  AS2.0 Open Source Compiler.  Very Fast -> Key piece in the OSFlash effort.

Page 7 © Bull 2004 OSFLASH Software Packages ARP – RIA Architectural Framework with some Cairngorm patchs. OpenAMF – Flash Remoting Open Source J2EE Alternative.  Integration Tier within our Flash Clients and the enterprise services (mainly EJBs). AnimationPackage.(for shape drawing support) Some v2 Custom Extensions, Skinning, Managers and Components (CursorManager, Floater, ToolBar,…).

Page 8 © Bull 2004 J2EE OS Tools and Software Packages JOnAS – Open Source J2EE Certified Application Server. JOPE – JOnAS Plugin for Eclipse.  App Server Log and Controls(start/stop) from within Eclipse IDE. EJB Persistence Tier.  Change RDBMS easily. Application could be plug in a system running Oracle, or MySQL, or any other RDBMS. Xdoclet (For EJB stub autocreation)  Provides Great Productivity Boost. EJB Stubs and Skeletons generation.

Page 9 © Bull 2004 Not Open Source Tools COMMERCIAL Flash Authoring Tool  Easy way to manage all Application Art  Remember: Maintain Compatibility with MMC. Macromedia v2 component framework.  Two serious problems: Very buggy and bad documented. Need Layout tools. FREE Remoting Classes  Free, Not comercial but not OS.  MX EventDispatcher Dependency.

Page 10 © Bull 2004 Flash/J2EE Application Architecture LDAPRDBMS JOnAS J2EE App Server Flash Client OpenAMF GateWay Custom Servlets Servlet Container EJB Container EJB Flash Client Mail System File System /Repository Application Bussines Logic EJB Facades Interaction with other Enterprise Systems

Page 11 © Bull 2004 Development Automatize tasks with ANT scripts. Eclipse Development Centralization  ASDT Test View : SWFViewer Client Log : AS Logger  JOPE Start /Stop Server Server Log: JOPE Console EAR Creation and deployment : Eclipse ANT Team  Eclipse CVS (or SVN with subeclipse plugin)  One person maintains the FLA. Rest of the team develops classes

Page 12 © Bull 2004 Client Best Practices Flash IDE create initial SWF (v2 Comp)  Create final compilation with MTASC (-out) Always Maintain compatibility with Flash IDE. If possible better maintain only one SWF.  All classes, assets, and Componets in one SWF that preloads itself.  Special case: Import v2 ProgressBar from a SWF if you don’t want to break your SWF in Flash IDE. Log with ASLogger View.  But REMOVE Log dependency when deploy to a Browser!!! Production problems (dificult to trace). Better use “–trace no” for production deployment Always Functionality first  Let effects and transitions to the end.

Page 13 © Bull 2004 Client Performance Without a good architecture you could run into problems as soon as your application increases its size. Don’t try to load all views/form at once  Break forms in small sub forms to create/destroy instances without creation delay penalty. Avoid complicated v2 cell renderers. Try NOT to do too much component nesting Server side communication:  Use Commands (in ARP) to match use-cases.  Group data on Commands - VOs – …and group calls. Try to make only on server side call per use case.  Delegate data calculations to the backend and send results as simple as possible to update UI.

Page 14 © Bull 2004 Remoting Security and Performance Use named services in OpenAMF to improve security. Instead of DefaultGateway Servlet use AdvancedGateway to improve performance.  OpenAMF don’t need to *search* for the service

Page 15 © Bull 2004 Open Source Benefits Better productivity:  Client: MTASC  Server: XDoclet Code control:  Customize  Help Fix Bugs Community support  through mailing lists, wiki, blogs, …  OSFlash projects (ARP, AnimationPackage,…) Better team workflow:  Eclipse/CVS Benefits to our project:  Client satisfaction: Better user experience Improved application user workFlow Makes his work more easy than old web apps

Page 16 © Bull 2004 We’re Looking Forward… Robust OS Application Component framework  ActionStep – ASWing – EnFlash - ¿? SWFMill  More optimization needed. Don’t allow duplicate assets,… Decrease file size. Remoting AS2.0 classes OS port

Carlos Rovira