220 likes | 334 Views
The Component Dilemma. Handicaps of Component Architectures in Commercial Information Systems Michael Löwe IDPT 2002. Contents. Theoretical promises Practical handicaps to keep them Perspectives and Solutions Perfect Pragmatic. The Theoretical Promises.
E N D
The Component Dilemma Handicaps of Component Architectures in Commercial Information Systems Michael Löwe IDPT 2002
Contents Theoretical promises Practical handicaps to keep them Perspectives and Solutions Perfect Pragmatic The Component Dilemma
The Theoretical Promises Well-Structured Maintainable Applications Divide and Conquer Reusable Software Component Market Places Efficient Software Process The Component Dilemma
Maintainable Applications Sample Insurance Architecture Well-isolated Application Components Marketing Contracts Product/Process Claims Thin Interfaces Independent Development Customer/Partner Consortia Reassurance Application Level Component Models Provision Finance The Component Dilemma
Class Product Contract Object Model View Application Components Process Statistic Coverage Marketing Consortia Re.-Ass. Tariff Interests Police Billing Competence Liability The Component Dilemma
Legacy Structure Application Application Application Application Application Application Application Application Interface Application Application Application Application Application Application Interface Interface Application Application Interface New Component Application New Application Application Components Migrating Component by Component Migrating Application by Application The Component Dilemma
Handicaps Branch-specific application domain architectures and components are not available, yet. Methods for migrating legacy systems into component structures are not sufficient. Integration of application level components is not easy and cost-intensive. The Component Dilemma
Requirements for Component1 Interfaces1 Requirements for Component2 Interfaces... Interfaces2 Construction plan Requirements for Componentn Interfaces... Interfacesn Divide and Conquer Global Requirements Analysis The Component Dilemma
Team 1 Requirements for Component1 Correct Component1 Requirements for Component2 Correct Component2 Requirements for Componentn Correct Componentn Team 2 Divide and Conquer Realization The Component Dilemma
Correct Component1 Correct System Interfaces1 Correct Component2 Interfaces... Interfaces2 Component Architecture Correct Componentn Interfaces... Interfacesn Divide and Conquer Synthesis The Component Dilemma
Handicaps Analysis results cannot be proven correct. Component architectures do not like change. Methods for the evolution of component structures are not sufficient. The Component Dilemma
System 1 System 2 System 3 Reusable Software Component Component Component Infrastructure Object Model, Communication, Messaging, Transactions, Synchronization, Security, Safety, Authorization, Workflow, Dialogs, Persistence, Logging, Administration, Operating, ..... Library Component The Component Dilemma
Reusable Software Not reusable class A Probably reusable class A Decoupled by Observer Pattern Subject observers Observer Dependent Classes Class A myB myA Class B Class A myA Class B The Component Dilemma
Handicaps Components need more infrastructure than function call. Function calls need some infrastructure themselves. There are several competing and incompatible component infrastructures. Methods and tools for migrating components into another infrastructure are not sufficient. Simply reusable components are not simple. The Component Dilemma
Suppliers Component Market Places Commercial Dependency Transaction Monitor Application (Client) Database System(s) Operating System(s) GroupWare MiddleWare Internet Components Office Components Workflow Management System The Component Dilemma
Handicaps Using components from a component market increases commercial dependencies. Consequent application of standard components leads to standard business. The Component Dilemma
Efficient Software Process PGP CORBA ODBC JSP XSLT Intranet JDBC DHTML Extranet OLE Active X DCE EJB XML C# XML-Schema SSL UML Java Beans Internet Thin Clients HTML IIOP .Net DTD DCOM Web-Server Multi-Tier Fat Clients Internet-Browser Webshere ASP Frameworks Applets EDI DAO Servlets COM+ Ultra Thin Clients Messaging Application Server 3-Tier RMI The Component Dilemma
Efficient Software Process Application Domain Services Branch Model Application Domain System Infrastructure Inter Platform Services Corba-ORB Application and Systems Integration Platform Services Enterprise Beans Technical Information Systems Infrastructure Component Model Beans Object Reuse Standard Service Java-Classes GUI, Collections, Threads, DBM, ... Language Java Algorithms, Patterns, Program Reuse, ... Machine or Byte-Code JVM Efficience, Security, ... The Component Dilemma
Handicaps There are not enough software engineers who are used ”to think in components”. Return on investments into component architectures cannot be expected within a short time. The Component Dilemma
Solutions (perfect) Application Components To good to be(come) true Evolution Migration Framework Migration Infrastructure Migration Prototype Frameworks Legacy Reengineering Branch Architectures Branch Components Inter-Infrastructure Techn. Components Componentization of Infrastructures Standardization of Interaction General Architectures General Components Technical Components The Component Dilemma
Solutions (pragmatic) Do not build for eternity! (20 years is eternity!) Design for today not for the future! Restrict maintenance! Bugs and errors Legal changes Rebuild often (5 - 8 years, complete systems)! Change platforms and tools if needed or wanted! Educate your people! Extreme, but works The Component Dilemma