GATEWAY CONFIGURATION LANGUAGE FOR USE IN API ENVIRONMENTS

Abstract

Disclosed herein are system, method, and computer program product embodiments for providing a universal coding language and construct for an application programming language (API) environment. In the environment, a standard language with a predefined and universal format is used for each of the different internal code modules. A translator is then provided in order to translate the standard language to the proprietary language of specific gateways or other vendor products. In some embodiments, a parser is used to in order to convert the code modules to an internal model. The internal model allows a user to visualize or otherwise understand the configuration that has been coded, and to make any necessary modifications.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No. 63/246,137, filed on Sep. 20, 2021, which is hereby incorporated by reference in its entirety.

BACKGROUND

One or more implementations relate to the field of Application Programming Interfaces (APIs), and more specifically, to a gateway configuration language.

As connectivity between computer and mobile devices continues to develop, applications have been developed that communicate and share information over these connections. Commonly, applications may communicate via an Application Programming Interface (API). An API is a software interface offering a service to other programs to communicate data. APIs may have several different components, such as specifications, markdown documents, etc. that constitute part of an API’s development. Further, there may be several computing jobs required in order to prepare an API for publishing and to publish the API. Some of these commands can be very expensive and time-consuming operations.

Many different API management products (e.g., engines) exist in order to monitor, secure and expose different APIs. These engines include nginx, envoy, and mule api gateway, among others. However, each of those different engines operates on its own language, meaning that code written for one engine is unusable for another engine. Sometimes, a company desires to migrate its API management from one engine to another. When this occurs, the code that was in place must be entirely converted for the new engine’s language. This can be extremely costly, ranging from the millions of dollars to tens of millions of dollars. Similarly, even within a single company, different engines may be used for different services. This requires knowledge of multiple different language and coordination between those different services. And any changes from one service to the other for a particular functionality will require the same level of conversion as required for other migrations. For example, commonly organizations protects their APIs with an ingress managed by one engine, but then use a different engine for their gateway solution.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated herein and form a part of the specification.

FIG. 1A illustrates a block diagram of an Application Programming Interface (API) environment, according to some embodiments.

FIG. 1B illustrates a block diagram of an Application Programming Interface (API) environment, according to some embodiments.

FIG. 2 illustrates a block diagram of an exemplary Application Programming Interface implementing the gateway configuration language environment, according to some embodiments.

FIG. 3 illustrates an exemplary construct of the gateway configuration language according to some embodiments.

FIG. 4A illustrates a block diagram of gateway configuration language modules as implemented in the Application Programming Interface environment, according to some embodiments.

FIG. 4B illustrates an exemplary embodiment of a gateway configuration language module for an API instrance in the API environment.

FIG. 4C illustrates an exemplary embodiment of a gateway configuration language module for a service in the API environment.

FIG. 4D illustrates an exemplary embodiment of a gateway configuration language module for a policy in the API environment.

FIG. 5 illustrates a flowchart diagram of an exemplary method for implementing gateway configuration language modules within an API environment, according to some embodiments.

FIG. 6 depicts an example computer system useful for implementing various embodiments.

In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

DETAILED DESCRIPTION

Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for implementing a gateway configuration language.

In some embodiments, a gateway configuration language is employed that is universally applicable to all different API engines and services. In some embodiments, this achieved by the gateway configuration language being generically defined and by referencing other modules within the gateway configuration language space. In particular, on the client side, the user/company (hereinafter “user”) devises a particular configuration for their API environment. This configuration will use one or more services that may operate in any number of different languages.

The user creates its configuration using the gateway configuration language described herein. As discussed in further detail below, this language utilizes modules that follow a common structure. These modules can then reference other modules to create a robust functionality set.

However, because the gateway configuration language described herein is not tied to any particular engine, it cannot directly communicate with any of those engine. Therefore, an intermediary is required in order to convert the gateway configuration language to the specific language used by the relevant engine. This intermediary functions as a translator, and translates the gateway configuration language to that of the relevant engine.

