IntelliPortal is an innovative, client/server framework and software development toolkit for delivering products, services and information over the Internet. You use IntelliPortal to create, publish, and administer channels of content that you transmit from a server environment to a client application that resides on your customer's PC.
Unlike a Web browser, with IntelliPortal you create a branded, customized, self-contained environment that displays only the content you want and effectively delivers a captive customer audience for your products and services. You can include links to Web sites or other Internet resources (but only the links you want your customers to see and use) to create a feature-rich solution that aggregates your own offerings with those from selected partners and provides your customers with a complete view of their entire financial position.
IntelliPortal is available in two packages: the IntelliPortal Production System and IntelliPortal QuickStart. Both versions include a Developer Toolkit that you use to create your content channels and link them to your proprietary data sources and those of your partners. You determine where and how these content channels appear in the client application, and you can brand the client application with your corporate identity and marketing and advertising content.
IntelliPortal's client/server infrastructure manages the publishing and delivery of channels to your customer's client machine. The IntelliPortal server manages client sessions, the acquisition and packaging of automatic data feeds, scheduling and delivery of personalized and targeted content, message and transaction formatting and routing to application servers. The IntelliPortal server also manages the distribution and updating of the client application (including content, channels, and data) with an automated background process that occurs whenever your customer connects to you over the Internet. You can distribute the IntelliPortal client application to your customers via your Web site, a simple bootstrap, or media such as CD-ROM.
___________________________________
IntelliPortal consists of a variety of server processes, as well as a customized client application with the "look and feel" of your own institution. It includes a variety of applications, content presentations, and sample channels that can be configured by individual financial institutions for delivery to end users. It supports various forms of content including HTML, Java, and other media.
IntelliPortal can be architecturally divided into a delivery vehicle and the content that is delivered. It is a delivery vehicle in that it that allows end users to subscribe to various applications and features which are then delivered to their machine. This vehicle provides a structure within which subscription content is delivered. The delivered content consists of both the application software and any dynamic content that might be associated with the software. Since the applications themselves are independent of the delivery vehicle and of other applications within IntelliPortal, many kinds of applications and content can be delivered without changing the vehicle. This is a function of the applications themselves and not of the IntelliPortal delivery system.
The delivered content may also include specifically-targeted content (such as marketing messages or advertisements) that is based on demographic and usage patterns collected from the client subscriber who is being updated. This guide explains how to develop channels within the guidelines and constraints of the IntelliPortal application environment.
IntelliPortal uses a client/server environment. On the client side, there is a container application (the client shell) that serves as the site within which the various channels are run. It also acts as a tuner to connect to the servers which are the transmitters for various IntelliPortal channels. The tuner is the client-side environment that installs applications, applies updates, and provides feedback on how the channel is being used. It tracks channel usage and relays this data back to the transmitter during the update process.
On the server side, a transmitter services the tuners and provides the mechanism by which new software and content are downloaded to the client. The channel delivery system tunes to a specific transmitter to obtain software and content updates on a regularly scheduled basis using an automated background process that occurs whenever there is a TCP/IP connection. As part of the update process, the tuner sends a usage report of the installed applications which the server uses to customize the update stream back to the client. The server manages client sessions, acquisition and packaging of automatic data feeds, content delivery, and routing to application servers.
Channel publishing is done in the server environment. A published channel is a channel that is available on the server for delivery to end users. Additionally, you can define a variety of external data sources that can feed individual channels whatever dynamic or personalized content is desirable. The structure and source of the channel data is defined using the administrator tool on the server and by using an API into and out of the channel that is used for updates. This lets each channel fetch user data from the channel profile and log and then push new content into the user version of the channel for delivery.
The client container is the single point of end user interaction with the application. The client is both the tuner and the shell application within which individual channels are displayed. The client container is itself a channel allowing dynamic updating of the tuner software. As shown in the following illustration, the IntelliPortal client has four major components.
The ITunerEventService is a delivery method for system and user-defined messages within IntelliPortal. Any class that implements the ITunerEventService interface can send and receive messages. The TunerEvent class contains the details of a message published by the ITunerEventService. The details include event name, channel name, optional string parameters, and a shared object for arbitrary values.
An object can subscribe to certain TunerEvents by registering as a listener with the ITunerEventService and passing a TunerEvent object as an argument that details the type of message they want to receive. You can further refine the scope of TunerEvents so that you are only notified of events on a certain channel, and then only when those events match specified criteria. Classes can publish messages to the ITunerEventService by creating a TunerEvent object and calling the static publish() method. The publish is synchronous so that you are notified of any errors or exceptions.
You can start/stop, subscribe/unsubscribe to channels using the ITunerEventService. The TunerEventsConstants interface contains a list of system events and their parameters that are used in the construction of TunerEvent objects. You can use the event names in TunerEventConstants to publish TunerEvents that let the channel communicate with the tuner and other IntelliPortal facilities. You can also create your own TunerEvents so that channels can communicate with each other.
This is the application interface that allows applications (i.e. channels) to be aware of the context in which they are executing. A channel must implement this interface to run in the IntelliPortal client shell.
This interface lets channels access services provided by the client application. It encapsulates much standard channel communication and provides additional IntelliPortal-specific methods. It provides access to information about the environment and other channels, and provides access to the Service Interfaces.
IMecaApplicationContext is the single point of contact among the client, the tuner, and the channel. It provides additional features such as a shared directory across multiple channels that lets IMecaApplicationContext encapsulate much standard channel communication within a single object.
The client shell displays an integrated, graphical user interface that you can customize. It also manages the execution and presentation of application and content channels (including HTML), permits the end user to subscribe to your channels, and tracks their usage patterns. The client shell acquires and starts channels and starts the layout environment. It receives dynamic updates from the IntelliPortal server, updating each channels at a specified interval and also provides a help channel for end users.
Channels are logical modules of content (including application software and/or data) that are delivered to a client from the IntelliPortal server. Channels include both application channels that present user content and system channels that run independently and perform system tasks.
Channels are delivered as files (collections of bytes) that can consist of executable software, media content, data, or any combination of the three. Channels are updated from the server using a mechanism to ensure that the same bytes reside on the client as are published to the server. There is the added ability to tailor the bytes sent to a specific client machine based on the identity of the user being updated. Once the files have been delivered from server to client, they can be accessed offline when a network connection is no longer available.
The major elements of channel design, content, and functionality are flexible and can be used to implement a wide variety of concepts. For example, you can create a "banking channel" that provides a variety of online and offline banking capabilities or you could create separate channels for bill-pay, home equity loans, etc. Depending on product requirements, channels may or may not be visible. Invisible channels are usually helper, or administrative channels. They are not visible in the channel menu and need to be started automatically or by a request from a visible channel.
An application channel is a collection of files that you "publish" to a transmitter. They can be Java class files, JAR files, ZIP files, HTML, images, sound clips, video, etc. The client shell on a user's machine can "subscribe" to a channel and replicate the channel files on that machine. On a client machine, a Java-based channel is represented by a ChannelItem object. When a user clicks a ChannelItem in the channel menu to start a channel, the tuner first determines whether the channel is already running. If the channel is running, the tuner makes it visible. If not running, the tuner loads the class specified as Main in the properties.txt file and executes the start() method of the IMecaApplication interface.
Only one instance of a channel can run at a time, but each channel has its own properties and parameters. This means you can have one instance of an accounts channel configured (in properties.txt) with different start states (e.g. checking and savings). This makes them look like different channels. You can also publish the same set of files twice as two different channels. In this case, the channel menu can contain both channels, and one instance of each channel can run simultaneously (even though both use the same Java class files). With the IntelliPortal file cache, you can publish two sets of the same files, although only one is actually stored on the client machine, thus reducing disk usage for duplicate channels.
Channels can be HTML-based or Java-based and can include videos, advertisements, etc.
IntelliPortal lets you implement your own choices with respect to product design and channel mix. You can organize and associate channels into categories (a grouping of channels with a similar topic, e.g. investment options) when you publish the channel. The client application uses this category association to build a list of categories and the channels within each category. This list is displayed in the channel menu and lets users choose which channels they want to run. Each channel can only be associated with one category which is assigned with the category property that is published with the channel.
A system channel performs system tasks such as displaying the channel menu and other housekeeping functions such as usage tracking and logging. They may be visible or invisible. The ticker channel and the alert channel are visible; usage tracking is not.
The interface IMecaApplicationContext is given to all channels that implement IMecaApplication at startup. This interface provides the services that are available to channel developers. The services shown below perform common tasks. The list of services for each channel varies according to which services you choose to implement for that channel but all implemented services start when the tuner starts. For a more detailed explanation of these services, see Client Services.
The MECA Storage Facility (MSF) has two parts: persistent storage and directory storage. Persistent storage is basically a structured storage and retrieval area that lets channels share resources and stores transactional data that can be carried over to future sessions. It can enable an offline mode so that channels can use the data offline if they are designed to do so. This allows channels to maintain state and shutdown data and to reload with knowledge of their prior state.
Directory storage is channel-related. Each channel has access to a data directory, a base directory, and a shared directory. See Using Triggers and History for more information.
HTML rendering is provided for rendering HTML 3.2 tags and running Java applets. It currently does not support JavaScript. (JavaScript availability is planned for the second half of 1999).
The Java Media Framework (JMF) is a collection of classes that enable the display and capture of multimedia data within Java applications and applets. It specifies a unified architecture, messaging protocol and programming interface for playback and capture of compressed streaming and stored timed-media including audio, video, and MIDI across all Java-enabled platforms.
The server provides a transmitter to service the client tuner. It publishes and delivers software and content and provides an interface to the profile/target engine. It also provides an interface to retrieve data from external legacy systems using a set of customizable adapters. The server has database storage that also includes an area for persistent or transient user data (e.g. userids, passwords, etc.) needed by external adapters.
Communication between the client and the server is either secure or non-secure. Clients can communicate with the server over an encrypted secure-socket link (SSL) or they can receive non-secure information directly from channels. Typically, an SSL link is used for transaction processing or other communications that needs protection (balance inquiries, fund transfers, etc.). Non-secure communication can be used for news feeds, stock prices, etc., as well as for client software installation and maintenance.
All client/server communication (secure and non-secure connections) is processed by an instance of a DataFeed. DataFeed sends the request to any of a number of different adapters which are the hooks connecting IntelliPortal to external applications, legacy data sources, etc. The entire IntelliPortal system (all client/server software) is written in Java and uses Java Bean component architecture wherever appropriate. All communication within IntelliPortal, including client/server communication, uses the Open Financial Exchange protocol. The protocol is encapsulated within OFX Java Beans.
IntelliPortal lets you distribute, install, and update software and content over the Internet. MecaPlugin is a class which provides the "hook" whereby files and data can be added or deleted from the channel.
MecaPlugin supplies customized data to clients via channel updates. Client requests are buffered in a log stream that is read by MecaPlugin. Based on the log stream and the profile data stream, MecaPlugin prepares channel requests for data. It uses two database tables to interpret the data from the log and profile streams.
DataFeed manages data on the server. It caches, fetches, and distributes data to MecaPlugin (and others). It is the standard interface through which requests for information are routed to external adapters. DataFeed is implemented differently depending on whether the information request is from the MecaPlugIn (data transmitted over a channel) or whether it is an encrypted SSL request (data transmitted through a socket connection).
The IntelliPortal server requires an Oracle database that provides permanent and temporary storage areas on the server for user data. Permanent storage holds configurable data (e.g., name, passwords, etc.); temporary storage is used by adapters to hold user data that cannot be downloaded until a connection is established.
You access the Oracle database through Java Database Connectivity (JDBC), an industry standard for database-independent connectivity between Java and a wide range of databases. You can choose to use another type of server database (for example, a database you have already), as long as it is accessible through JDBC. If you want to use a different database, MECA's Professional Services can assist you with the implementation.
IntelliPortal communicates with outside data sources using external adapters. Adapters are the hookpoints into the server from outside data sources. IntelliPortal provides flexible adapter interfaces so that you can connect to external application, content, profiling, advertising, and transaction servers.
External adapters are implementations of IAdapter. They are designed to be extended into specific protocols so that the server can communicate with external systems. On the outside, they provide a uniform interface to DataFeed; on the inside, they are customized as needed to get data from the actual source.
BaseFinancialAdapter is an implementation of IAdapter which has added functionality for financial processing based on OFX. It is a class that provides an interface to existing financial systems. The basic function of the class is to take a transaction request from DataFeed and make the information available to an extension. It also gets information back from the extension, producing and sending OFX back to the DataFeed. The adapter is passive, meaning that it is the function of the extension to request and set the information it requires. There are two ways an adapter and extension can communicate.
When an extension receives a response from the external data source, it requests that the adapter send the data back to the client. The adapter is also responsible for storing each request and response as part of a process that ensures reliable client/server communication.
An adapter extension is responsible for getting information from the adapter and assembling it into the protocol of the legacy system. It then communicates with the legacy system or data source, and gets a response. The simplest example of an extension is one that talks OFX through a secure socket to a legacy system. In this case, the extension establishes a socket connection to the legacy system, requests the transaction data from the adapter as an OFX stream, and then sends it and waits for a response. When done, it sends the information back to the adapter as an OFX stream.
The extension drives the adapter and the adapter will likely have a superset of the necessary information. For example, the legacy system will likely require signon information. The extension in turn would ask the adapter for username and password. The adapter will likely have other signon information not needed for this extension.
IntelliPortal has built-in APIs to the client services for alerts, usage tracking, bookmarks, layout, etc. so that you can use them when building channels. The services explained below are available to channel developers. All services are exposed by the method getServiceProvider which returns IServiceProvider. You can also use the shortcut method IService.getService(String). See the corresponding javadoc for methods and additional details.
You use the Alerts Service to notify customers of a condition that requires attention or may be of special interest to them. In the client application, Alerts display in the panel represented by Important button at the top of the client shell. You can customize this button if you want. You can use the trigger mechanism as a convenient way to cause changes in channels based on a set of criteria that you establish and manage in advance. For example, you would use triggers to enable your channel to take advantage of the client application's Bookmark Service (see Bookmark Service) and History Service (see History Service). Or you can use a trigger to cause a video to play as a result of an HTML page being loaded. for more information.
This service changes the appearance of the cursor into one of two states depending on whether a channel is busy or working. It is typically used when a section of code is executing that may cause the channel to appear unresponsive or when it is useful to freeze the application entirely.
This means that depending on your application requirements, you can change the cursor into either a "working in the background" state that allows limited user interaction or into a "busy" state that allows no interaction. The cursor remains in the selected state until released.
A bookmark is a pointer to a channel in a particular state or condition. Bookmarks let users mark a specific location in a channel that can be revisited later. You decide which parts of a channel (e.g. which HTML pages) are "bookmarkable." Any channel can be bookmarked to its initial state.
Bookmarks appear in the channel menu in the special bookmarks category. A bookmark does not change or restrict channel functionality; it is simply a way to restore or start the channel in a particular state or condition. Only one instance of a channel runs at a time but multiple bookmarks can point to the same channel. For example, if you select a bookmark for a Register channel that displays a Savings account, you can also add a different bookmark that points to the same channel but displays the Checking account instead. The tuner makes the single running Register channel visible, but the bookmark forces the channel to display Checking rather than the Savings.
This service automatically displays the channel menu that is used to subscribe or unsubscribe and display channels. It is not used by channel developers except for customization.
This service is intended as a wrapper for objects that do not want to implement the IService interface. It is used primarily as an interface between a channel and its TriggerTable that gives the channel a way to expose objects within the channel to the TriggerTable.
The history channel maintains a running list of the channels and locations that have been visited during the current session so that you can go back to any specific location. It displays a list of channels that is updated each time you navigate to a new (bookmarkable) area within a channel. (If the area is not bookmarkable, it is not included in the history.)
To do this, the history channel registers as a listener to TunerEventObjects and copies the Bookmark object when notified. This bookmark is displayed in the scrolling list so that you can go back to places that were previously displayed.
The primary tool for user authentication is the IKeyManagerService interface. User authentication is a client-side service for channel developers, and authentication requirements vary according to the type of channel you are developing. Some channels require more security than others. During channel development, you define authentication requirements separately on a per channel basis using the KeyManager class. KeyManager exposes the API and is used to define authentication requirements.
By design, IntelliPortal channels are not assigned an individual top-level window. Instead all channels share a window that is used for all IntelliPortal content. IntelliPortal channels can be displayed anywhere within this window (the client shell) as assigned by a channel developer using ILayoutService. This service interface lets IntelliPortal developers decide where channels should be placed. Channels can request a specific location or can use the default location. They are placed in certain content areas based on settings in their properties.txt file. Channels can also request changes to their content area size so that they can go fullscreen if requested.
This service is used to log messages to the console or a text file during channel development. The messages can be traces, exceptions, debugging, or any other type of system message generated during channel development.
This service is used to get and commit an IRequestBuffer interface to construct a buffer that is sent to the transmitter plugin as part of an update. It is designed for requesting specific items for updating such as stock ticker symbols.
The ticker channel is a scrolling text widget that displays text, stock quotes, messages, etc., generally at the bottom of the client shell. Channels can add (or remove) ticker items via the ITickerService. Messages can be permanent or transient. Permanent messages are marked for persistent storage in the ticker channel data directory and remain there until explicitly removed. Transient messages are not stored in the data directory; they are discarded when the channel stops.
The trigger mechanism simplifies communication between channels and tuners. This is accomplished by a set of classes that construct and publish TunerEvent objects based on data included with the trigger, or on data that is dynamically read from the channel at runtime. Triggers also let HTML channels take advantage of tuner functionality (e.g. hyperlinking to a new channel) without having to write additional code. The basic component in the Trigger mechanism is the TriggerItem class which can construct and publish a TunerEvent.
The Trigger class is a collection of TriggerItem objects that are "pulled" together. A trigger is identified by a unique key that serves as reference to its location in the TriggerTable. As a channel developer, you decide what identifiers to use as keys. In HTML channels, you can use the URLs for HTML pages so that the browser checks the TriggerTable every time a new URL is loaded. Each channel has one TriggerTable which is simply a collection of triggers for that channel. If you use the default triggers, no additional coding is required. See the Trigger Editor for a description of how and when to define triggers.
The usage tracking system provides the ability for any client channel to record arbitrary or defined events and send that information to the Ad Manager for processing and profiling use. When the system is in use (either on- or offline), the IntelliPortal client captures and records channel usage. It transmits this data to the server which parses and routes the information to a specified targeting engine. The engine can then respond with personalized ad content that the server returns to the client application.
Usage tracking uses the IUsageTrackingService interface. There are two pieces to the client side. One is listening for events and passing them to the server, the other is the creation of the event.
This service tracks what version of the channel was loaded the last time the channel ran. As part of the update process, a channel overwrites any previously installed version of itself at startup. The version registry tracks what version of the channel ran the last time so it can act accordingly. It can be the same version, no version (e.g. a new channel running for the first time), or a new version.
The IntelliPortal Java packages below show the major classes and interfaces that are available for use by channel developers. See the appropriate javadoc for more information.
| Package | Description |
|---|---|
com.mecasw.awt | |
| MessageRenderer | |
| com.mecasw.eb.adapters | |
| AdapterContextConstants | An Interface to get various information about the desired data the implementer wants in his passed context. |
| IAdapter | The interface which allows legacy and other data access to the IntelliPortal Server. Implementers of this interface can make their information available for the server to manage and distribute. |
| IAdapterContext | An interface which should be implemented to pass Adapter Context information to classes. |
| IAdapterContextInfo | An Interface to get various information about the desired data the implementer wants in his passed IAdapterContext. |
| IEventDataProcessor | An interface used to talk to the UsageTrackingAdapter. An implementing class can retrieve from the UT Adapter a userID associated with event data and the event data itself in the form of either an array of Hashtables or an XML string. |
| IFinancialContext | The provider of financial services, utilities, data and context properties for financial components. |
| IFinancialHost | The host specific component for financial outgoing and incoming data. |
| IUsageTrackingProcessor | Provides methods to receive a reference to the UsageTrackingAdapter (through the IEventDataProcessor interface) and process the event data. |
| AdapterContext | Adapter context class. The context class is used to pass any extra data parameters, environment information, etc. to the IAdapter implementation before calling IAdapter.process(). |
| AdapterContextDataInfo | Contains Information about the name and type of data that resides in an AdapterContext. This is used by implementers of IAdapterContextInfo to return information about the data to be placed into the context. |
| ByteArrayTestAdapter | Returns a buffer of a determined size for end-to-end testing. The buffer will have nothing of significance in it. |
| DataBundle | This is a convenience class to enable the return of multiple 'chunks' of data from a single call to an adapter. |
| EnrollmentAdapter | This is a convenience class to enable the return of multiple 'chunks' of data from a single call to an adapter. |
| EnrollmentData | This is the individual data holder class. It contains all the data required for enrollment. |
| FileReaderAdapter | This adapter will read a file or a directory of files and pass them back in a DataBundle object. |
| FinancialAdapter | This provides the implementation of IAdapter and IFinancialContext providing a generic class which is part of a mechanism for sending financial requests and getting financial responses from outside the IntelliPortal server. |
| FinancialHost | The host specific component for financial outgoing and incoming data using HTTP and OFX. |
| URLAdapter | Open and read the contents of a URL (file or CGI program). |
| UsageTrackingAdapter | UsageTrackingAdapter receives event data from Datafeed and holds it until it's needed by the UsageTrackingProcessor object. |
| UsageTrackingProcessorDb | |
| WebCrawlerAdapter | This class implements an adapter interface that given a web site to retrieve, will add the references and images to a DataBundle object that is returned to the caller. |
| AdapterException | Exception class for classes implementing IAdapter. |
| com.mecasw.eb.alerts | |
| AlertObject | This class represents an IntelliPortal alert. Alerts represent actions the user should be aware of and are actionable; the action taken will correspond to the publish() method of the contained TunerEventProducer. Alerts have several properties which affect how they are shown to the user. |
| com.mecasw.eb.bookmarks | |
| IBookmarkable | Interface which channels should implement if they want to take advantage of the trigger's auto-bookmarking feature. May also be of some use to classes other than the Trigger classes. |
| IRestoreBookmark | Interface which channels should implement if they want a method notification of bookmarks. |
| Bookmark | The Bookmark object is an encapsulation of a stored IntelliPortal location. |
| RestoreBookMarkListener | This is a helper class used by MecaBaseChannel (and potentially any other channel that doesn't extend MecaBaseChannel but wants to be able to restore bookmarks). It listens for the GOTO tuner event messages and calls back to restoreBookmark (of IRestoreBookmark) when a GOTO is received for this channel. |
| com.mecasw.eb.channels | |
| MecaBaseChannel | The base class for all channels that wish to play within the MECA IntelliPortal Client. You do not need to use this class to be a channel, but it certainly does make things easier by providing all the hooks you would need to run the channel. Within this class are housed a variety of individual pieces of functionality that is available to any channel that plays inside the IntelliPortal client. Channel developers who wish to quickly add a channel into the client will undoubtedly use this class as it encompasses all necessary hooks, bells, and whistles of a channel. |
| com.meca.eb.datafeed | |
| DataFeedException | Exception thrown by the Profile Package. This Exception handler takes an integer constant as an initializer which will set the appropriate message. It also contains a pointer to Exception which may contain other exceptions that the user may wish to examine. |
| com.mecasw.eb.intf | |
| IKeyHolder | |
| IMecaApplication | The IMecaApplication interface for the MecaTuner. A class which implements this interface can act as an application in the context of the IntelliPortal tuner. |
| IMecaApplicationContext | An interface that allows channels to access services that are provided by the platform client. |
| IRequestBuffer | |
| IUpdates | |
| com.mecasw.eb.services | |
| IAlertService | Provides channel developers a means for alerting the user to some situation which requires their attention. The data for an alert is encapsulated in an AlertObject. An alert appears in the tuner as an entry in the scrolling ticker which appears at the bottom of the screen. |
| IBBusyService | A simple service to set and release the "wait" cursor. It encapsulates all the necessary logic to cause the application to switch the cursor into either a working in background cursor (cursor with hourglass) or a busy cursor (hourglass only). |
| IBookmarkService | The bookmark service enables the user to add/remove bookmarks to or from the bookmark channel. |
| IChannelSelectorService | Extends IService. |
| IGenericService | Serves as a wrapper for objects which do not want to implement the IService interface. This interface is primarily used as an interface between a channel and its TriggerTable in order to provide the channel with a means to expose objects within the channel to the TriggerTable inside of the Service API. |
| IHistoryService | Extends IService. |
| IKeyManagerService | Extends IService. |
| ILayoutService | Provides an interface to the layout of the MecaTuner client frame. |
| IRequestBufferService | |
| IServiceConstants | |
| ITickerService | Represents the channel developer's interface with the ticker. |
| ITunerEventService | |
| IUsageTrackingService | Interface for channels to log usage events. |
| IVersionRegistryService | The single point version information class. |
| com.mecasw.eb.system | |
| TunerCallbackListener | Intended for use by those who wish to receive asynchronous responses to their published TunerEvents. tunerCallback( Vector ) will be called after all events have been delivered, and all responses from those deliveries have been stored into a Vector. |
| TunerEventConstants | All the necessary constants for TunerEvents. |
| TunerEventListener | |
| TunerEventProducer | Classes should implement this interface if they want to provide TunerEvents for the Trigger mechanism. The TriggerItem class maintains a reference to a TunerEventProducer object which it uses to construct and publish a TunerEvent when it gets pulled. |
| ChannelItem | Encapsulates basic information about a channel and has the necessary methods to start, stop, subscribe, and unsubscribe. |
| TunerEvent | The TunerEvent is the object passed in all Tuner messages. |
| com.meca.eb.triggers | |
| ICleanable | |
| ITriggerCleaner | Classes that implement this interface provide the necessary information to clean Triggers and TriggerItems. This is necessary because a channel developer who is creating Triggers/TriggerItems that need to load resources can't possibly know ahead of time where the resources are going to be. |
| TriggerTableListener | |
| Trigger | A Trigger is an event that causes one or more changes (including starting and stopping) to occur in a target channel. The act of affecting this change is called "pulling the trigger". Channels can use this trigger mechanism as a convenient way to cause changes in other channels (or themselves) based on a set of criteria that the channel developer establishes and manages. |
| TriggerItem | A TriggerItem is class whose purpose is to perform some type of action when it is "pulled" by calling its pull() method. The exact nature of this action depends upon the value of the type field and the value of the delegate field. |
| TriggerTable | Channel interface to Trigger mechanism. Channels will have an instance of this class to store all of its trigger data. |
| TriggerException | A single Exception class for the Trigger mechanism |
| com.mecasw.eb.tuner | |
| VersionRegistryException | Exception class for VersionRegistry. |
| com.mecasw.eb.util.server | |
| IUserPermanentStorage | This is the class that provides access to the BankUser and EBranchUser Permanent data. |
| IUserTransientStorage | An interface to a holding facility for a given users temporary data. |
| DBUserTransientStorage | An implementation of UserTransientStorage that uses a database. |
| LocalConnectionPool | Pooler for Local Connections. Designed to have one instance per VM. This currently has a pool size of 15 and can be overridden in PoolSize.txt. This pool does not use the thread pre-filler. |
| SharedConnectionPool | Pooler for Shared Connections. Designed to have one instance per VM. This currently has a pool size of 15 and can be overridden in PoolSize.txt. This pool does not use the thread pre-filler. |
| UserStorageFactory | A factory to get instances of UserStorage classes. |
| UserStorageException | Exceptions for all UserStorage access classes. |
| com.mecasw.financials.ofx | |
| OfxConstants | This contains all the constants for OFX. It should be implemented by OFX classes. |
| AccountInfoRequest | This is the Account Information request class. It is used for both parsing and creating the Account Information Request information between <ACCTINFORQ> and </ACCTINFORQ>. It should be used to request a list of all the available accounts. |
| AccountInfoResponse | This is the Account Information response class. It is used for both parsing and creating the Account Information Response between <ACCTINFORS> and </ACCTINFORS>. It contains a list of all the available accounts. |
| AccountInfoTransactionRequest | Account Information request class. It is used for both parsing and creating the Account Information Request information between <ACCTINFORQ> and </ACCTINFORQ>. It should be used to request a list of all the available accounts. |
| AccountInfoTransactionResponse | Account Information response class. It is used for both parsing and creating the Account Information Response between <ACCTINFORS> and </ACCTINFORS>. It contains a list of all the available accounts. |
| AccountInformation |
Ofx Account Information bean. This is used for both parsing and creating the Account Information between tokens <ACCTINFO> and </ACCTINFO> |
| BankAccountInformation | Ofx Bank Account Information bean. This is used for both parsing and creating the Account Information between tokens <BANKACCTINFO> and </BANKACCTINFO>. |
| BankAcctBase | The Ofx Account bean. This is used for both parsing and creating the BankAcctBase information. |
| BankAcctFrom | Bank Account From class. |
| BankAcctTo | Bank Account To class. |
| CCAcctBase | Superclass for all classes using OFX protocol. |
| CCAcctFrom | Credit Card Account From class. |
| CCAcctTo | Credit Card Account To class. |
| CreditCardAccountInformation | This is the Ofx Credit Card Account Information bean. This is used for both parsing and creating the Account Information between tokens <CCACCTINFO> and </CCACCTINFO>. |
| CreditCardStatementDownload Request | This is the Credit Card StatementDownload request class. This is used for both parsing and creating the StatementDownload Request information between <CCSTMTTRNRQ;> and </CCSTMTTRNRQ;>. |
| CreditCardStatementDownload Response |
This is the CreditCardStatementDownload Response bean. This is used for both parsing and creating the StatementDownload
Response information between tokens <CCSTMTTRNRS> and </CCSTMTTRNRS>. |
| FinancialInstitution | This is the Ofx Transaction bean. This is used for both parsing and creating the StatementDownload Response information between tokens <<STMTTRN> and </<STMTTRN>. |
| OfxBase | Superclass for all classes using OFX protocol. |
| OfxInstanceMgr | Used to manage and get new instances of OfxBase derived classes. |
| OfxParser | The Parser for OFX streams of data. It walks along the String passed in the constructor. |
| OfxRequest | The highest level OFX request bean. Any new additional OFX functionality will likely require a change here. |
| OfxRequestBeanInfo | |
| OfxResponse | The highest level OFX response bean. Any new additional OFX functionality will likely require a change here. |
| Payee | This is the Ofx Payee bean. This is used for both parsing and creating the Payee information. |
| SignOnRequest |
This is the SignOn request class. This is used for both parsing and creating the SignOn Request information between <SONRQ> and </SONRQ>. |
| SignOnResponse |
The SignOn Response class. This is used for both parsing and creating the SignOn Response information between tokens </SONRS> and </SONRS>. |
| StatementDownloadRequest | The StatementDownload request class. This is used for both parsing and creating the StatementDownload Request information between <STMTTRNRQ> and </STMTTRNRQ>. |
| StatementDownloadResponse | The StatementDownload Response bean. This is used for both parsing and creating the StatementDownload Response information between tokens <STMTTRNRS> and </STMTTRNRS>. |
| StatementTransaction | This is the Ofx Transaction bean. This is used for both parsing and creating the StatementDownload Response information between tokens <<STMTTRN> and </<STMTTRN>. |
| Status | |
| com.mecasw.intf | |
| ILogService | |
| IService | Marks the implementing class as IService and requires them to return a String which represents the version number of the service. It is anticipated that developers will extend this interface to provide their own interfaces to the service that they are providing. |
| IServiceProvider | Exposes Services to objects by mapping an IService interface to an object which implements the IService. It is assumed that the users of the service will have direct knowledge of the interface. |
| com.mecasw.msf | |
| MsfColumn | The MsfColumn class is used to define all columns contained by an MsfDataset. One MsfColumn is defined for every column returned by the SQL query used by the dataset. |
| MsfCriteria | The MsfCriteria object is used for passing extra information the MsfMessage uses to create the MsfDataSet. The MsfCriteria object can contain a Parameter Row to be used to pass data to a parameterized query. |
| MsfDataSet | The MsfDataSet class is the primary interface to all data in the MECA Storage Facility. In simple terms it is a representation of a JDBC Result Set, based on a SQL query. |
| MsfDataSetContainer | The primary purpose of a MsfDataSetContainer is to provide a common mechanism to retrieve data from the MECA Storage Facility. |
| MsfMessage | The MsfMessage object is used to make a request to the MsfStorageFacilityManager. It has attributes that can be set on the MsfMessage to tell the MsfStorageFacilityManager what it needs. |
| MsfParameterRow | The MsfParameterRow object is used for passing parameters to the query contained in the MsfDataSet. The query would have to have been set up with parameters when it was defined. |
| MsfServiceNotification | The MsfServiceNotification class is the returned from the MsfStorageFacilityManager in response to a request. These include requests for data, returned in an MsfDataSet, a commit of data, and a rollback of the database if necessary. |
| MsfStorageFacilityManager | The MsfStorageFacilityManager is the runtime interface to the MECA Storage Facility. The channel will request and receive all data via methods provided in the MsfStorageFacilityManager. |
| MsfVariant | The MsfVariant class is a storage class whose value can be one of many data types. It is like a smart object. |
| com.mecasw.security | |
| IKeyEditListener | Defines the callback method which is called by the KeyManager when a key edit session started by a call to KeyManager editKey() is completed. |
| KeyHolder | Contains and operates on the KeyData object for a key. The KeyHolder is not serialized, but offers methods for manipulating a KeyData object, which object is serialized for storing key attributes and token data. |
| KeyManager | The class that exposes the external Key API. KeyManager is a channel that acts in both a user interface and internal mode. |
| KeyHolderException | Exception class for KeyHolder. |
| KeyManagerException | Exception class for KeyManager. |
| KeyRingException | Exception class for KeyRing. |
| com.mecasw.util | |
| HttpConstants | This interface defines the various constants required to establish an HTTP connection. |
| CallTrace | Provides a mechanism for tracing execution threads. Each CallTrace object is identified by a unique string, it's name. No methods in CallTrace throw exceptions. |
| DbResultFieldHolder | This is used as a convenient way to hold fields and provides a layer hiding some of the differences in SQLs. |
| DbUtils | These are utilities to aid in the use of JDBC. |
| HtmlParser | This is a utility class that facilitates the parsing of HTML pages. Methods are supplied to localize the HTML page and obtain references to images and link references that are members of the page. |
| HttpConnection | This class can be used to establish an HTTP connection. |
| MECAUtil | A collection of static utility functions. |
| ObjectPool | Object pooling class for pooling frequently used Objects. Its function is to provide a significant performance boost over instantiating objects with new(). |
| MECAException | |
| com.mecasw.util.assert | |
| Assert | Assertion mechanism for Java. An attempt to give to Java a basic assertion capability. This version sets the static final boolean to true, enabling the Assertion methods. By setting the booleans to false and compiling using the -o switch of the JAVAC compiler, the bodies of the various assertion methods will be compiled out for a run-time release. |
| AssertException | An AssertException is thrown when a program bug is detected by the Assert class. AssertException is derived from RuntimeException so that it does not have to be declared in the throws clause of every method that directly or indirectly calls it. |
