Server Glossary

Bean Managed Transactions An Enterprise Java Bean that demarcates its own transaction boundaries is said to exercise bean-managed transaction control. (The alternative is Container-managed transactions.) The bean-managed model allows the programmer to exert low-level control over transaction logic, but at the expense of extra code and program complexity.

Connection Pool A group of database connections that can be shared among processes, under the control of a management process (typically the application server). Since opening and closing database connections can becostly from a performance standpoint, it makes sense for a server to cache connections.

Container-Managed Transactions Also known as declarative transaction control, the Container-managed transaction model shifts transaction management responsibilities out of the EJB and into its Container. EJBs that use this transaction model need not be "transaction aware" at the internal code level. Instead, the bean's transaction attributes can be set in a descriptor, and the Container will ensure that appropriate control is exercised over transactions in which the bean may play a part. The Container-managed model can greatly reduce code complexity while increasing reliability.

Deployment Context The deployment context is a name string (whose elements are separated by periods) that can be used to prevent namespace collisions between services with like-named components.

JNDI Java Naming and Directory Interface. A standard extension to the Java platform, providing a unified interface to multiple naming and directory schemes that might exist across file systems and server domains.

JTA Java Transactions API. A standard Java interface between the transaction manager and parties involved in a distributed transaction system. Bean-managed transactions rely on this API.

Params (URL/Form) One of the four canonical Composer service trigger types. This Servlet type builds an in-memory XML document using HTTP URI form parameters as the names of nodes and their values as text. Multiple values for a parameter can be handled, but multiple input documents are not created.

Service Triggers A Service Trigger is a Java Servlet or Enterprise Java Bean created when deploying a project from Composer. It submits a Service to exteNd.Server for execution. A Service Trigger is also associated with an URI and converts inbound data into XML documents as input to the service it triggers.

SOAP (Simple Object Access Protocol) A platform-independent protocol for remote invocation of objects using HTTP as the transport layer and XML to represent the payload.

XML (HTML form field) One of the four canonical Composer service trigger types. This Servlet type extracts a service's input document from a POSTed form's field. The Servlet expects the field name containing the XML file to be called `xmlfile' and it uses the first occurrence of this parameter for the extraction.

XML (HTTP POST) One of the four canonical Composer service trigger types. This type of trigger Servlet extracts an XML document sent via an HTTP POST method. This differs from HTML Form POSTs that contain parameter name | value pairs. The payload of this kind of HTTP transmission is, in fact, the raw XML document. It is a convenient method for exchanging XML documents with trading partners.

XML Metadata All exteNd objects created in Composer are themselves stored as XML files. The object data and processing instructions in these files are referred to as XML metadata. The exteNd runtime engine processes this metadata to perform XML Integration services.

XML (MIME multipart) Another of the four canonical Composer service trigger types. This Servlet type extracts a service's input document from a multipart encoded form containing a field with an input type of file. The Servlet expects the field name containing the XML file to be called `xmlfile' and it uses the first occurrence of this parameter for the extraction.