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:
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.
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.
Comments