Glossary | Software Fortresses: Modeling Enterprise Architectures

access control list ( ACL ): An operating system facility for defining which users are allowed to access which system resources.

ACL: See [access control list]

ActiveEnterprise: TIBCO's technology for treaty management fortresses .

Active Server Pages ( ASP ): Microsoft's pre-.NET programming technology for the presentation fortress, now replaced by ASP.NET.

ally: A fortress that works with another fortress to fulfill a common objective.

ASP: See [Active Server Pages]

ASP.NET: Microsoft's .NET programming technology for the presentation fortress.

assembly: In .NET terminology, a deployable unit of code.

asynchronous component: A component that uses an asynchronous communications protocol, such as message queues, for transmitting information. In the J2EE space, these components are called message-driven beans . In the .NET space, these components are called queued components .

asynchronous drawbridge: A drawbridge that makes no promises about when it will deliver its infograms or the order in which it will deliver its infograms, and that returns no information to the sender once those infograms have been delivered. Compare synchronous drawbridge .

auditing: The guard function of logging infograms.

authentication: The guard function of verifying the source of an infogram .

authenticator: A trusted party that can be used to verify the identity of other, nontrusted parties.

authorization: The process for deciding whether or not a fortress is authorized to do what it is trying to do.

automatic transaction boundary management: A feature of component-oriented middleware (COMWare) by which the system automatically determines transaction boundaries.

autosecurity: The ability of a system to provide some security features administratively rather than through code.

availability: See [true reliability]

BAF: See [business application fortress]

BizTalk Server: Microsoft's product that is the basis for .NET's equivalent of the treaty management fortress.

broadcast: To send information from one source to many other places.

broadcast service fortress: A service fortress that receives information from one fortress (the publisher) and broadcasts it to a number of other fortresses (the subscribers).

browser client: A human being working at a browser. Also called thin client .

BTP: See [Business Transaction Protocol]

buffer overflow: An attack on an Internet fortress in which a hacker tries to send more data into the infogram than the fortress can handle, thereby overriding memory in the fortress. If successful, the hacker can gain control of the trusted processes within the fortress.

build-big: An approach to scalability that attempts to predict the eventual workload of a system and build it on a system large enough to handle that workload from the beginning. Compare scale-up and scale-out .

business application fortress ( BAF ): A fortress that processes a major piece of business functionality, such as a human resource system.

business transaction: In BTP terminology, a loosely coupled transaction that spans Web services.

Business Transaction Protocol ( BTP ): The standard proposed by OASIS for coordinating loosely coupled transactions across Web services.

C#: A .NET programming language that closely resembles Java. Pronounced "cee sharp."

cancel: A request to terminate and undo a transaction (usually loosely coupled) that has been started but not yet committed.

CERT/Coordination Center: Formally known as the Computer Emergency Response Team Coordination Center, one of the main organizations that tracks and reports on Internet-based attacks on enterprise systems. The Web site is www.cert.org.

certificate: A document that can be used to prove a party's identity.

CICS: Customer Information Control System, an early transaction processing monitor from IBM that is still widely used in large enterprise systems.

class: One of possibly many object-oriented implementations of an interface.

class “responsibility “collaborator ( CRC ) cards: A design technique that was first described at an OOPSLA conference by Ward Cunningham and Kent Beck in 1989 and became popularized most notably by Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener in their book Designing Object-Oriented Software (1990, Prentice-Hall). FAR cards are based on CRC cards.

client: One who requests a service from another.

client process: The process in which the client, or caller, resides. Compare component process .

client “server architecture: A software architecture that recognizes only two tiers: one for the combined client/business logic and one for the database.

client surrogate: A bit of software that stands in for a client in the component process in a component system. Compare component surrogate .

CLR: See [Common Language Runtime]

cluster: A collection of similarly configured computers designed so that any given work request can be sent to and successfully processed by any one of them.

cluster controller: The process, machine, or other entity of the cluster that decides which machine in the cluster will process the next request.

