|
Spring Replacement (The Elephant in The Room)
Introduction Spring Framework is appealing to certain IT audience and it is still used by a lot of companies. Our team consider Spring Framework is as the expression goes: "There is an elephant in the room." We believe we have homegrown alternative which can use any existing Spring code. The goal of any framework is to address Usability, Security, Loosely Coupled, Transparency, Refactoring, Performance, Redundancy, Errors, Scalability, Expandability, Latency, Flexibility, Intelligence, Reliability and Availability. Plus no use of XML documents as ways to control the flow of running applications. Another important point is that Spring code lacks Intelligence. Our Main Concern: The main drawback of Spring Framework is that Spring structure (the controllers-dependences-DAO-MVC-services-Hibernate-Description) would grow out of control and maintenance becomes almost impossible. As for reusability, we do not believe reusability is practical nor cost effective. Our main concern is that different team members may view Spring structure and processes differently and that is not a good practice and source of conflicts and errors. Spring Code Conversion: We have a section at the end of this page presenting step-by-step Spring Code Conversion. Use Case: Spring Replacement with Our Business Intelligence Framework (BIF) Description: Looking at Spring buzzword such as Aspect Oriented Programming (AOP), Dependency Injection, Inversion of control (LoC), IoC Container, setter-based injection, interface-based injection, constructor-based injection, XML Configuration using p-namespace, Programmatic Transaction Management, Declarative Transaction Management, ..etc, sadly these buzzwords may have different meaning to different people. Therefore, Spring beginners or critics may have a case. Briefly Describe This Use Case Our Spring Framework Replacement must appeal to Spring Framework Fan Club and its conversion should be automated and it should not be a costly task in term of the learning curve, time and effort. The replacement effort should be worth the effort and time spent in the conversion. What is Business Intelligence Framework (BIF)? In a nutshell, BIF is a pyramid structure of processes. It is composed of: • Marco Decisions - Top Management • Micro Decisions - Business Process • Process - Architectural Structure • Code - Development and Testing Primary Actor: Clients, managers, architects, developer, testers and any Spring users or fan. Goals: How to convince Spring Fan Club with all their code developed and tested, that our conversion is: first worth reading or searching, secondly it is worth considering, then lastly converting to a homegrown reusable system. BIF addresses every level of management including development. Conversion: Our Spring Conversion uses "Bottom-Up", where Spring code conversion can be accomplished with automation and it would be tested with minimum effort. The Conversion starts with code and build the Processes, the Micro Decisions and the Macro Decisions. Analysis How can a framework link all management levels from the CEO's Macro Decisions which include the company future to the developers' code. To make our presentation more clear let look at the following example. How can CEO of company or a branch within a company build a running website with all its security, customer service and functionalities with a GUI tool. The lesson we can learn from the invention of the computer mouse, where the computer mouse was created to make using computers and software as easy as pushing mouse button. Our BIF would have a GUI interface for CEO to build and run a functional website which would present the company products and services. Such a GUI tools also would provide guidelines from services such as CRM, BI and Analytics and other CEO services. They would help CEO strategically decide on what must be done. Looking at present day Spring framework, the GUI tools we are proposing would be used by the clients stakeholders and their supporting technical teams. Our analysis is based on creating cloud based and loosely coupled maps which are controlled by the Dynamic Business Rules. System admin would be able to edit the Dynamic Business Rules using GUI editor to changes values and processes and their execution sequences. All are supported by Common, Utilities, and services modules or components. Architect Our BIF Architect view from 2,000 foot is what Figure #1 presents. 
Decision Support System (DSS) - Dashboard would help with decision making based on Analytics and CRM services. CEO would be working with GUI DSS interface and making decisions and changes in real-time. The GUI interface is to help the CEO and the supporting staff in building a running application based on all existing frontend templates available to choose from. The decisions pyramid is levels of maps, where the top level is supported by the one below. Architect Components: Our architect is structured as the following cloud based and loosely coupled componets: • Admin GUI Editor • Dynamic Business Rules • Management Tracking • Marco Decisions - Top management decisions • Micro Decisions - Business Process and analysis • Business Objects (MVC) - instantiate services • Services - use engines • Engines - each performs one task • Development - Java Code • Database Adapters - abstract factories and factories • Web Services - to handle the outside world • Utilities • Commons • Reports • Errors and Exception handlers • Logging • Testing - including user, integration, auto testing ..etc • Statistics - system performance All these structured components are controlled by the business rules which is plain text and NOT XML. 
BIF components are grouped as follows: 1. Mapping of Maps (Java HashMap) 2. Editing and running Dynamic Business Rules 3. Database Adapters 4. Supporting Services 5. Logging and Tracking of errors and exceptions 6. Management Tracking 7. Web Services 8. Testing The main execution is: • Loop through the Macro Decision map • For every value in Macro Decision map is a Micro Decision (Business processes) Map • For every value in Micro Decision map is to instantiate a Business Object • Every Business Object will instantiate a number of Service Objects • Business Objects are developed for different tiers in the MVC structure • Security should be applied to Business Objects based in on which server-tier they are running in • Each Service Object will instantiate a number of Engine Objects • Each Engine Object will run its Java code The Dynamic Business Main task is to provide: • The latest values (calculation, comparison. etc ) and constants • Execution Sequences of services • Score and weight for Intelligent (Think in Abstract) decision making • Latest validation criteria • Latest decision values for Intelligent (Think in Abstract) decision making • Dictionary of values for parsing business values Management Tracking: Each process would be logged, and tracked for statistics and management tracking. This would help evaluate the system performance as will as any bottleneck code modules. Such tracking should be turned On/Off as needed. Documentation: We view management and documentation as important pillars in any project. Documentation is a tool for reusability, tracking, training, audit trial, as well as lessons to learn. We recommend that the project documentation is composed of the following: • JavaDoc - for code documentation • Build-in Templates: which would be filled out by the users. • Free Hands: where users to give their own document and feedbacks. Supporting Services: They are used for saving redundancies in the development of components. Reports are also part of tracking as well as supporting services. Testing: Testing, test plans and automatic testing should available for managers to schedule and run. Testing processes and values should be automated the same way as dynamic business rules. Different type of test should part of testing plans. Addressing Security: Security is handled by having all components posted be on the application servers and connected to the database servers. They also can be part of the Baronet. Business Objects may use different server-tier and security must be applied. As for Web Services, it should handle the communication with outside world and store data in the database. Quickest Example: The quickest example to illustrate how our DSS system works in real-time. Let us assume that based on our Analytics-CRM services which is recommending that the company needs to run a promotion and certain items to be put on sale (reduce by 50% in prices) in the next two weeks. Such decision created in Macro Decision level would not require any changes in any of the lower levels include Java code. With same talk, if the business analyst decides to add an additional Micro Decision to an existing Macro Decision. If the newly added Micro Decision is composed of the existing processes (different in sequence of execution), then the analyst would be able to add such changes and no changes would be required by any of the other levels. With help with DSS interface, CEO decision would be translated in real-time to changes in the company's portals with 50% promotion without any changes in the other three levels. We added Dynamic Business Rules to help make the system dynamic and changes in any rules would not require any code change. Spring Code Conversion: We recommend that the conversion team should develop automated parsers which would parse the Spring files and create a map of the Spring folder structure of who is doing what. Such a map can be used to identify the following: • DAO • Services • Engines • Business Objects • Supporting services • Commons • Properties The steps for Spring conversion is done as follows: • Develop the Map structure • Build a conversion map • Build small pilot project • Test the pilot project • Lessons Learn • Start the main conversion |
|---|
