Architecture overview

IBM® UrbanCode Deploy 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, and 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 run by agents that are distributed throughout the network. Most clients use browsers to communicate with the web server with HTTP(S). Most server-agent communication is done with JMS (discussed below) but HTTP(S) is also used as required.

IBM UrbanCode Deploy uses stateless communications for server-agent communications (JMS-based) and client-web service communications. Stateless, as used here, means that the server retains little session information between requests and each request contains all the information that is 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, or deploying, components. Components can contain any business-meaningful content, such as environment information, configuration data, source, static files, or anything else that is associated with a software project. Because JMS connections are persistent and not based on a request-response protocol, IBM UrbanCode Deploy does not continually open and close ports. These persistent connections enable the server to communicate with agents at any time while the agents remain secure and scalable.

Many IBM UrbanCode Deploy 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 that is needed by the server to make a coherent response.

The data tier's relational database stores configuration and runtime 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.

A diagram of a typical system, showing the data tier, service tier, and clients

Feedback