Author Archives: te-bachi

Software Architectural Style

Leave a reply

Representational state transfer (REST)

Representational state transfer (REST) is a software architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine. REST has been applied to describe desired web architecture, to identify existing problems, to compare alternative solutions, and to ensure that protocol extensions would not violate the core constraints that make the web successful. Fielding used REST to design HTTP 1.1 and Uniform Resource Identifiers (URI). The REST architectural style is also applied to the development of web services as an alternative to other distributed-computing specifications such as SOAP.

Architectural constraints

  • Client–server
  • Stateless
  • Cacheable
  • Layered system
  • Code on demand (optional)
  • Uniform interface

Representational state transfer (REST)

Create, read, update and delete (CRUD)

Create, read, update and delete (CRUD)

Service-oriented architecture (SOA)

Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications. This is known as service-orientation
A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application. SOA makes it easy for computers connected over a network to cooperate. Every computer can run an arbitrary number of services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without the need to make changes to the underlying program itself.

Design concept

SOA is based on the concept of a service. Depending on the taken service design approach, each SOA service is designed to perform one or more activities by implementing one or more service operations. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. SOA design principles are used during software development and integration.
For some, SOA can be seen in a continuum from older concepts of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA)

Other SOA concepts

Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:

  • SOAP, RPC
  • REST
  • CORBA
  • Web services
  • DDS
  • Java RMI
  • WCF (Microsoft’s implementation of web services now forms a part of WCF)
  • Apache Thrift
  • SORCER

Service-oriented architecture (SOA)

Embedded Implementation of Mutexes and Semaphores

Leave a reply

Mutexes and Semaphores Demystified
Programming Embedded Systems in C and C++

ChibiOS/RT

Counting Semaphores, Binary Semaphores and Mutexes explained
Mutual Exclusion guide

System Locks

This is the lowest level mechanism, the system is locked by invoking the chSysLock() API and then unlocked by invoking chSysUnlock(). The implementation is architecture dependent but it is guaranteed to, at least, disable the interrupt sources with hardware priority below or equal the kernel level.

Mutexes

The mutexes are the mechanism intended as the most general solution for Mutual Exclusion.

/**
* @brief Locks the specified mutex.
* @post The mutex is locked and inserted in the per-thread stack of owned
* mutexes.
*
* @param[in] mp pointer to the @p Mutex structure
*
* @api
*/
void chMtxLock(Mutex *mp) {

  chSysLock();

  chMtxLockS(mp);

  chSysUnlock();
}