Building application by assembling interchangeable parts


J2EE patterns: Building application by assembling interchangeable parts

  1. In the software engineering research area, there is a lot of talk about building application by assembling pre-fabricated interchangeable parts. Unfortunately, software researchers may never realize this goal, since software applications are so unique. Furthermore, the applications need to be constantly adoptable to changing needs, how one could find pre-fabricated parts for not yet known future needs? Let me outline a process to build applications by assembling interchangeable parts. As I said, we cannot use pre-fabricated interchangeable parts. So, I will be using “dynamically-configurable-interchangeable” components. The main requirements for the ‘interchangeable-parts’ are that, they must be: (i) Easy to replace or interchangeable by a new component in minutes, (ii) They must allow independent and easy reconfiguration or refinement to meet to evolving business needs. So, what are the pieces we must invent to accomplish that goal? The product makers assemble pre-fabricated interchangeable parts to build products such as computers and automobiles. The problem of assembling interchangeable-parts to build software-applications is not that much different from assembling products, for example automobiles. The only fundamental difference may be generally summarized as: The automakers need to build assembly line to make just one model car (e.g. either Camry or Accord). The software-makers need to build a universal assembly line to dynamically make any model car at real-time, based on user preferences: There are few issues we must address, to setup the supply chain for the software application: The method to assemble pre-fabricated interchangeable-components: The process to assemble ‘dynamically-customizable-interchangeable-parts’ to build larger and larger components and finally the application: Pioneer-soft is planning to create reusable Ajax-GUI-API, which are capable of generating XAML and/or SVG code-blocks for the ‘interchangeable-components’. The ‘developer guide’ to use the reusable GUI-Classes: An example to build a reusable GUI-Class for Air-traffic-control system application: A simple example for the Component-factory and assembling the components: An example for building component hierarchy: This pattern may be used for building graphics intensive online applications. Best Regards, Raju
  2. You may want to take a look at Jt Jt - Java Pattern Oriented Framework (Jt 2.3) Jt2.3 has been released. Jt is a pattern oriented framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. Jt implements many well-known patterns including Data Access Objects (DAO), GoF design patterns and J2EE patterns. Jt2.3 features several enhancements to the Jt components and a version of the Jt automated Wizard (JtWizard). This reference application is based on the Jt framework. The framework addresses the following goals and requirements: A) The pattern oriented framework should implement and/or facilitate the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself should be conceived and implemented based on design patterns (from the ground up). The framework should also facilitate and accelerate the implementation of applications based on design patterns. B) The framework architecture should be based on a messaging design pattern: framework objects should be able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily plugged into complex framework applications using a “lego/messaging” architecture. The framework should take full advantage of the power and simplicity of the messaging design pattern. C) The framework lego/messaging architecture should provide transparent access to remote components: remote framework objects should be treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) should make this posible by hiding the complexities associated with remote APIs. D) The framework should provide transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services. E) The framework should be designed to be lightweight and fast in terms of performance (low overhead). F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework should provide wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams. G) The framework messaging architecture should facilitate testing and debugging efforts. The framework should provide capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages. H) In order to provide additional productivity benefits, the framework should be integrated with open source IDEs. Most of these requirements are met by the current version of the framework (refer to list of features). Jt online documentation can be found at For additional information please refer to