In an environment in which multiple different engines are used, it is necessary to include a different translator for each of those different engines. Code modules that are applied to a first service in the environment are translated by a first translator corresponding to that service. Similarly, code modules that are applied to a second service in the environment are translated by a second translator corresponding to that service.

As discussed above, a user may also decide to migrate from one service to another. Whereas previous implementations would require the user to completely recode the environment for the new engine, with the gateway configuration language of the present disclosure, the user need only replace the translator used with its current engine with a new translator applicable to the replacement engine. In other words, if a company seeks to migrate from Nginx to Envoy, the company need only replace the Nginx translator with the Envoy translator. However, in an embodiment, translators for common engines are supplied and/or made available to the user for easy transition. Thus, in this embodiment, the customer need not seek out a new translator, but rather must merely identify in some fashion that a different translator is to be used. The underlying gateway configuration language encoded configurations require no altering in order to function. This is a significantly less expensive option that recoding the environment.

In the manner described above, the user of the API environment has several options available when designing its API environment. Although the user is required simply to program a single set of instructions, these instructions are applicable to any combination of different engines. Therefore, the user is free to perform a complete migration from one engine to another, to mix and match different engines, and/or to swap out different engines at will.

Various embodiments of these features will now be discussed with respect to the corresponding figures.

FIG. 1A depicts a block diagram of an exemplary Application Programming Interface (API) environment 100, according to some embodiments. As shown in FIG. 1, environment 100 includes a cluster 105 that operates the API services. The cluster 105 includes several gateways connected to various services. As depicted in FIG. 1, each of the services corresponds to an API. Each of the gateways manages the communication to/from different services. For example, the ingress gateway 110 is positioned at the front of the cluster, like a door. All traffic seeking to come into the cluster must pass through the ingress gateway 110. The ingress gateway 110 includes any number of policies applied to the incoming traffic, such a security policy, authentication, etc. In some embodiments, the ingress gateway performs other tasks, such as application routing, rate limiting, request and response handling, etc.

Similarly, the Egress gateway 120 is also included at the outgoing edge of the cluster and applies policies to outgoing traffic. This may include, for example, data retrievals instantiated by one or more of the different services. Gateway 140 functions similarly to gateways 110 and 120, but applies internal policies on one or more services, such as services 130a and 130b.

In some configurations, a service, such as service 130c, may have associated therewith a sidecar (SC) 135. A sidecar is a separate container that runs alongside an application container in a Kubernetes pod - a helper application of sorts. Sidecars are sometimes used to aggregate and format log messages from multiple app instances into a single file. The SC functions similarly to a gateway, but is more specifically focused on the service to which it is assigned. In some embodiments, the sidecar 135 may perform peripheral tasks, such as platform abstraction, proxy to remote services, logging, and configuration, etc.

In the context of this disclosure, the various gateways house the proprietary coding languages. For example, each of the ingress gateway 110, egress gateway 120, gateway 140 and SC 135 may be designed by and use the language of one of nginx, envoy, or mule. Alternatively, some of the gateways may use the language of one such provider, whereas others may use the language of other such providers.

Therefore, in embodiments of the present disclosure, the gateway configuration language described herein along with any necessary translator module for the particular gateway language is provided in association with each of the different gateways, as illustrated in FIG. 1B. For example, as shown in FIG. 1B, a gateway configuration language (GCL) module 150a is provided for the ingress gateway 110. The GCL module 150a is coded in the gateway configuration language described herein. In order to allow the GCL module 150a to communicate with the ingress gateway, a translator module 155a is provided between the GCL module 150a and the gateway 110. Similar configurations are provided for each of the other proprietary gateways. For example, GCL modules 155b, 155c, and 155d are provided for each of the gateway 140, egress gateway 120 and SC 135, respectively. Similarly, translator modules 155b, 155c and 155d are provided for each of those GCL modules to allow them to communicate with their respective gateways.