COM+: Microsoft's infrastructure for the business application fortress. COM+ predates .NET but is still considered part of .NET.

Common Language Runtime ( CLR ): The runtime infrastructure used by the .NET programming languages. Compare Java Virtual Machine .

Common Object Request Broker Architecture ( CORBA ): An early distributed-component architecture.

complex treaty: A treaty that requires the coordination of a treaty management fortress. Compare simple treaty .

component: The smallest unit of packaging and distribution in component-based systems. Component packaging is one of the techniques we use to package compiled code, identify remotely accessible interfaces to that code, and assign processes in which that code will run. In Java, a component is typically an Enterprise JavaBean. In .NET, it is typically a COM+ component. Compare object .

component instance: A discrete blob of memory that serves the role of a component and can process requests from a remote client.

component interface: A collection of method definitions that a component supports.

component-oriented middleware ( COMWare ): The technologies represented by EJB and COM+. These technologies were originally intended to be middle - tier infrastructures for components (hence their name ). They are now used as the infrastructure for business application fortresses.

component process: The process in which one or more instances of one or more components lives.; See also [client process]

component state: The data needed by a component to fulfill a request.

component surrogate: A bit of software that stands in for a component instance in the client process in a component system. Compare client surrogate .

COMWare: See [component-oriented middleware]

confirm: In BTP terminology, the process of letting the coordinator know that the end boundary of the transaction has been reached and that the coordinator should start working with the participants to reach the final transactional end game.

connector: The part of an application designed to plug into a treaty management product, such as BizTalk Server.

consensus: The third phase of the four-phase commit protocol, which is entered when the transaction initiator informs the coordinator that the end transactional boundary has been reached. In this phase, the coordinator asks the participants how each one feels about its portion of the transactional workload.

context: In BTP terminology, information that uniquely identifies a specific business transaction.

coordinator: In BTP terminology, the entity that is coordinating the loosely coupled transaction, analogous to DTC for a tightly coupled transaction.

CORBA: See [Common Object Request Broker Architecture]

CRC cards: See [class “responsibility “collaborator cards]

create: In the context of a loosely coupled transaction, the request to the transaction coordinator to begin a new transaction and allocate a region of memory to store information about that transaction.

CTO: Chief technical officer, the highest position in an IT organization.

database: A technology specialized for managing data and processing update requests to that data within the context of a tightly coupled transaction.

database connection: A logical connection between a database client (typically a process within a fortress) and the database itself.

database locks: A technique in which users are temporarily denied access to specific data. This technique is used by databases to coordinate the conflicting data access requirements of different database users.

data-sharing fortress: A service fortress that serves as a shared data repository for two or more other fortresses.

data strongbox: Conceptually, the private data storage facilities used by a fortress. A data strongbox can be implemented, for example, with a dedicated database, a logical partition of a database, or a file system.

data tier: The back end of a three-tier architecture. This is the tier in which the database resides.

DCOM: See [Distributed Component Object Model]

decryption: The process of converting data that had been algorithmically altered to appear garbled back to its original form. Compare encryption .

Distributed Component Object Model ( DCOM ): One of the component protocols used by .NET.

distributed transaction coordinator ( DTC ): A system that coordinates two or more transactional resources in a tightly coupled multiple-resource transaction.

donor fortress: The fortress that is making a request of another fortress. Compare recipient fortress .

drawbridge: Conceptually, a communications channel that a fortress uses to receive work requests (infograms). A drawbridge can be implemented, for example, with a message queue or a shared logical data partition.

DTC: See [distributed transaction coordinator]

EJB: See [Enterprise JavaBeans]

emissary code: In Pat Helland's software fiefdom model, code that runs on the browser to prepare requests for a software fortress.

encryption: The process of algorithmically altering data to appear garbled. Compare decryption .

enroll: The process by which a participant in a transaction (either loosely coupled or tightly coupled) informs the coordinator of its intention to participate in the transaction.

