BlackTie Architecture (Page 2)

BlackTie Actors

A standard BlackTie application has several key roles to be carried out by a combination of user developed and framework provided components. Notable amongst these are the following:

BlackTie Clients

Clients can be deployed onto standard desktop (or similar) environments and are typically used to submit data collected from users of an application and to retrieve results based on that data. The client also contains the logic to demarcate transactions and to control the order of execution of invoked XATMI applications. BlackTie clients join the system through an X/Open defined suite of XATMI and TX routines.

BlackTie clients can be written in either a language supporting linking against C libraries, or the Java programming language. In the C case, once a BlackTie client is written, it is then compiled against the xatmi.h and tx.h files (along with any proprietary BlackTie headers and other software that may be chosen by the developer) and then linked against the set of BlackTie and similar required libraries. In the Java case, then the client must be compiled against the Jab or EJB-connector libraries.

Runtime Requirements

Access to gcc, Microsoft Visual C++ or Java run time libraries

File permissions to read BlackTie configuration files

TCP/IP network connection

Is typically running Fedora Core 10 (and above) or Microsoft Windows XP

Moderate memory requirements

BlackTie XATMI Services

An XATMI service typically encapsulates the solutions business rules and is bound into the application through the standard XATMI tpservice(TPSVCINFO*) callback method. It is uniquely named withing a domain and is assisted in performing its ability with the support of the BlackTie XA resource managers extension.

Similarly to the BlackTie client, the service must be compiled and linked against the libraries provided by the BlackTie framework, with the slight exception being for Java where the choice is restricted to the EJB connector library.

Runtime Requirements

Access to gcc or Microsoft Visual C++ run time libraries, or for Java based services JBoss 5 or above

Has a TCP/IP network connection

Is typically running Fedora Core 10 (and above) or Microsoft Windows XP

Moderate memory requirements

Service Lifecycle

Unlike with client software where the user is responsible for maintaining the lifecycle of their application, services are typically deployed into a standard BlackTie server and as such their lifecycle is maintained by the server process itself. The following diagram illustrates the lifecycle of an XATMI service:

4-lifecycle.gif

The states in the above diagram mandated by the XATMI specification are Advertised and Unadvertised, these states being achieved via tpadvertise() and tpunadvertise() calls respectively. Of special note is that the state of being Advertised is also reached (by default) on server start-up as illustrated in the diagram above.

Our additions to the specification provide a pool of service handlers (threads) to allow several concurrent requests to be processed simultaneously. This leads to the additional states of Pooled and Active.

BlackTie Server

A BlackTie server provides the container which manages the lifecycle of the BlackTie services and allows the services to be monitored and controlled from remote administration tooling.

The administrative functions supported by the BlackTie server are as follows:

Advertise Service

Start the identified service

Unadvertise Service

Stop the identified service

List Advertisable Services

List the services that are not

Get Server Information

Retrieve data about the running state

Shutdown

Stop the server

NOTE: These functions are accessed via CORBA invocations

Further to the administration of the actual server lifecycle, there is also the configurable aspects of the server and its services. These are discussed in a later section.

BlackTie Domain

The domain is the container class that collects related services and clients which together compose the solution as defined by the user. It is defined in XML and contains the ports and other identifiers which partition the application from other BlackTie domains. The domain is also the level where the administered application services such as queues, topics, the transaction manager and naming service are defined. It is that combination which becomes the domain and is totally at the discretion of the user as to how to partition their domains.

2-actors.gif

NOTE: The TMS, Naming Service and Queuing software do NOT need to be ran within the JBoss AS container, however this does provide a convenient method for administering and deploying these components.

Administered Services

With BlackTie, we have chosen to use the following administered services:

  • The naming service (NS) is      provided by JacORB

  • The transaction manager (TMS/TM)      is provided by JBoss Transactions

  • The queuing system (Q'ing) is      provided by JBoss Messaging (wrapped by the Stomp library)

Example Physical Deployment Diagram

The below diagram illustrates an example of how BlackTie components may by deployed at a physical level on a users hardware. It is intended to show that the options for deployment are several; from a single machine deployment (lower left hand box), to fully federated deployment options depending upon the number and capacity of the machines available.

3-physical-deployment-DIAGRAM.gif

On to BlackTie Architecture (Page 3)