The development suite for web-based service-oriented architectures.

GBuilder is the innovative suite for designing, developing and deploying robust multi-tier applications by leveraging the code and capabilities of the Embarcadero Delphi and Adobe Flex environments. It guides development teams towards the latest Web technologies and the SOAP standard, enabling the creation of applications based on the 2G architecture.

It is the first solution based on the concept of global modelling, where data virtualization, core business rules and user interface characteristics are stored as information within a single repository. This enables the creation of reliable business services and Enterprise-level Rich Internet Applications, ready for deployment and equipped with advanced configuration and administration features. Applications developed with 2G implement the SOA multi-tier model, based on Web services (SOAP) over HTTP/HTTPS, with dynamically published WSDL and XSD definitions.

Exclusive features of the modeller and framework include the presence of a Repository containing business object definitions and interface specifications, directly used by the user system and dynamically interpreted at runtime by the framework classes, as well as the advanced multi-window Web 2.0 user interface of the produced applications, which exploits the high interactivity of the Adobe Flex environment and is compatible with all major Internet browsers.

GBuilder is the tool used for modelling 2G applications. A model includes the definition of business objects, their properties and relationships, user interface specifications, messages, parameters, rules and everything required to create the underlying server and client infrastructure.

All project information is stored in the production database; GBuilder enables the production database to be updated using the model data. The database is used by the 2G classes to expose Web services and business objects, as well as to dynamically generate the interface definitions that the Flex application can read and interpret.

If business objects do not require specialised application logic, the standard 2G classes are able to expose all the services required on the client side to manage and manipulate data and interfaces, without writing a single line of code. However, elements requiring specific processing, such as updating multiple entities according to particular application logic, can be implemented by customising Delphi and/or Flex code, inheriting from the standard classes created by the framework.

The standard interface classes include: ribbon menus; advanced and basic grids; editable grids; tree views; forms; as well as a complete set of configuration and administration tools.

A 2G model is based on elementary elements called VirtualSets. A VirtualSet represents a business object when it is based on persistent data (one or more database entities or the result of a parameterised query), or a set of parameters when it is defined as a descriptor.

A database-based VirtualSet can be used in the same way as a dataset; its definition includes a list of fields, called VirtualFields, each with its own characteristics, management rules and visual appearance, as well as one or more interface definitions for displaying and manipulating data on the client side. A descriptor is not based on data; it can be used to collect the parameters of a form in order to execute server-side operations, such as a report or a remote procedure. The 2G framework is responsible for publishing the methods for inserting, modifying and deleting data in VirtualSets, together with the methods required to instruct the client in the design of management forms.

An interface, whether a grid or a form, can include all or part of the standard management tools and/or specific controls, called Actions; an Action can call other interfaces or remote procedures, called Processors, passing one or more parameters. A Processor is a hard-coded Delphi class compiled within a server-side application; 2G exposes standard automatic insert/update Processors for the modelled VirtualSet, based on the business logic predefined in the model. However, new Processors or custom Processors can be written in Delphi to implement customised procedures or complex logic.

The elements that make up a 2g model are the following:

• Entities. They are the physical entities (tables) or logical entities (updatable or non-updatable views) contained in the application database, which are involved in the definition of the VirtualSets (business objects, see below).
• VirtualSets. They are the actual business objects, containing the information managed by the system. They can be based on persistent data (updatable entities), for which they define relationships and properties (fields), on non-persistent data (non-updatable views or user-defined selections), or on structure definitions (descriptors) useful only for data collection from the interface. VirtualSets define the fundamental characteristics of individual pieces of information, called VirtualFields, regarding basic properties (name, format, type, update rules), interface properties (representation/input modes), and specific behavior (progressiveness, nullability, etc.).
• Interfaces. They are the interfaces related to individual VirtualSets, defining the ways in which the user interacts with data. In 2G there are predefined classes for representation in linear grids (with different levels of complexity), hierarchical grids, and forms. Interfaces can be called from menus or from other interfaces;
• Layouts. Layouts are related to interfaces and define which VirtualFields are accessible by the specific interface and with which characteristics.
• Actions. Actions represent the connection elements between the different elements of the 2G model, through I/O Rules, from the Client point of view. In particular, Actions allow linking: Interfaces to other interfaces, Interfaces to Providers/Processors, VirtualFields to specific lookup interfaces/providers, Menu items to Interfaces, Menu items to Processors.
• Menu. The menu items making up an application are separate elements with respect to VirtualSets and the other model elements. The structure of the items is defined within a tree structure. Each Menu Item is associated with an Action, which can launch an interface or execute a processor.
• Report. Reports are independent elements within the model, defined in a specific repository, even though their use takes place within interfaces. In particular, reports are executed through Forms belonging to a specific class (generally based on VirtualSets of type Descriptor) that include in their definitions the list of available Reports.
• Modifiers. Modifiers are not autonomous elements, but additional information related to other model elements, such as VirtualSets, VirtualFields, Reports, Menus, Processors, Interfaces, and Actions. The purpose of modifiers is to alter the behavior of objects at run-time, depending on different possible aspects, such as the presence/absence of license certificates (extensions), the value of application parameters, the content of session variables, and so on.
• Provider. Providers are not model elements in the strict sense, but represent the services made available by the server for data reading (GetRecordList method). Therefore, there is no provider repository in the model, as providers are automatically exposed for VirtualSets enabled for reading. There are also providers that do not derive from VirtualSets present in the model, but are automatically exposed by the system to allow the reading of information related to built-in functionalities (for example Users and Sessions for administration functions).
• Processor. The term processor identifies an application class exposed by the server as a service. Processors generally perform operations on data, such as inserting/modifying records in a VirtualSet, and can belong to three main categories:
  • Dynamic Processors. They are automatically published by the service, based on the VirtualSet definitions, to allow the insertion/modification/deletion of records contained in them;
  • Custom Processors. They are manually created for application purposes and generally perform controls or calculations requiring server-side logic;
  • System Processors. They are published by the service in reference to specific built-in functions, which the system manages natively.

The elements described above are defined within the modeller, 2G Builder, and stored in the repository which, once deployed to the user site, is read by the 2G Framework engine to create the actual application. The interface, downloaded to users' browsers in the form of a run-time agent, automatically communicates with the application servers based on the model in use.

Modelling and standard functions concern both the services side and the interfaces side, meaning that 2G Framework provides by default a “complete” solution directly usable by the end user and equipped with all the administration tools required in enterprise-level applications, limiting code interventions only to advanced business rules (if present in the application), without necessarily requiring knowledge of the protocols used and integration issues in services. This aspect, unique in the current landscape of CASE systems for SOA architectures, is fundamental because the use of 2G Builder does not require specific knowledge in the SOA/RIA field and allows the production of complex applications quickly and without critical issues, acquiring know-how on these new technologies gradually, in a guided and structured way. It is an absolutely innovative infrastructure also because the almost complete modelling of the interface side could allow an almost painless change of the technologies used on the client side, according to future market developments and user expectations, while preserving the logic and information of the abstract layer.

One of the most interesting features of GBuilder is the ability to design and deploy a complete application, both client-side and server-side, without writing a single line of code. User menus, grids, and forms can be easily defined within the modeller; their visual properties are stored within the repository and managed using the suite's tools. No line of code is required to create a new menu item or a data management module, and no Flex procedures are needed; 2Gframework Flex reads, interprets, and dynamically manages the form specifications defined on the server side, using web services. The interactive design tools are so flexible that developers can simply ignore Flex programming techniques, as 2G is capable of producing robust and reliable application forms in a very short time.

Another major advantage of 2G is that most of the application structures, specifications, and characteristics are stored within a database. This allows programmers to search, analyze, and operate on application objects through SQL tools, even in bulk mode, and enables analysts to quickly navigate the application's functionalities. For example, programmers can choose to extract every form containing a specific field, modify its appearance or behavior, and apply all changes with a single operation. Furthermore, an abstract repository makes future technological migration of the client and/or server side possible: since business objects and their relationships are stored separately from the code, a different server and/or client framework written in other technologies, languages, or platforms can enable the migration of an entire application with minimal or no intervention, also allowing the coexistence of the same model on different platforms.

The model repository includes reports and remote procedure definitions, enabling the complete centralization of application elements and the ability to produce automatic documentation, for internal or external use. Delphi classes can be automatically read from source code and stored in the repository, easily associated with 2G processors, greatly improving system documentation and maintenance capabilities.

Application forms and messages, as well as labels, are stored in the same way, allowing easy translation to produce applications in different languages.

A version control tool is also available within the suite, which tracks changes to model definitions; even a correction to a label can be tracked and used to prepare version update documentation.