Enterprise JavaBeans ( EJB ): The J2EE specification that defines an infrastructure for the business application fortress.

enterprise system: A collection of software fortresses that collectively run a large enterprise.

envoy: A specialized system within a fortress that creates infograms and sends them to other fortresses via drawbridges .

Extensible Markup Language ( XML ): A standard string-encoding mechanism designed specifically for data.

FAD: See [fortress “ally “diagram]

FAR (fortress “ally “responsibility) card: An adaptation of a CRC card that tells us three things about a fortress: its name and type, its responsibilities, and the allies with which it must collaborate to fulfill its responsibilities. Compare TAR card .

File Transfer Protocol ( FTP ): A protocol used to transfer files between machines.

final: The fourth phase of the four-phase commit protocol, which is entered when the last transactional participant lets the transactional coordinator know its opinion on the transaction outcome. In this phase, the coordinator informs each of the participants of the transaction as to what the transaction result should be.

firewall: A combination of hardware and software systems designed to prevent unauthorized entry into a private network.

FOD: See [fortress overview document]

fortification: The wall function of preventing access to a fortress other than through approved channels (drawbridges).

fortress: See [software fortress]

fortress “ally diagram ( FAD ): A diagram showing the enterprise fortresses and the ally relationships between them.

fortress “ally “responsibility card: See [FAR card]

fortress overview document ( FOD ): A detailed description of a specific fortress, including any information that a fortress outsider might need to know, such as information about the drawbridges, the high-level algorithms the fortress implements, and the technologies used inside the fortress.

fortress-specific icon: A cartoon figure used in diagrams to represent the type of a fortress.

four-phase commit protocol: The protocol that is used by most transaction coordinators for either loosely or tightly coupled transactions. The four phases are sleep, meditative, consensus, and final.

FTP: See [File Transfer Protocol]

golden rule of components: The rule stating that business component methods should be designed to be self-contained tightly coupled transactions.

guard: A specialized system within a fortress that receives requests from a drawbridge and subjects them to a security inspection. Compare wall .

heterogeneous: Describing two or more dissimilar systems. The term usually refers to the technology base on which the systems are built. For example, a pair of two systems ”one built on .NET and the other built on WebSphere ”would be considered a heterogeneous pair. Compare homogeneous .

heterogeneous drawbridge: A drawbridge connecting a pair of heterogeneous fortresses. Compare homogeneous drawbridge .

homogeneous: Describing two or more similar systems. The term usually refers to the technology base on which the systems are built. For example, a pair of two systems, both built on .NET would be considered a homogeneous pair. Compare heterogeneous .

homogeneous drawbridge: A drawbridge connecting a pair of homogeneous fortresses. Compare heterogeneous drawbridge .

HTML: See [HyperText Markup Language]

HTTP: See [HyperText Transfer Protocol]

HyperText Markup Language ( HTML ): The standard definition of documents returned to browsers from presentation fortresses.

HyperText Transfer Protocol ( HTTP ): One of the common protocols used for the transferral of information between browsers and presentation fortresses.

idempotent: In Pat Helland's software fiefdom model, describing a request that can be executed any number of times greater than zero with an equivalent result.

IIOP: Internet Inter-ORB Protocol, the CORBA component protocol and precursor to the Java RMI/IIOP component protocol.

IIS: See [Internet Information Server]

infogram: A request that travels between two fortresses via a connecting drawbridge.

Information Technology ( IT ): The part of a large enterprise that owns information processing.

initiator: In BTP terminology, the party starting the transaction and defining the loosely coupled transaction boundaries.

instance management: A feature of component-oriented middleware (COMWare) that shares a single instance of a component among a large number of clients .

integrity: A guarantee by a fortress that it never leaves itself in a damaged or incomplete state. Also the process of guaranteeing that an infogram has not been changed en route through a drawbridge.

interface: A description of what something can do for you, usually used within the context of objects or components.