FIG. 2 illustrates a block diagram of an exemplary Application Programming Interface implementing the gateway configuration language environment, according to some embodiments. As shown in FIG. 2, the API environment 200 includes a gateway configuration language program 210. The GCL program 210 may correspond to any of the GCLs 150 described above with respect to FIG. 1B. The GCL program controls any number of gateways, such as gateway A1 230A1, gateway A2 230A2, and gateway B 230B. In the embodiment illustrated in FIG. 2, gateway A1 230A1 and gateway A2 230A2 operate on the same proprietary gateway language, but gateway B 230B operates on a different language than that of gateways A1 and A2. In this embodiment, a single translator 220A may be provided in order to translate the GCL of the GCL program 210 to control the gateways A1 and A2. Meanwhile, another translator (translator B 220B) is provided to translate from the GCL to the language of gateway B 230B. In this embodiment, a single translator may be provided for multiple gateways that operate on the same language. However, in an alternative embodiment, a translator is provided for each of the different gateways regardless of the language used by those different gateways.

FIG. 3 illustrates an exemplary construct of the gateway configuration language according to some embodiments. As shown in FIG. 3, a gateway configuration module 300 is given a standard construct usable across all different implementations. In particular, each construct includes a header portion 305 with a number of mandatory fields that each follow a predefined format. For example, as shown in the construct 300, the header portion 305 includes at least the following fields: apiVersion 310, a kind 320, and metadata 330.

The apiVersion field 310 defines the type of schema, and particularly indicates which version of the schema is applicable. In other words, the apiVersion defines the group and version. In some embodiments, the apiVersion takes the form of a filepath. To provide an example, filepath gateway.mulesoft.com/v1alpha1 indicates that the module is associated with version v1alpha1 within the gateway.mulesoft.com group of schemas.

The kind field 320 identifies the type of the module. In embodiments, there may be several predefined types from which the designer can select, such as ApiInstance, Service, or PolicyBinding, etc. In other embodiment, the designer may be permitted to define their own module types. Lastly, the metadata field 330 defines the name and namespace of the given module. In embodiments, more or fewer fields may be defined as part of the standard header portion of the module.

Following the header portion 305 is the spec 340. The spec defines the actual functionality of the module 300. In embodiments, there may be several different fields available for use within the spec 340, none of which are mandatory. For example, the spec 340 may include an address field 342. In some embodiments, the address is a URL defining an address or port.

A targetRef field 344 can be used to identify a target of the policy, such as an API or API instance by referring to its name as defined in its metadata. The policyRef field 346 defines certain details relating to a policy module, such as its name and namespace. Finally, a config field 348 may be used to define the actual policy, such as for example by defining a path and destination for routing. Modules constructed in this manner are able to appropriately communicate with and reference each other in order to provide a robust API environment solution.

FIG. 4A illustrates a block diagram of gateway configuration language modules as implemented in the Application Programming Interface environment, according to some embodiments.

As shown in FIG. 4A, the environment 400 includes a gateway 410. An API instance 430 is provided to listen in the gateway 410. Meanwhile, a policy 440 is attached to the API Instance 430, and can reference a service (e.g., API). In some embodiments, the policy 440 may be implemented by an extension 450. In this exemplary configuration, gateway configuration language modules can be designed in accordance with the construct described above to provide gateway functionality within the environment 400. FIGS. 4B-4D, below, provide examples of such modules as may be used within those modules.

FIG. 4B illustrates an exemplary embodiment of a gateway configuration language module for an API instance within the API environment 400. As shown in FIG. 4B, the exemplary API Instance module includes a header portion 405b that defines the apiVersion, the kind, and the metadata of the module. The apiVersion of the exemplary module defines the version as the v1alpha1 version of the gateway.mulesoft.com group with the filepath “gateway.mulesoft.com/v1alpha1”. The kind field defines the module as an ApiInstance module, and the metadata names the module “ingress-http” within the e-commerce namespace. Finally, the spec 410b merely includes an address field that defines a port of the gateway being listed to.

FIG. 4C illustrates an exemplary embodiment of a gateway configuration language module for a service within the API environment 400. This particular module includes a header portion 405c. The header portion defines the version as v1alpha1, and in the metadata field, defines its name as “httpbin” and its namespace as “e-commerce.” The spec 410c one again includes only an address field that defines another port associated with the service.

