Primeton EOS Development Platform Training Summary

Pu Yuan EOS Development Platform Training summary

2004-02-22

(This article is a software enterprise's technical person to accept the Primeton EOS Platform 3.0 version of training after summing up the experience.) At present, the latest version of the Primeton EOS product is 5.0, the author of the "5 major shortcomings" is still in existence, it is a question worth thinking. ）

a EOS the capabilities of the development platform

 

Primeton EOS is a rapid development platform. On the basis of this platform, we can customize the new system by the function of some existing components.

The EOS Pro Edition comes with permissions and public two component libraries, and optional artifacts include workflows, management, and so on. The default component library makes it easy to invoke and customize new features.

EOS provides a studio development environment, and the custom process is fully graphical and can be implemented in a drag-and-drop fashion.

For a new business system development, developers can be customized "performance automata", "Business automata" and so on to build the entire system. The system automatically generates the appropriate code and submits it to the server.

EOS provides a database mapping tool called a data dictionary that maps a database table to a named entity object. The named object is invoked on the system to access the database.

EOS provides a JSP builder that automatically generates the corresponding CRUD template operating interface based on an entity.

EOS supports a variety of application servers. Support is deployed on distributed systems.

two EOS advantages of the development platform

 

1 can quickly develop prototype products

With the understanding of business requirements, several developers who are familiar with EOS can quickly develop a product prototype. This is suitable for competing bids in unfamiliar fields.

2 The learning curve is more java EE Low

Some of the complex technologies of EOS are transparent to developers, and developers are not allowed to know too many EJBs, application servers, etc., and can be developed and deployed as long as they operate the various EOS tools. Only need to focus on the business.

3 ability to change customer's needs and adaptability

The entire development is based on a graphical process interface that rarely involves program code, and only needs to update the graphics and regenerate the code once the customer's requirements change. Other revisions are relatively small.

4 component packages can accumulate continuously

EOS provides some basic packages, and a large number of features are already encapsulated. At the same time, in the implementation of different areas, it will also produce the characteristics of the domain component package, can be accumulated for future use.

three EOS disadvantages of the development platform

 

1 EOS There is no uniform standard for components

The component of EOS does not yet have a uniform standard. This has a great impact on subsequent development and expansion. In the future, all products are firmly tied to the EOS platform, the transplant is very poor, completely lost the flexibility of Java EE.

2 EOS vague definitions of some of the concepts

For example, dynamic EJB, data dictionary, widget, etc., does not give a definite definition. There may be some difficulty or deviation in understanding. In fact, dynamic EJB and data dictionary are in the hype concept, and no new ideas.

3 EOS will lead to a decline in the company's technical accumulation

The high transparency of EOS also leads to a reduction in the level of technology. Programmers can't master the core technology, so it's hard to solve them on their own if there is an accident.

4 EOS cannot be compatible with old products

The portability of EOS is poor, and the old products are completely unable to be ported to the EOS platform.

5 EOS There are still gaps in the tools

There are still some gaps in the usability and maturity of its tools. For example, various tools have not yet been integrated into the same operating interface.

Four A personal view of EOS

with 2 days of training, there is a general understanding of EOS. It can be considered that EOS is a relatively stable and rapid development platform. However, some of these concepts or methods, there is a greater risk.

The first is the idea of the entire EOS software, which is positioned in a graphical rapid development platform that generates final code by modeling the business. The international standard is MDA (Model driven architecture). MDA development is just beginning, its core is MOF or metadata, and is the OMG standard.

To counter EOS, it simply defines the business through a custom flowchart, one without a global architecture or profile design, and two without modeling the business domain. EOS is a process-oriented design if it is appropriate to compare the past with process-oriented and object-oriented. However, its finished product is the object-oriented language Java code, in a process-oriented way to write object-oriented Java code, which is the reason for its poor portability.

Second, the so-called component. The widget, as I understand it, is a set of business functions or models that can be reused, and the scope of reuse should be a suite of functions rather than a class, such as an order system that may contain multiple classes, but reuse is the entire order system. There is a portlet standard in Java, which is the standard defined for the portal. Each portlet can correspond to a set of artifacts. As long as the order system implements Portlet standards, orders can be reused anywhere on the web. The widely accepted component concept in Java is Pojo or JavaBean, a domain model with business functions.

The artifacts in EOS are actually functions in a class. According to my analysis, Eos actually defines a business process in an XML file and then invokes and executes the process with many functions that are fixed out of the portal. In this way, reuse is actually specific to the function. Each function is a similar parameter, typically an XML document and an entity object.

EOS does not give a system interface or extended standard, and subsequent development or expansion is difficult, and the risk of developing a complex system is high. Standards are related to the success or failure of EOS.

EOS is not available for technical developers. A large number of similar operations and shielding of the core technology will make people who are keen on technology lose interest. This platform is relatively low in technology, but it may be effective for technical support personnel who are familiar with the business. Software development is the work of man and not machine, therefore, human activity plays a very important role in the development. Ignoring the cultivation of people, can only bring a higher rate of staff turnover.

EOS cannot be used to upgrade and transplant existing OA products. But it can be used for bidding in new areas. However, it cannot be overlooked that reliance on EOS will be unavoidable due to the difficulty of EOS expansion and the lack of core technology.

The above is my summary to EOS3.0. After a few days of training, I think the actual platform of EOS is much worse than propaganda, and still can't be used for real enterprise development.