Table of Contents
Serena Release Automation architecture consists of a service tier and a data tier. The service tier has a central server
that provides a web server front-end and core services, such as workflow, agent management, deployment, inventory, security,
as well as others. A service can be thought of as a self-contained mechanism for hosting a piece of business logic. Services
can be consumed by clients\agents or other services. Deployments are orchestrated by the server and performed by agents distributed
throughout the network. Most clients use browsers to communicate with the web server via HTTP(S). Most server-agent communication
is done via JMS (discussed below) but HTTP(S) is also used as required.
Serena Release Automation uses stateless communications for server-agent communications (JMS-based) as well as client-web service communications. Stateless, as used here, means the server retains little session information between requests and each request contains all the information required to handle it. The server sets-up listening sockets and listens for agents, relays, and users (clients). For added security, agents do not listen on ports. Agents send requests when they are ready to make the transition to a new state.
Server-agent communication is built around transferring—deploying—components. Components can contain any business-meaningful content, such as environment information, configuration data, source, static files, or anything else associated with a software project. Because JMS connections are persistent and not based on a request-response protocol, Serena Release Automation does not have to continually open and close ports, which enables the server to communicate with agents at any time while remaining secure and scalable.
Many Serena Release Automation services are REST-type (representational state transfer). REST-style services
are web services that focus on transferring resources over HTTP. A resource can be any
business-meaningful piece of data. Resources are transferred by a self-describing format
such as XML or JSON (JavaScript Object Notation). The XML and JSON representations
typically model resource states at the time of agent/client requests. REST-style services
achieve statelessness by ensuring that requests include all the data needed by the server to
make a coherent response.
The data tier's relational database stores configuration and run-time data. The data tier's file store—CodeStation—contains log files, artifacts, and other non-structured data objects. Reporting tools can connect directly to the relational database.