Tag: Service Oriented Architectures

Microservices is not more than a specialized case of SOA

Posted on by Benjamin Kanagwa

Over the last couple of years, there has been renewed energy in the subject of service oriented architectures. The invention of term ‘micro services’ has warranted a immense interest in the subject of service oriented architectures.

Despite the initial contention on the difference between SOA and the already mature Component Based Software Engineering (CBSE), there is consensus that SOA improves the key attributes of software such as agility, cost to market, flexibility, inter-operability and many others. A service in SOA is now understood as an autonomous software unit that can be used programmatically across the network. Services can interact regardless of the underlying technologies for as long they expose their interfaces for use by other entities.

The size of a service — how much functionality can be bundled into a single service unit is a issue of design left to programmers and software architects. Of course services are compositional – i.e. two or more services may be combined into a new service in its own right. Practice and programmatic recommendations suggest that a service should bundle a business functionality. And SOA in is traditional form has been largely conceived to be applicable at the business level.

Microservice advocate a new way of building systems with more fine grained service units. Simple low-level core functionality can now be exposed as services for use in building high-level systems. A micro service may be as large as a function in a functional language or method in Object oriented Language. Microservices should not be equated to functions or methods because a service is an architectural unit.

Whereas micro services raise the level of flexibility, they increase the number of ‘moving’ parts – each service is autonomous, deployeable in an independent process. This comes with well known challenges of distributed computing. Obviously we have come to learn that in software architecture there is need for trade-offs. It may be very hard to optimize both flexibility and reliability.

The level of granuality and new usage scenarios for microservices, require new support tools for designing, monitoring, provisioning, management of microservice based systems.

Loading

Turning ‘software’ into a ‘software service’

Posted on by Benjamin Kanagwa

This article looks at how to turn an  existing software that is not service oriented into a service that can be used in a service oriented architecture. We need to know  exactly-  what  is a service?  We are assuming the resulting service will provide  identical functionality. So the  only difference between a software service and other software components is at the interfaces. The interfaces define how the service can be used individually or as part of a larger system. In summary a service needs to achieve the following properties :-

  • is self contained, highly modular, and can be independently deployed. A service can do something useful in its own right.
  • is distributed component, accessible over the network or locator other than the absolute network address.
  • has a published interface, so users only need to see the interface and need not to know the internal details of the implementation.
  • is discoverable, meaning users can look it up in a special directory service where all the services are registered. Services designed for public use require to be discoverable, otherwise potential users may never learn about the service.
  • stresses inter-operability such that users and providers use different implementation languages and platforms. That is any software can be turned on a service for use with other services regardless of the languages in which they are implemented.
  • is dynamically bound, which signifies that the service is located and bound at runtime. Therefore service users do not need to have the service implementation at build time.

Therefore, turning  a software system into  a service consists of encapsulating the software such that it is  exposed  to the web via well defined and  flexible network accessible application programming interface (API).  This can only happen using a set of inter-related technologies. Currently web services provide a technology suite that can provide the above listed characteristics.

Our next article will relate the technologies in web service to   the properties of a service.

Loading