This lesson was originally featured at Software Architectural Patterns & Design Structures. It has been republished here with permission from Nishant Sharma
Shared-data (or repository) pattern: This pattern comprises components and connectors that create, store, and access persistent data. The repository usually takes the form of a (commercial) database. The connectors are protocols for managing the data, such as SQL.
Microkernel :The microkernel pattern, or plug-in pattern, is useful when your application has a core set of responsibilities and a collection of interchangeable parts on the side. The microkernel will provide the entry point and the general flow of the application, without really knowing what the different plug-ins are doing.
Client-server pattern: The components are the clients and the servers, and the connectors are protocols and messages they share among each other to carry out the system's work.
Multi-tier pattern: which describes how to distribute and allocate the components of a system in distinct subsets of hardware and software, connected by some communication medium. This pattern specializes the generic deployment (software-to-hardware allocation) structure.
Microservices: When you write your application as a set of microservices, you're actually writing multiple applications that will work together. Each microservice has its own distinct responsibility and teams can develop them independently of other microservices. The only dependency between them is the communication. As microservices communicate with each other, you will have to make sure messages sent between them remain backwards-compatible. This requires some coordination, especially when different teams are responsible for different microservices.
A diagram can explain.
1. Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured.
2. Component-and-connector structures embody decisions as to how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors).
3. Allocation structures embody decisions as to how the system will relate to non software structures in its environment (such as CPUs, file systems, networks, development teams, etc.).
- Decomposition structure: The units are modules that are related to each other by the is-a submodule-of relation, showing how modules are decomposed into smaller modules recursively until the modules are small enough to be easily understood.
- Uses structure: In this important but overlooked structure, the units here are also modules, perhaps classes. The units are related by the uses relation, a specialized form of dependency.
- Layer structure: The modules in this structure are called layers. A layer is an abstract "virtual machine" that provides a cohesive set of services through a managed interface.
- Class (or generalization) structure: The module units in this structure are called classes. The relation is inherits from or is an instance of
- Data model: The data model describes the static information structure in tenns of data entities and their relationships.
- Service structure: The units here are services that interoperate with each other by service coordination mechanisms such as SOAP
- Concurrency structure: This component-and-connector structure allows the architect to determine opportunities for parallelism and the locations where resource contention may occur.
- Deployment structure: The deployment structure shows how software is assigned to hardware processing and communication elements.
- Implementation structure: This structure shows how software elements (usually modules) are mapped to the file structure( s) in the system's development, integration, or configuration control environments.
- Work assignment structure: This structure assigns responsibility for implementing and integrating the 1nodules to the teams who will carry it out.
SOAP is a protocol specification for XML-based information that distributed applications can use to exchange information and hence interoperate. It is most often accompanied by a set of SOA middleware interoperability standards and compliant implementations, referred to (collectively) as WS. SOAP and WS together define many standards, including the following:
An infrastructure for service composition. SOAP can employ the Business Process Execution Language (BPEL) as a way to let developers express business processes that are implemented as WS * services.
Transactions. There are several web-service standards for ensuring that transactions are properly managed: WS-AT, WS-BA, WS-CAF, and WS-Transaction.
Service discovery. The Universal Description, Discovery and Integration (UDDI) language enables business.
Reliability. SOAP, by itself, does not ensure reliable message delivery. Applications that require such guarantees must use services compliant with SOAP's reliability standard: WS-Reliability.
Sign up for our newsletter list and join over 3,000 brilliant developers leveling up and solving coding challenges daily.