The Sepia project forms part of the larger Eiffel Community, where it provides guidance both to contributors and users of the Eiffel protocol and its implementations. While there is an infinite number of possible solutions to the problem of implementing the Eiffel protocol, Sepia represents one such solution, recommended and supported by the community.
Below you will find an overview image of the architecture. Each item in the overview is a clickable link that will take you to its description, example implementations and API specifications. Each Pipeline Actor role is presented along with the event types of which it holds authorship, with further details provided in the description of the Pipeline Actor role.
An Event Service is a service that does not act in the pipeline, but exists to facilitate the handling of Eiffel events. This may be services for authoring (Command) or for consuming (Query) of such events. Event Services are typically not the provenance of Eiffel event data, but serve the Pipeline Actors and/or users by storing, analyzing, transporting and analyzing the event data.
A Mode of Access captures a form of interaction with Eiffel events. It does not represent any physical entity, but merely describes a type of behavior.
Pipeline Actors are the entities that act upon the software in the pipeline. Among the usual suspects are tools that manage, store, test, package and build software. These are authors of Eiffel event data, but may also consume data from other Pipeline Actors in order to inform and configure their behavior.
Sepia always reflects a specific edition of the Eiffel protocol. You are currently looking at the Arica edition.
Like any architectural description, Sepia makes certain choices with regards to what to express, and what not to express. Sepia is different from most software architecture descriptions in that it does not express a single identified system, but rather a template of a system. Consequently it does not identify implementations directly, but roles for implementations to fill along with the responsibilities and constraints of those roles. Beyond those responsibilities and constraints, different implementations may have different features or side effects. In particular, Sepia defines which Pipeline Actors are responsible for authoring event types, but not which event types they may consume. This is intentional, as it preserves a high degree of freedom in implementing Eiffel to suit the individual case. To exemplify, it is perfectly legal for implementations of the Activity Orchestration role to only publish relevant events, but it may also be implemented to consume and trigger based on any Eiffel event type.
Furthermore, Sepia does not define direct dependencies or interactions between Pipeline Actors. To continue with the example above, the Activity Orchestration actor may instruct an Activity Execution actor directly via API calls, or the Activity Execution actor may listen to events emitted by the Activity Orchestration actor, or both roles may be filled by the same implementation, turning all communication between the two roles into intra-process calls. This is why the Sepia overview contains no dependency connections. The only connections in the overview are those between Even Services and Modes of Access, representing the data transportation paths to and from the RabbitMQ Message Broker.