interfortress: Describing a process that involves more than one fortress. Compare intrafortress .

Internet fortress: A presentation or Web service fortress.

Internet Information Server ( IIS ): The part of the .NET technologies that provides an infrastructure for presentation fortresses and sometimes for Web service fortresses.

Internet Inter-ORB Protocol: See [IIOP]

intrafortress: Describing a process that occurs entirely within one fortress. Compare interfortress .

IT: See [Information Technology]

J2EE (Java 2 Enterprise Edition): A family of specifications, produced by Sun, that define an enterprise architecture and are rooted in the Java programming language.

JAR: See [Java Archive]

Java: The programming language used with J2EE technologies.

Java Archive ( JAR ): In J2EE terminology, a deployable unit of code.

Java bytecode: The low-level language into which Java is translated before it is compiled. Compare Microsoft Intermediate Language .

JavaServer Pages ( JSP ): Sun's main specification for programming presentation fortresses.

Java Virtual Machine ( JVM ): The runtime infrastructure used by the Java language. Compare Common Language Runtime .

JSP: See [JavaServer Pages]

JVM: See [Java Virtual Machine]

Kerberos: A shared-key authentication system.

LCTM: See [loosely coupled transaction management service fortress]

legacy fortress ( LF ): A fortress that wraps an existing legacy system that was originally developed without regard to the software fortress model.

LF: See [legacy fortress]

linked library: A collection of compiled code that is linked into an executable.

loosely coupled cluster: A cluster of machines, usually a large number, that are organized such that if one machine goes down, its work in progress is lost, but new work can be picked up by another machine in the cluster. Compare tightly coupled cluster .

loosely coupled transaction: A coordination of two or more activities that allows each activity to learn of the failure or success of the others, and to take appropriate remedial action upon failure. Compare tightly coupled transaction .

loosely coupled transaction management ( LCTM ) service fortress: A service fortress that is responsible for coordinating loosely coupled transactions that span fortresses.

meditative: The second phase of the four-phase commit protocol, which is entered when the transaction initiator informs the coordinator that a new transaction boundary has been reached and the coordinator has assigned a transaction ID. In this phase, the coordinator is waiting for transactionally aware resources to check in.

message-driven bean: See [asynchronous component]

message queue: A communications technology that is the basis for asynchronous drawbridges today.

method: Usually used within the context of objects or components, a specific request that something can do for you.

method invocation: A request to a component instance to perform a service on behalf of a specific client.

Microsoft Intermediate Language ( MSIL ): The low-level language into which all .NET-supported languages are translated before they are compiled. Compare Java bytecode .

middle tier: One of the tiers in a three-tier architecture. The middle tier is typically responsible for tightly coupled transaction processing.

MQ Integrator: IBM's technology for treaty management fortresses, considered part of its WebSphere product line.

MQSeries: IBM's message queue product.

MSIL: See [Microsoft Intermediate Language]

MSMQ: Microsoft's message queue product.

multiple-resource transaction: A transaction that must be coordinated over two or more transactional resources, such as databases.

.NET: Microsoft's term for its enterprise technologies.

.NET language: A language that can be used for programming within .NET. Most languages (the notable exception is Java) are .NET languages.

.NET Remote Binary Protocol: One of the component communications protocols supported by .NET.

nonblocking: Describing a workload that can be accomplished without blocking the one requesting the work. In the software fortress model, the term is usually used in reference to asynchronous drawbridges.

nonrepudiation: A process for proving that a particular fortress made a particular request, especially when the fortress denies having done so.

nontransactional queue: A message queue that does not support transactional protection and will not participate with transactional resources in a multiple-resource transaction.

N-tier architecture: A three-tier architecture in which the middle tier is subdivided into smaller business systems.

OASIS: See [Organization for the Advancement of Structured Information Standards]

object: An artifact of object-oriented programming, which is one (not the only) technique we can use to implement algorithms. An object is therefore a unit of implementation. In Java, an object is an instantiation of a Java class. In .NET, an object is an instantiation of a class defined in one of the .NET languages, such as C#. Compare component .

