EdgeBuilder Development Overview

03 August 2006

EdgeBuilder Documentation

This guide describes how to use the SCO EdgeBuilder™ Software Development Kit (SDK) to develop mobile digital services for the SCO EdgeClick™ Platform. This guide is accompanied by: API documentation in language-specific format (such as JavaDoc for Java APIs), and sample EdgeClick mobile digital applications. The sample applications allow you to see concrete examples of the components of a service, to use as a starting point for your development.

After reading this guide, you will understand the different components of an EdgeClick mobile digital service and how to develop custom applications for the EdgeClick platform.

The installation instructions, a quick start, and release notes for the EdgeBuilder product can be found in a separate document on the EdgeBuilder Download Web Site, or on the EdgeBuilder CD. See the EdgeBuilder Documentation Start Page for the complete list.

All the EdgeBuilder Documentation is contained in the Help file, launched by selecting Start-»All Programs-»EdgeBuilder-»EdgeClick Help.

Contents of this Document

EdgeClick Development Overview

SCO's EdgeClick is a platform for enabling, developing, and marketing a wide variety of mobile digital services. These services may be an adaptation of an existing application to give it a mobile presence, or it may be an entirely new application whose utility comes from the aspect of being mobile. Developers of mobile applications can use the SCO EdgeClick platform APIs and Services to implement solutions that allow mobile applications to be created and deployed with ease.

Each EdgeClick mobile digital service application consists minimally of a Client and an EdgeClick Processor (ECP). The mobile Client sends data to (or requests data from) the ECP; the ECP processes the request and, if required, sends a reply back to the mobile Client.

In more complex applications, the structure may be extended to include all of the following major components:

Clients
- Mobile clients
- Browser-based and PC-based clients
EdgeClick Processor
- Application services
- Web administration pages
Back-end Integration
- Agents
- Brokers

These components are illustrated in the following functional diagram.

In each of these components, EdgeBuilder makes available to you a set of services and APIs that makes programming in the mobile world simple and straightforward.

Mobile Client Development

Development of the mobile client portion of an EdgeClick application is dependent upon the mobile device being used. Typical languages for such development have included HB++ for PalmOS, Java for Java ME MIDP on a variety of client OS platforms (especially useful for less-than-smart phones), and C# for Windows mobile devices.

The mobile client portion of an application typically concerns itself with Forms or other GUI presentations to collect or report information. Communication with the EdgeClick Processor is done by sending CGI-based name/value pairs over HTTPS communication to the EdgeClick Processor, and receiving XML or some native format in return.

Certain functions common to all EdgeClick mobile clients are implemented in supplied libraries for common implementation languages, such as authentication and provisioning (including self-updating of new versions of the code), or can be reused from sample code.

EdgeClick Processor Development

The EdgeClick Processor executes within a Java application server as a Java EE web application. EdgeClick services are written in Java, and deployed within the running Java application server; simply copy the compiled service into the deployment area and you're done.

Details of the application server environment are hidden from what the server component of an EdgeClick application needs to know. Instead, EdgeClick-provided classes reveal an operating-environment-neutral API for getting commands from the mobile client and returning results back to it. Application services are then coded in Java and deployed on the EdgeClick Processor within the overall application server-based environment.

Typically, development of this Edge Processor component would be done using the Eclipse toolkit. Instructions for setting up the development environment are included below (under Using Eclipse to Build a Service), so that the edit-build-deploy-test cycle is as painless as possible. This development process is also not specific to any particular host operating system, since Eclipse and the other necessary Java infrastructure pieces can generally run anywhere.

Information needed from the EdgeClick Processor's local database -- regarding EdgeClick accounts, subscribers, groups, contacts, etc. -- is acquired through the API mentioned above. An EdgeClick service may also need to define its own local database on the EdgeClick Processor. This is typically done to keep track of agents, or to accumulate or cache information collected from mobile devices, or for various other reasons. An application service-specific local database may be defined and accessed by a variety of Java database techniques, including plain JDBC or an object-relational mapping framework such as iBATIS.

