X-UP is a framework for easily creating a new dataset by processing data from various sources.

X-UP consists of X-UP Model, X-UP Builder, and X-UP Server technologies. This chapter describes these three technologies and the X-UP Administrator service.

X-UP Model

To collect and amalgamate datasets, a variety of information referred to as metadata must be configured. In addition, business logic must be defined to determine each value. The metadata and user logic required to collect and amalgamate datasets are collectively referred to as an "X-UP Model."

An X-UP model contains the metadata and logic for actual mashup and is developed using X-UP Builder. An X-UP model - developed in X-UP Builder - is deployed on an X-UP Server, and when an external request for driving is received by an X-UP Server, the server then drives the corresponding model.

All operations in X-UP are performed in X-UP model units. Development and deployment in X-UP Builder are conducted in X-UP model units as are the external requests for processing. For example, after developing and deploying to an X-UP Server--an automation model named "Cat," data is collected and processed from a model externally referred to as "Cat" and results are received.

An X-UP model can utilize a variety of data sources and define a method for collecting raw data from said sources. Furthermore, you can define a method for converting collected raw data into formalized datasets or amalgamate multiple datasets into a single dataset. Methods for converting collected raw data into canonicalized datasets can be defined or multiple datasets can be amalgamated into a single dataset. If necessary, an X-UP user can add any logic required for collecting or amalgamating data in an X-UP model.

Domain

In X-UP, a domain refers to a single project.

X-UP models are distinguished by each domain. For example, if a model named "Order" exists for a domain named "petStore" and another model of the same name exists for a domain named "flowerStore," each model is treated as a separate entity. Although the names of both models are the same, they are distinguished because they belong to separate domains. Therefore, both the domain name and X-UP model name must be specified when an external application calls X-UP.

The target domain name can be set when an X-UP project is created by X-UP Builder. An X-UP project created by X-UP Builder is equivalent to a domain. A single X-UP project may not have multiple domains, and a single domain may not be shared by multiple X-UP projects. If multiple X-UP projects are deployed on an X-UP Server using the same domain name, the preceding model will be overwritten by the following model rather than both models coexisting.

Automation Model

An automation model is a type of X-UP models, and its algorithm, which constitutes a service, can be expressed by a diagram using the GUI editor. The diagram, called invoke, will obtain data from random data sources. Data information for obtaining data is written by using the editor and Property View of X-UP Builder. When an automation model is created, a resulting Java class code is automatically generated. If users make changes in the models through the GUI editor, those modifications will be automatically applied to relevant class codes.

MetaData

Metadata stores a wide range of configuration information for an X-UP model to operate. Metadata serves as criteria that allows an X-UP server to load a model as well as the logic class of the model. Moreover, metadata contains schema information on model versions, character sets, and inputs/outputs. Therefore, it can provide information on the interfaces designed for the connection with Nexacro applications.

Logic Class

For an X-UP model to operate actually, the relevant Java class that contains algorithms must called. X-UP Builder automatically generates such a Java class, which is in turn compiled and deployed to an X-UP server. In most cases, there is no need to modify an automatically-generated Java class. Sometimes, however, you cannot develop your intended algorithms just with the features provided by X-UP Builder. Then, you need to fine-tune an automatically-generated Java class.

When the model wizard creates an X-UP model, it also automatically generates a Java file that corresponds to the type of the X-UP model. For example, if the name of an automation model is "Cat," "CatAutomationLogic.java" file is automatically generated. Afterwards, you can develop your desired algorithms by adjusting the generated Java file.

X-UP Server

An X-UP Server drives a deployed X-UP model and operates as a web application in the WAS. Only the logic for collecting, amalgamating, and processing data is developed in X-UP Builder, and the actual function is run on an X-UP Server. The X-UP Server bundles each service provided by X-UP.

X-UP Server is supported in the following environments:

Installation

1. Install a WAS to create an X-UP Server. Apache Tomcat 6.0.35 is used for the purposes of this user manual.

2. Extract the downloaded apache-tomcat-6.0.35.zip file to the C: drive.

3. Copy the xup.war file to the webapps directory, the default host's appBase for Tomcat.

4. The xup folder will be created in the webapps folder when Tomcat is restarted.

5. Register the server license. Please refer to the “License Registration” section below for details.

X-UP Server File Structure