ObjectWatch Newsletter: The official newsletter of the software fortress movement, available at www.objectwatch.com.

Oracle: Oracle corporation's main database (data strongbox) technology.

Organization for the Advancement of Structured Information Standards ( OASIS ): One of several software consortia that are trying to define standards for various aspects of Web services. The Web site is www.oasis- open .org.

partitioned database: A database that is spread out over multiple physical computers.

persistent queue: A message queue that is stored on disk and therefore is not lost in case of system failure. Compare transient queue .

PF: See [presentation fortress]

point of interception: The point at which COMWare technologies intercept a method request traveling between a client and a specific component instance for the purpose of running a variety of COMWare algorithms.

polymorphic method resolution: The ability of an object-oriented or component-oriented system to support multiple implementations of an interface and then choose which of those implementations is appropriate to use at runtime.

poor-man's clustering: The use of asynchronous drawbridges to implement many of the features of clusters.

presentation fortress ( PF ): A fortress that accepts browser requests and prepares to forward them to the corporate empire. The presentation fortress is a browser gateway into the enterprise.

presentation tier: The browser- facing tier in a traditional three-tier architecture. This tier typically handles interactions with the browser. Its function is analogous to that of a presentation fortress.

privacy: The process of protecting infograms en route through a drawbridge from prying eyes.

private key: A secret key, typically used for encryption and decryption, that is shared by a small number of parties (usually two). Compare public key .

proxy: See [surrogate]

pseudoreliability: The condition in which a fortress is not particularly trustworthy but appears to be so, most likely through the use of asynchronous drawbridges. Compare true reliability .

public key: A key that is made publicly available for use in encryption and decryption. Compare private key .

public/private “key authentication: An authentication scheme that is based on public and private keys. Secure Sockets Layer (SSL) is a public/private “key authentication scheme. Compare shared-key authentication .

publisher: The source of a broadcast. Compare subscriber .

queue: The carrier of a message in a message queue system.

queued component: See [asynchronous component]

recipient fortress: The fortress that is receiving a request from another fortress. Compare donor fortress .

reliability: A measure of how much a fortress can be trusted to be available when it is needed.

remote method invocation ( RMI ): Any technology designed to allow component method invocations to be made across process boundaries.

remote procedure call ( RPC ): A precursor technology to distributed components.

rich client: A client system that is built as a stand-alone program.

RMI: See [remote method invocation]

RMI/IIOP: Remote Method Invocation/Internet Inter-ORB Protocol, the standard component protocol that is supposed to be used by all J2EE systems. Pronounced "RMI over IIOP."

role-based security: A type of security used with components in which users are assigned roles (such as managers or tellers) and then access rights to components, interfaces within components, or methods within interfaces are based on those same roles.

RPC: See [remote procedure call]

rule of transactional integrity: The rule dictating how data must move between code that implements business logic and a database. The first part of this two-part rule states that all data used in a transaction must be acquired from the database within that transaction. The second part states that all data that is changed during the transaction must be stored back to the database before the transaction commits.

SAD: See [sequence “ally diagram]

scalability: The ability to increase the processing capability of a fortress, preferably without increasing the overall cost per unit of work.

scale-out: An approach to scalability in which more machines are added to one or more clusters. Compare scale-up and build-big .

scale-up: An approach to scalability in which smaller machines are replaced with larger machines. Compare scale-out and build-big .

Secure Sockets Layer ( SSL ): A public/private “key authentication scheme.

sequence “ally diagram ( SAD ): An adaptation of the UML construct called class sequence diagram. SADs give more detail about how the various fortresses work together while still fitting in a relatively small space. In a SAD, the heading gives the name of the treaty. Within the treaty, each ally fortress is represented by a vertical line. Interactions between the fortresses are shown with one of three arrows, following conventions similar to those of UML's class sequence diagrams. Full solid arrowheads show use of a synchronous drawbridge. Full hollow arrowheads show a synchronous drawbridge returning information. Half solid arrowheads show use of an asynchronous drawbridge. Typically the name of the drawbridge is written underneath the arrow.