Web Administration Component Development

Some EdgeClick application services may require administration from an interface other than a mobile device. Such administration may involve defining the roles of different users within the application, defining where agents are, and a variety of other tasks. The mobile device is typically not a suitable interface for such administration because of limited visual real estate, and the possible need to import information from other files or locations.

Thus, a conventional browser-based interface is used for this administration role, implemented using Java jar files developed in the same environment as the EdgeClick Processor.

Agent Development

EdgeClick agents are the most varied of EdgeClick components in development terms, because they are the most tied to existing business application systems. Some EdgeClick applications do not need agents, because they only deal with entities already defined within EdgeClick's Enterprise Broker Component. (Brokers are specialized Agents that access Subscriber and Account data. More documentation on brokers will be provided in future revisions of the Developer's Guide).

For those applications that do need agents, an EdgeClick agent may be written in any language that supports SOAP/XML-based web services, and most commonly-used application development languages have such support. The tools to write agents will correspond to whatever language and application environment is required.

For existing applications that happen to be running on SCO Unix operating systems, SOAP and XML implementations are provided in five languages -- Java, C, C++, Perl, and PHP -- any of which may be used to write EdgeClick agents.

Work is underway to expand the Edge Processor-Intelligent Agent pathway to use Java EE Connector Architecture (JCA) for greater generality, allowing hundreds of existing industrial connectors and adapters to be used as part of EdgeClick agents.

Designing an EdgeClick Mobile Digital Application

The central value provided by EdgeClick is the ability to concentrate on the EdgeClick Processor (ECP) both the servicing of client access as well as the data processing required by the application. This ability allows internet-enabled mobile clients of many types to access data that is located on servers running behind a firewall.

To design an EdgeClick Mobile Digital Application, you first need to determine:

the data entry and display requirements for the client
the processing to be performed by the ECP
the data the ECP needs from servers running behind firewalls

As an example of one of the simpler kinds of EdgeClick applications, a simple poll-taking application might allow a service subscriber to send an email question out for a vote. The client interface includes forms that allow the subscriber to compose, address, and send the vote out to a contact list. Recipients of the vote interact with the ECP through HTTPS messages delivered from a variety of clients, such as smart phones and web browsers. The ECP handles the work of managing the contact, recipient, and subscriber lists; sending and receiving the votes; tabulating the results; providing a landing page where the results can be viewed, etc. The only data needed from outside the ECP is the corporate data (names, emails, etc.) required to send the poll. This is done without the need for any agents, but rather a simple broker that keeps the subscriber database local to and used by the ECP in sync with the corporate database -- all the processing takes place on the ECP.

Such an application is an example of a Self-Contained EdgeClick Application. In general, we can break down EdgeClick applications into four broad categories; the categories and their major characteristics are listed in the following table:

Self-Contained Applications Focus is around subscriber data (groups, contacts, etc.) ECP performs most or all data processing ECP stores application data in local databases Do not connect to existing applications (require no agents) Often do not require web admin pages Can be tied to "landing pages", application web pages	Business Integration Applications Connects to an existing application requires agents Purpose includes: data collection data processing transaction processing ECP primarily acts like a switch; the ECP database is used to route a request to the proper agent Processing done by agents and clients Web admin pages are required to manage the agents
Heartbeat Applications Variant of a Business Integration application Tracks vital business and system metrics: View health indicators (business statistics, system performance monitors, etc.) Receive alerts based on user-defined indicators Take actions to correct problems Combines a Service Oriented Architecture (SOA) with an Event Driven Architecture (EDA)	Mobile Database Applications Full application database and processing is located on a mobile client Data is periodically synchronized with a server Very client-centric

These groupings are somewhat of an oversimplification, but are useful to consider when designing an EdgeClick application. Often, you can start designing your application as a self-contained service, for example, and build it up in complexity as you become more familiar with EdgeClick services.

The following sections summarize the design considerations for each type of EdgeClick Application.

Designing a Self-Contained Application

Self-contained applications minimally require:

A client interface that accepts user input, sends commands (via HTTPS) to the ECP, and displays responses from the ECP.
A Java servlet that runs on the ECP, receives HTTPS requests from clients, and does all of the processing required to fulfill client requests.
A local database on the ECP that contains all the data required to fulfill client requests.

To create these components, you need to:

Understand the EdgeClick semantics in the Commons library for programming the Java servlets that run on the ECP. The entities defined by this library (accounts, domains, subscribers, contacts, etc.) are often used quite heavily in a self-contained service.
Design the flow of information between the client and the ECP. This includes:
- the user interface forms used on the client
- the command parameters to be communicated between the client and the ECP
- the XML returned to the client by the ECP
Design the Java servlet and the ECP database schema; this data is typically the information that needs to be maintained persistently on the ECP.

Designing a Business Integration Application

Business Integration applications minimally require:

A client interface that accepts user input and sends commands (via HTTPS) to the ECP.
A Java servlet that runs on the ECP, receives HTTPS requests the client, and essentially acts as a switch to send the request to the proper agent for processing. It also manages communication failures with the agent, etc.
A small local database on the ECP.

To create these components, you need to:

Decide what existing application functionality will be exposed to mobile clients.
Design the flow of information between the client and all agents (the ECP is mostly just relaying client requests to agents).
Determine where the agent needs to be executed (on what system) and how it would be written. This is dependent on the existing application being accessed by the agent, as well as the capabilities of the system hosting the agent. Most of the effort in designing a business integration service will be focused on the architectural decisions involved in designing agents. Firewall and Internet access issues also need to be considered.
Design the Java servlet and the ECP database. This will mostly used for Identification and Authentication of the client request, and to direct client requests based on subscriber data.

Designing a Heartbeat Application

Heartbeat applications minimally require:

A client interface that accepts user input and sends commands (via HTTPS) to the ECP.
A Java servlet that runs on the ECP, receives HTTPS requests the client, and essentially acts as a switch to send the request to the proper agent for processing. It also manages communication failures with the agent, etc.
A small local database on the ECP.
Agents that provide the processing and data needed to satisfy client requests.

To create these components, you need to:

First, design the Agents and the data and services that will be provided by them to the client. The data could be any metric or data tracked by the business: e.g., sales figures, inventory statistics, computer system availability and performance, application availability, building environment conditions, or power levels on devices. Services provided could include interpreting and displaying data, responding to alerts set by the client, and performing corrective actions on the client's behalf.
Design the client user interface and flow of information between the clients and all agents for displaying data, setting alerts, and performing corrective actions. User interface is more important here than in simpler applications, because the amount of data that needs to be manipulated by the client may be large. The ECP becomes essentially a formulaic relay between the clients and agents.
Design the Web Administration pages required on the ECP; this follows directly from the design of the agents and flow of information. These can be complex, depending on how the alert and action services are structured; for example, new groups for defining (restricting) who can receive alerts and who can take certain corrective actions may be needed.
Design the Java servlet and the ECP database. This will mostly used for Identification and Authentication of the client request, and to direct client requests based on subscriber data.

Designing a Mobile Database Application

Mobile Database applications minimally require:

A client interface that performs all data processing on data that is located on the client. The client usually contains a complete application database, and may not need to request information from the ECP or agents. The user input forms may be complex, depending on the application. The HTTPS command interface may be limited to requests to synchronize local data with a back-end server.
A Java servlet that runs on the ECP, receives HTTPS requests from the client, and essentially acts as a switch to send the client data to the proper agent for processing. It also manages communication failures with the agent, etc.
A small local database on the ECP.
Agents that receive client data and synchronize it with the required server.

To create these components, you need to:

The choice of mobile client device is critical to the design of a mobile database application. The goal is to pick a device that satisfies the needs of the application at a reasonable cost. Memory card size, media capture capabilities, programming technologies, file and database handling capabilities, screen size, keyboard, etc., will be key considerations.
Design the Java servlet ECP database. This will mostly used for Identification and Authentication of the client request, and to direct client requests based on subscriber data.