1 / 22

The Component Dilemma

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.

aric
Télécharger la présentation

The Component Dilemma

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Component Dilemma Handicaps of Component Architectures in Commercial Information Systems Michael Löwe IDPT 2002

  2. Contents Theoretical promises Practical handicaps to keep them Perspectives and Solutions Perfect Pragmatic The Component Dilemma

  3. The Theoretical Promises Well-Structured Maintainable Applications Divide and Conquer Reusable Software Component Market Places Efficient Software Process The Component Dilemma

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

  5. Class Product Contract Object Model View Application Components Process Statistic Coverage Marketing Consortia Re.-Ass. Tariff Interests Police Billing Competence Liability The Component Dilemma

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

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

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

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

  10. Correct Component1 Correct System Interfaces1 Correct Component2 Interfaces... Interfaces2 Component Architecture Correct Componentn Interfaces... Interfacesn Divide and Conquer Synthesis The Component Dilemma

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

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

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

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

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

  16. Handicaps Using components from a component market increases commercial dependencies. Consequent application of standard components leads to standard business. The Component Dilemma

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

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

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

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

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

  22. ...thank you for your attention!!!

More Related