service fortress ( SF ): A fortress that packages some common functionality and/or data that must be shared across one or more enterprises .

session key: The data that is used by a presentation fortress to find, in a data strongbox, the larger body of data that represents the state of a specific browser session. Also called session state key .

SF: See [service fortress]

shared-key authentication: An authentication scheme that is based on two parties sharing a common secret, such as a password. Kerberos is a shared-key authentication scheme. Compare public/private “key authentication .

Simple Object Access Protocol ( SOAP ): A standard string representation of a request between heterogeneous systems.

simple treaty: A treaty that does not require the coordination of a treaty management fortress. Compare complex treaty .

single-resource transaction: A transaction that involves only one transactional resource.

sleep: The first phase of the four-phase commit protocol, in which the transaction coordinator is not paying attention to anything you are doing.

SOAP: See [Simple Object Access Protocol]

SOAP surrogate: A component surrogate that uses SOAP to transform a method request into a string.

software fiefdom model: Pat Helland's model for enterprise architectures, in which software systems owned by different enterprises treat each other as autonomous computing units.

software fortress: A conglomerate of software systems that work together in a tight trust relationship to provide consistent and meaningful functionality to a hostile outside world.

software fortress architecture: An enterprise architecture consisting of a series of self-contained, mutually suspicious, marginally cooperating software fortresses interacting with each other through carefully crafted and meticulously managed treaty relationships.

software fortress model: A methodology for designing an enterprise system based on software fortresses.

SQL Server: Microsoft's main database (data strongbox) technology.

SSL: See [Secure Sockets Layer]

state management: The process of managing information that is specific to the donor fortress or requestor of a service.

stored procedure: Programming logic that is stored inside and executed from inside of a database.

strongbox: See [data strongbox]

strong transactional guarantee: A guarantee that is made in a tightly coupled transaction ”namely, that participating transactionally aware resources will all undo their portion of the workload if any other participating transactionally aware resource is unable to complete its portion of the workload and will absolutely guarantee to complete their portion of the workload once they all agree to do so. Compare weak transactional guarantee .

subscriber: One of the places to which a broadcast will be sent. Compare publisher .

surrogate: Something that stands in for something else. Also called proxy .

synchronous drawbridge: A drawbridge that delivers its infogram immediately and does not return control to the envoy until that delivery has occurred. Compare asynchronous drawbridge .

TAD: See [treaty “ally diagram]

TAR (treaty “ally “responsibility) card: A brief overview of a treaty, including which fortresses are part of that treaty and what their responsibilities are within that treaty.

thin client: See [browser client]

three-phase commit protocol: A version of the four-phase commit protocol that does not consider the sleep part of the commit protocol.

three-tier architecture: A traditional architecture that consists of a presentation tier, a middle tier, and a data tier. Compare N-tier architecture .

ticket: A string, typically encrypted, that gives one party permission to do something with another party.

tightly coupled cluster: A cluster of machines, usually a small number, that are organized such that if one machine goes down, its work in progress is not lost but rather is automatically picked up by one of the remaining machines in the cluster. Tightly coupled clusters are usually used to protect the database machine from failures. Compare loosely coupled cluster .

tightly coupled multiple-resource transaction: A tightly coupled transaction in which there are two or more transactional resources and the services of a distributed transaction coordinator are therefore required. Compare tightly coupled single-resource transaction .

tightly coupled single-resource transaction: A tightly coupled transaction in which exactly one transactional resource is involved, and the services of a distributed transaction coordinator are therefore not required. Compare tightly coupled multiple-resource transaction .

tightly coupled transaction: A coordination of updates to one or more transactional resources (such as databases or message queues) such that all resources either complete their updates or none of the resources complete any of their updates. Compare loosely coupled transaction .

