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.
2,517 total views, 1 views today
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.
2,431 total views, 3 views today
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.
2,805 total views, 4 views today
To begin with there has been considerable attention to web services in the last couple of years since early 2000. For starters web service are no more that applications that are designed to be used across the web. Web services provide a program-to-program programming model where one service invokes another using web standards including the well known HTTP and XML. Here I outline the main benefits, some technical others business.
- Interoperability – when faced with a challenge varying systems architectures, legacy systems, a cocktail of programming languages that make up systems that make up systems which need to be integrated then web services come in handy. Perhaps the most important benefit of web services they provide a non proprietary means of interactions. Web services only need to speak the same message protocol for them to inter-operate. So far a common set of standards-based communications method that include HTTP, WSDL, SOAP have been developed. These make it possible for web services to be platform-independent.
- Usability – web services are designed to be used over the web, that is just in the same way a page is fetched, one can fetch web services capability over the web. The capability of a web services varies from simple information lookup to complex algorithmic computations. Therefore when a service is used to expose a business logic, then it can easily used.
- Re-usability – Web Services are designed to be combined to deliver more added value services. Web services serve as building blocks and this makes it easy to reuse Web Service components as appropriate in other services. Also legacy applications can be wrapped into web services for use by others
- Deploy ability – Web Services are deployed over standard Internet technologies. For instance using Apache, Axis2 to provide HTTP, WSDL driven services. This makes it simple to deploy
- Agility – this looks at ability to change. When a an enterprise IT infrastructure is streamlined into services, new functionality to address new business demands is a matter of assembling existing services. Of course a few more services may need to build, but overall it is easier that re-building a new system from scratch.
- Quality – Related to reuse, because web service development approaches allows services to be built by assembling existing existing services, it logical to expect that such services are already tested with known performance characteristics. Therefore new systems will be less buggy.
- Cost – The cost of developing new systems reduces significantly since such systems are assembled from ready made web services. Such cost reductions translate into profits on may be passed on the customers. The customers stand to win from cost cuts and efficiency brought in by web service
Overall, an enterprise that streamlines its operations into web services stands to benefit in many aspects.
2,839 total views, no views today