The X-UP Server file structure is as follows: Tomcat is used as the WAS for the purposes of this user manual. The figures below show the subdirectory structure under the [webapps > xup > WEB-INF > xup] folder for Tomcat WAS.

License Registration

The license must be registered to properly utilize X-UP functionalities. This section describes the license registration process for the X-UP Server installed on a WAS such as Tomcat and WebLogic.

1. Install X-UP on a WAS.

2. Copy the license file (X-UP_Server_License.xml) received at the time of purchase into the conf folder.

3. Restart the WAS.

Bundle Install and Uninstall

A bundle refers to a module unit such as an invoker that operates in an X-UP Core or a data source.

The types of bundles provided in X-UP are as follows:

• DataSource Type: An agent that obtains raw data from an external connection by using data sources.

• Invoker Type: An agent that processes data acquired by a DataSource type bundle to run a service that accommodates the flow specified by an X-UP Builder user.

  • Two subtypes, a gatherer and an invoker, are provided.

A connection generated by a DataSource type bundle features a unified management system through a data pool.

Bundle Installation

Bundles are installed automatically by the core when X-UP is run.

The bundles are extracted only once the first time X-UP is run as long as the version does not change by using the bundle and engine (X-UP Server Engine) versions.

Bundle Uninstallation

To uninstall a bundle, delete the respective bundle folder and compressed file.

Bundle Repository

You should see the following directory structure when a bundle is extracted:

• conf: This folder contains the bundle_config.xml file, which contains the configuration information required when a bundle is run.

  • The configuration can also be applied by assigning the information in the xup_config.xml file.

  • Settings priority: xup_config.xml > bundle_config.xml

• lib: This folder contains the dependency libraries that are required by a bundle. Each bundle is loaded by a separate ClassLoader. This ensures the independence of the library used.

• META-INF: This folder contains the MANIFEST.MF file, which records a bundle's meta file information.

X-UP Builder

The X-UP Builder is a tool for developing X-UP models.

X-UP users can quickly and easily develop X-UP models using X-UP Builder. Services developed using X-UP Builder call X-UP libraries, and X-UP libraries collect and amalgamate data using deployed models and return generated datasets.

X-UP Builder provides drag and drop functions and an intuitive GUI editor to visually develop, test, and deploy models on a server. The features included in X-UP Builder allow easy development even for inexperienced developers.

X-UP Builder was developed on the Eclipse Platform using JDT, EMF, and GEF libraries. The JRE and Eclipse library versions used in X-UP Builder are as follows:

The features provided in X-UP Builder are as follows:

• Create X-UP Project

• Define DataSource

• Find and View DataSource

• Model Test

• Debugging

• Deploy to Server

• Validate

• Refactoring

• Reporting

X-UP Builder File Structure

The X-UP Builder file structure is as follows:

Logic classes are located in the logics folder. Logic classes are created by default without package names, and the logics folder is registered in the class path.

The logic classes generated by an X-UP model are divided into user logic and base logic classes.

The user logic class is a class file with pre-defined interface methods for holding separate logics when a user develops a model. The class is automatically generated when a model is first created, and the class name is automatically registered under the logic property value.

The base logic class is also automatically generated when a model is created. However, this logic class is hidden from- the user by default, and its contents are automatically updated whenever 'Save' is used in the editor. In other words, even if the contents are modified, it will be recreated as the editor automatically updates the logic class. This base logic class is hidden by default, because the user does not need to know its contents during model development.

The userLib folder is automatically generated when a user library is registered through [Project > Import > X-UP > User Library]. All .jar files are located in this folder.

When model development is finished and it's deployed to the server, all .jar files that exist in the userLib folder are added together with the logic class.

All developed X-UP models are located in the models folder. All .xam files must be in the models folder.

The GlobalEvents.xaop file allows you to set configurable events in all developed models on a global basis. You can perform I/O data verification and data source changes. The setting is optional.

The mashup.msh file contains important information required during model development in an X-UP project such as a server URL for deployment or data source information.

X-UP Administrator

X-UP Administrator is an administrator service.

X-UP Administrator allows you to check hardware and software specifications for an X-UP system through a browser as well as view and control logs and deployed X-UP models.

After logging in, you can view a list of deployed domains and their resource and history information. It provides system monitoring and notification services for convenient operation and management.