FIG. 4D illustrates an exemplary embodiment of a gateway configuration language module for a policy within the API environment 400. This module includes a significantly larger spec portion 410d than the previously-described modules in order to accommodate the functionality of the policy being implemented. First, in the header portion 405d, the module defines the version as “v1alpha1”, and the defines the kind as a “PolicyBinding”. In the metadata, the name is defined as “ingress-route” within the “e-commerce” namespace.

In the spec portion 410d, several details are provided in order to define the policy functionality. First, a targetRef field names the API instance to which the policy is applied. In this case, the module 400D references the ingress-http API Instance described with respect to FIG. 4B. Much like the metadata filed of the header portion, a policyRef field defines information about the policy. In this case, the policy is named “route” because it is a routing policy, and exists within the gateway namespace because it applied to gateway functionality.

Lastly, within a config field the policy is defined. Specifically, in the example of FIG. 4D, a route field is defined. Within that field a path is provided for the destination of the ingress traffic. In the illustrated example, this corresponds to the pathway of the service 420: “/api/httpbin/”. Then information of the destination is defined within the destinationRef field, which defined the kind as a Service and provides its name as httpbin. In this manner, ingress traffic detected by the API instance 430 is routed to the service 420.

The above-described example is meant only to provide one example of a potential configuration. Importantly, the various modules implemented within the environment each follow a predefined construction. This construction includes defining a certain space within which they operate, such as a namespace or version, and providing each such module with metadata information that can be referenced by other modules in the environment, such as a name. By constructing the modules in this fashion and allowing each to internally reference the others using this same information, the full functionality of the environment can be realized. As discussed above, in order to apply the gateway configuration language functionality to the various proprietary modules within the environment, translators are provided either alongside the GCL modules or between the modules and the proprietary elements they seek to control in order to convert the functionality defined in the GCL module to one useable by the elements.

FIG. 5 illustrates a flowchart diagram of an exemplary method for implementing gateway configuration language modules within an API environment, according to some embodiments. As shown in FIG. 5, the method begins at step 510 with one or more modules being described using the gateway configuration language discussed above. As discussed, the modules are created using a predefined structure that includes a header portion with a plurality of required fields for purposes of labeling the module for both identification and reference purposes. Then, a body of the module included commands and references to other modules using another predefined format. In this manner, a universal construct is available for designing the functionality of an API environment.

In step 520, a language processor reads the GCL module(s) provided. In embodiments, the language processor functions as a parser used to read the GCL module and generate an output, such as a data structure. In step 530, the language processor outputs an internal model that is a representation of the data structure it generated in step 520. According to some embodiments, the internal model shows the data, extensions, and all the entities described by the various GCL modules. In some embodiments, the internal model may be a visual representation of the coded GCL modules and their interplays with one another. An example of such an internal model may appear similar to the block diagram of FIG. 4A. In embodiments, the internal model can be manipulated and changed in much the same way as a code-level modification.

In step 540, the internal model is provided to a gateway configuration generator. The gateway configuration generator converts (e.g., translates) the internal model to the specific gateway configuration. In other words, the gateway configuration generator takes the model of the gateway configuration and prepares it to actually function on a respective gateway. In embodiments, any necessary translation from the GCL to the proprietary language used in the particular gateway occurs at this time. In step 550, the gateway configuration generator outputs the completed gateway configuration.

Various embodiments may be implemented, for example, using one or more well-known computer systems, such as computer system 600 shown in FIG. 6. One or more computer systems 600 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

Computer system 600 may include one or more processors (also called central processing units, or CPUs), such as a processor 604. Processor 604 may be connected to a communication infrastructure or bus 606.

Computer system 600 may also include user input/output device(s) 603, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 606 through user input/output interface(s) 602.

One or more of processors 604 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

Computer system 600 may also include a main or primary memory 608, such as random access memory (RAM). Main memory 608 may include one or more levels of cache. Main memory 608 may have stored therein control logic (i.e., computer software) and/or data.

