Tag: SOA

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

A short answer to a Bank Manager about Software as a Service and SOA

Posted on by Benjamin Kanagwa

Recently, I met an executive of a top bank who was trying to roll his head around the notion of software as a service and service oriented architecture. He intimated to me that these two terms are the only things he hears from software development vendors and the internal Information Technology team. I offered an explanation that went as follows.

Software as a service represents a shift in the way software is developed and used. In traditional software development, the software executable or program  code is installed on the users computer. This requires a copy of the same software for each user creating challenges in updating, maintenance and licensing.

SaaS allows software to be installed and used over the Internet or Intranet. It allows a single copy of the same software to be used by different users from a single location through the network, which may be  intranet or internet. Even when multiple copies are deployed, they provide redundancy rather than a copy for each user. Under SaaS, access to the software is strictly through external Application Programming Interfaces (API). To encourage loose coupling, the mode of communication is usually message passing. Because the software is used through an external interface and most often owned by a different party,  this is sometimes referred to as consuming a service.

An architecture that is based on consumption of different capabilities of software programs by way of external interfaces is called a Service Oriented Architecture (SOA). With SOA, solutions can be built faster because we rely on existing SaaS functionality and add only what is missing. Incase of failure of one SaaS provider, it is possible to switch to other providers. Moreover,   most SaaS vendors allow consumers to pay for only what they consume.

He appeared to understand and promised to get back to me, and will give feedback as soon as I hear from the manager.

Loading

Software programming and problem solving

Posted on by Benjamin Kanagwa

Programming is the process of planning a sequence of steps called instructions for the computer to follow. The fact that you are reading this post you already know that computers lack common sense and cannot make any judgment. So the computer will do as instructed by the programmer through the computer program. Programming is more about problem solving than coding.

A problem is the difference between things as perceived and things as desired. A solution will move the situation from the things as perceived to the things as desired.

Programmers are problem solvers and need to improve the art and science of problem solving. On one hand problem solving involves an element of art in that experience, judgment and common sense can help deliver smart solutions. On the other hand problems solving is a science involving scientific means of arriving at solutions. Overall, there are several steps to be taken to solve problems

  • Define the problem
  • Analyse the problem
  • List/Identify  alternative solutions
  • Select the best solution
  • List instructions that lead to the solution using the selected solution
  • Evaluate the solution

in the next post, more details on each step shall be discussed

Loading