This scenario is largely the same as the API Transformation scenario from an installation perspective. The only difference is that the requests in this scenario comes from end users rather than server applications and the target for the requests are existing web applications or Software as a Service applications.

This scenario lends itself to a myriad of use cases:

• Digital transformation, where an existing application (often beyond the control of the business) is functionally enhanced, without the explicit need for the existing application being aware of these changes

• Bot management, where the X Engine detects bots and adds policies for how those bots are able to access the underlying application

• Robotic process automation where requests to the existing application results in data also being entered into secondary systems

• Orchestration of multi existing applications that are joined together to form a new experience

• … and many more

This scenario is especially useful for regaining control of web applications that are otherwise difficult, expensive or impossible to change

Each X Engine is controlled from a Composable Architecture Platform Console. The console is a web application. Any information pushed to the X Engine from the console is stored in the X Engine’s home folder. This includes any software required to execute the rules.

It is important to note that the X Engine and the console are autonomous entities. They do not need to be connected for the X Engine to execute rules.

In this scenario the X Engine is installed alongside the Composable Architecture Platform Application Server and they work as an integrated whole, turning the X Engine into a high-performance HTTP proxy with the ability to provide SSL termination and on the fly transformation of requests and responses between the existing applications and the existing APIs.

Use cases for this approach include:

• Vendor abstraction, which provides the ability to create generic APIs for things such as text messages, geo-location, two-factor authentication and use those APIs in the existing applications instead of vendor specific APIs

• API Sunsetting, where the X Engine is capable of transforming the structure of an API call between different versions, such as to facilitate the removal of older version code from the API server source code

• API Accounting, enabling chargeback of API calls that have a monetary cost to the respective users of that API

Installing the X Engine as a Servlet filter in a Java Application Server (such as Jetty, WebSphere, JBoss etc.), is a common approach. In this scenario, the X Engine is acting like a Servlet Filter sees all requests coming in and has the ability to modify the request before it reaches the web application. Similarly, is also sees every response coming back from the web application and it has the ability to modify these responses on the fly.

Use cases for this approach mostly centre around making temporary changes to an existing web application, out of band of release cycles, or when the web application is third party and not able to be modified.

Examples of such temporary changes include:

• Adding security such as CSRF or SQL Injection protection

• Frequently changed compliance rules that can be required on short notice

In this scenario, the X Engine is configured as a proper web application server. It is capable of serving up content, including multi-media and other web assets. Rules are used to create a dynamic user experience.

Use cases include:

• Web forms that capture data on a single page and disperse it into one or more locations

• Dashboards that capture data from multiple different sources and serve up a singular view for all those sources

• Fully fledged stand-alone web applications

In this scenario the X Engine is configured to work as an application server with the ability to create client-side rules for validation, data storage and other mobile device features.

The client-side X Engine is running entirely in JavaScript and is portable across any mobile device with a browser. It creates a native look and feel mobile experiences using pure HTML5, CSS and JavaScript.

Use cases include:

• Rapid mobile application prototyping

• Offline/Online mobile data capture

With the active proxy and the web application server used in combination, in this scenario the X Engine can be configured to act as a proxy that has the ability to add content.

Use cases include:

• Customisation of the user experience of a SaaS application, without the knowledge of the SaaS provider

• Mobile enablement of an existing application without any changes

• Adding two-factor authentication to an existing insecure application

• Short lived campaigns and surveys that would otherwise clutter the target application code

Composable Architecture Platform can be installed in a number of different ways. The following section highlights the most common scenarios.

In its simplest form, the X Engine receives data from a file (CSV, XML, Spreadsheet) and processes it by interacting with databases, APIs or other servers.

The X Engine in this form requires very little other than a software platform with Java and the X Engine core installed, a configuration file and a home folder. Upon deployment of rules, the console will deploy all other required dependencies along with the rules.

The Asynchronous multi-protocol scenario operates at the network packet layer and expands the reach of the X Engine from HTTP into other protocols. TCP and UDP packets are supported.

To facilitate this approach a secondary protocol level engine breaks down the packet into elements the main X Engine can understand. The X Engine can then modify these elements and the underlying protocol packet will be changed accordingly. The X Engine is then able to forward the modified package to the designated network endpoint and can even in some instances commence a chat with the endpoint before forming a response packet for the initiating computer. As always, the X Engine can rely on secondary data sources (APIs, data, other systems) to help form the modified request and response packets.

Use cases for this scenario includes:

• Database field level security

• ATM stand-in

• SCADA security

• Advanced DNS

• … and many more

In addition to protecting internal websites from attacks and fraudulent activity, Composable Architecture Platform can also be used to monitor employee’s interactions with external websites (such as social networking sites, blogs and wikis). The most common use of this feature is for internal users to limit access to specific sites (for example Facebook and Twitter) for business purposes.

The following diagram illustrates how Composable Architecture Platform can be configured to monitor all traffic going to one or more nominated sites:

The key to this feature is to introduce a second DNS server within the company infrastructure. This second DNS server provides an override IP address for sites that are monitored by Composable Architecture Platform, ensuring that all the traffic is visible to the appliance. The monitoring appliance can be hosted and managed by an external service provider or can be installed in-house.