Computer system 600 may also include one or more secondary storage devices or memory 610. Secondary memory 610 may include, for example, a hard disk drive 612 and/or a removable storage device or drive 614. Removable storage drive 614 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

Removable storage drive 614 may interact with a removable storage unit 618. Removable storage unit 618 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 618 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 614 may read from and/or write to removable storage unit 618.

Secondary memory 610 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 600. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 622 and an interface 620. Examples of the removable storage unit 622 and the interface 620 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

Computer system 600 may further include a communication or network interface 624. Communication interface 624 may enable computer system 600 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 628). For example, communication interface 624 may allow computer system 600 to communicate with external or remote devices 628 over communications path 626, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 600 via communication path 626.

Computer system 600 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few nonlimiting examples, or any combination thereof.

Computer system 600 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computer system 600 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 600, main memory 608, secondary memory 610, and removable storage units 618 and 622, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 600), may cause such data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 6. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other.

The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A method for controlling a gateway in Application Programming Language (API) environment, comprising:

defining a module structure having a header portion and a spec portion, the header portion including a plurality of required fields;

receiving a plurality of code modules that each adhere to a defined module structure including a header portion and spec portion, the header portion including a plurality of required fields;

generating, from the received plurality of code modules, an internal model that represents functionality and interactions between the plurality of code modules;

translating the internal model to a proprietary language used by the gateway; and

implementing the translated internal model on the gateway.

2. The method of claim 1, wherein the header portion includes an identification field that uniquely labels the corresponding code module.

3. The method of claim 1, wherein the header portion includes a kind field that identifies a type relating to the code module.

4. The method of claim 1, wherein the code module further includes a spec portion that defines a functionality of the code module.

5. The method of claim 4, wherein the spec portion includes at least one reference to another code module.

6. The method of claim 1, wherein the internal model is a visual representation of the plurality of code modules, and

wherein the internal model is configured to be graphically editable such that edits to the visual representation of the code modules cause corresponding modifications to the plurality of code modules.

7. The method of claim 1, wherein the generating includes parsing the plurality of code modules.

8. A gateway for use within an application programming interface (API) environment, comprising:

a gateway configuration language (GCL) code repository that includes a plurality of GCL code modules, each code module adhering to a predefined structure;

a translator configured to: receive the plurality of GCL code modules from the GCL code repository; convert the plurality of GCL code modules from the predefined structure to a language used by the gateway; and

one or more processors configured to implement the converted plurality of GCL code modules.

9. The gateway of claim 9, wherein the predefined structure includes a header portion having a plurality of required fields, the plurality of required fields including an identification field that uniquely labels the corresponding code module.

10. The gateway of claim 9, wherein the header portion includes a kind field that identifies a type relating to the code module.

11. The gateway of claim 9, wherein the predefined structure includes a spec portion that defines a functionality of the code module.

12. The gateway of claim 11, wherein the spec portion includes at least one reference to another code module.

13. The gateway of claim 8, wherein the GCL code repository and the translator are included within the gateway.

14. The gateway of claim 8, wherein the GCL code repository and the translator are associated with the gateway.

15. An application programming interface (API) system, comprising:

a gateway;

an API connected to the gateway;

a plurality of gateway configuration language (GCL) code modules including a first GCL code module associated with the gateway and a second GCL code module associated with the API, each of the plurality of GCL code modules adhering to a predefined structure; and

at least one translator configured to convert the GCL to a second language used by at least one of the gateway and the API.

16. The system of claim 15, wherein the predefined structure includes a header portion, the header portion including an identification field that uniquely labels the corresponding code module, and a type field that identifies a type related to the code module.

17. The system of claim 16, wherein the predefined structure further includes a spec portion that defines a functionality of the code module.

18. The system of claim 15, further comprising a parser configured to generate an internal model of the plurality of GCL code modules.

19. The system of claim 18, wherein the internal model is a visual representation of the functionality and interaction between first GCL module and the second GCL modules.

20. The system of claim 18, wherein the internal model is modifiable.