Access Providers

Access providers are small client-side high-level programming libraries that contain all the functionality and APIs needed for easy access to the business logic. Access providers encapsulate the underlying communications protocol and also handle client-server protocol semantics such as authentication and error handling. When using access providers, the input and output can be either XML documents or any of the other supported object models.

Contents

• IFS and Access Providers
• How it works
• Access Provider Contents

IFS and Access Providers

IFS has chosen to package the access APIs into separately installable access providers so that any application, whether it uses an IFS client framework or not, can have full access to business logic. Although all access providers provide the same functionality the implementation is different for each targeted platform (Java, .NET). The reason for this is to make them as natural as possible to use. For example the Java access provider is written in 100% Java. Similarly native mechanisms for exception handling, object collections etc. are used. If an error occurs in the business logic the Java access provider will throw a Java exception to the application. All of this makes it very easy for a developer to build an application (with or without UI) that uses the application business logic using any of the supported development environments. The developer is only working with objects and technologies that are native to the development environment he knows and understands.

Because all the functionality and APIs required to use the business logic have been separated into access providers, both IFS client applications and other applications can enjoy the same easy way to access the business logic.

How it works

Access providers use a simple request-response metaphor for invoking business logic. The basic principle works like this:

1. The client program creates the request document. This can be either an XML document or a document built using the BOM, ROM or VOM object models (see below)
2. The client program Invokes an Activity or Business API in the business logic, passing the request document along.
3. The access provider handles all required communication with the servers, where the request is processed and a response document is created. The response document will be of the same format as the request document. For example if an XML request document was passed, then the response will also be an XML document.
4. The client application reads the response document and continues execution.

Important to know is that the transaction control happens in it's entirely on the server. Each invocation becomes it's own transaction.

Access Provider Contents

As much as the technical implementation differ between the access providers, they all have a common set of functionality which they provide to the applications. Each access provider includes the following:

• XML parser
  The XML parser is not developed by IFS, but it is an important part of an access provider. The XML parser is used to create XML documents to be passed to a server request. Each access provider uses the standard XML parser for the target platform.
• Buffer Object Model (BOM)
  The buffer object model is a low-level object model to construct request and response documents. It serializes to a binary format rather than a text format like the XML documents. Because of the binary format used, the BOM gives significantly better parsing times and smaller documents than is possible with XML.
• Record Object Model (ROM)
  This is a high level record object model. The basic constructs are records (representing one data entity), record collections (a set of records, or many entities in one lump), and attributes (the individual information attributes of a record). Depending on the target platform the record object model may be built on top of existing data models and api:s on that platform. The ROM uses the same binary serialization format as the BOM.
• View Object Model (VOM)
  The view object model consists of real classes representing the various entities and views used in the business logic. Access providers that support VOM contain functionality to generate class representations of any entity or view in the business logic. This means that the developer will get compile-time rather than run-time checking of record types, attribute names etc. The generated VOM classes internally use the ROM to construct the request and response documents.
• Server
  The server object is the object that handles the communication with the business logic. It encapsulates the underlying protocol and provides additional services (see below). Client applications use the server object to invoke the business logic, passing a request document along. Client can use request documents built using either of the document object models XML, BOM, ROM, or VOM.

In addition to the core components listed above, the access providers also provide other services useful to client applications. These services are:

• Data compression
  Compression of the request/response documents sent and received.
• Server debug trace
  All application servers optionally output a debug trace form the execution. The access provider let's the client enable different categories of debug trace in the server, and to retrieve the complete trace text after a call to the server has been made.
• Statistics
  Keeping track of statistics such as the amount of sent and received data, time used for server invocations, and number of server invocations made.

From a developers point of view an access provider is basically a Software Development Kit (SDK) which allows him/her to build an application which interacts with the business logic. Not all component and services are implemented by all access providers.