TMF: See [treaty management fortress]

TOD: See [treaty overview document]

TPC-C: An industry standard benchmark designed to test high-end database applications.

TPM: See [transaction processing monitor]

transaction: A collection of either requests or updates that should be processed as a group , with all either succeeding or failing.

transactionally aware resource: Something that knows how to accept groups of updates and guarantee that they are done or not done en masse, and how to participate with an outside entity to coordinate its group of updates with groups of updates to other transactionally aware resources. Often called simply transactional resource .

transactional queue: A message queue that can behave as a transactionally aware resource.

transactional resource: See [transactionally aware resource]

transaction boundary: The point at which a transaction either begins or ends.

transaction boundary management: See [automatic transaction boundary management]

transaction flow: The ability of a system to automatically have all of the work in a given workflow be done within the same transaction.

transaction processing monitor ( TPM ): The original approach to building the middle tier in a three-tier system. TPMs were built to provide highly scalable systems built around a rich-client architecture.

transient queue: A message queue that is not stored on disk and therefore is not protected against loss in case of system failure. Compare persistent queue .

treaty: A defined partnership of two or more fortresses.

treaty “ally diagram ( TAD ): A subset of a fortress “ally diagram (FAD) that shows only those fortresses participating in a given treaty.

treaty “ally “responsibility card: See [TAR card]

treaty management fortress ( TMF ): A fortress that is specialized to manage complex treaties .

treaty overview document ( TOD ): A detailed description of a specific treaty, including any information that a participant in the treaty might need to know, such as information about sequences of fortress interactions, security requirements, transactional expectations, and the synchronicity of the drawbridge.

true reliability: The condition in which a fortress is truly up and running when asked to do something. Also called availability . Compare pseudoreliability .

trust rule: A basic rule of fortress design stating that all entities within a fortress trust all other entities within the same fortress, but trust no entities that live outside the fortress.

two-phase commit protocol: A version of the four-phase commit protocol that considers the sleep and meditative phases part of the precommit phase and not part of the commit protocol per se.

UDDI: See [Universal Description, Discovery and Integration]

UML: See [Unified Modeling Language]

Unified Modeling Language ( UML ): An object-oriented design methodology.

Universal Description, Discovery and Integration ( UDDI ): One of the Web service family of standards that is used to find potential partners, usually partners exposing their functionality through SOAP.

validation: The guard function of checking infograms to make sure they don't contain illegal or invalid information.

Visual Studio.NET: Microsoft's programmer tools, used primarily for presentation and business application fortresses.

wall: Conceptually, a part of the fortress that prevents requests from entering the fortress other than through approved channels. A wall could be implemented as a firewall, through role-based security, through database security, or through ACLs. Compare guard .

weak transactional guarantee: A guarantee that is made in a loosely coupled transaction ”namely, that participants will merely let each other know if they are unable to complete their portion of the workload, and let each participant decide what action, if any, to take as a result. Compare strong transactional guarantee .

Web service fortress ( WSF ): A fortress that accepts programmatic requests over the Internet and prepares to forward them to the corporate empire. The Web service fortress is the programmatic gateway into the enterprise.

Web Services Description Language ( WSDL ): A standard string format defining, in minute detail, everything there is to know about a Web service.

Web Services Inspection Language ( WS-Inspection ): A specification for finding WSDL documents and related information on a Web site.

WebLogic: BEA's J2EE-influenced enterprise technologies.

WebSphere: IBM's J2EE-influenced enterprise technologies.

worker: Conceptually, something within the fortress that fulfills part of the overall fortress's responsibility. A worker could be implemented, for example, as a component, a process, or a collection of processes.

workload averaging: The use of asynchronous drawbridges to put off peak workloads until times when the system would normally be used lightly.

WSDL: See [Web Services Description Language]

WSF: See [Web service fortress]

WS-Inspection: See [Web Services Inspection Language]

XML: See [Extensible Markup Language]