The Service-Oriented Architecture

The Service-Oriented Architecture

CIS 336

The Service-Oriented Architecture

Service-oriented architecture is an approach for the creation of system architecture that is based on the use of services. This leads to business solutions that promote agility in the organization’s operations. The services are usually manifested as web services and lead to flexibility, cost-effectiveness and maintainability. Total Cost of Ownership (TCO) is a method used by businesses to estimate the expenses accrued by the purchase, deployment, usage and decommissioning of a product. It is regarded a fairly accurate method for determining the value of an investment by taking into account both direct and indirect expenses over the entire life cycle of the product. Businesses usually aim to have a much lower total cost of ownership, and this can be achieved by implementing service-oriented architecture. Software licensing costs play a big part in increasing the total cost of ownership of a product. The longer the piece of software is in use and has to be used for new workloads, the increase continues.

This is where specialty engines come into play. Developed by IBM for their System z mainframe platform, these are processors that help users expand the use of their mainframe. The most recent specialty engine from IBM is the System z Integrated Information Processor (zIIP). XML parsing is a function that is CPU-intensive and can be taken over by specialty engines. Service-oriented architecture is platform independent. This means that a user gets to a service without the burden of doing so within a specific environment. For example, functionalities previously accessed via desktop devices can now be accessed from mobile devices. The focus shifts from the platform, to the service itself. This broadens the access base of the service and eliminates costs associated with having to provide access from a single place.

It also enables more users to have access as the constraints to this have been removed. Consolidation brought by service-oriented architecture is associated with indirect costs under the total cost of ownership. In a bid to continue using legacy systems, organizations often resort to investing in more systems that would support this. However, service-oriented architecture helps in integrating various systems into an organized set of co-existing systems. This helps in gradually phasing out legacy systems while maintaining their functionalities in a much more dependable environment. Acquiring new systems and maintaining them is no longer needed. For organizations involved in the development of applications, time to market is an important factor. The faster an application is released to the market, the faster it can begin the return on investment.

By conducting the development within an SOA environment, businesses are able to leverage on the business aligned solutions to achieve this. The necessary resources for this can be deployed much faster, more efficiently and should save the company money that would have otherwise been spent on a dragged out process. Less TCO can be achieved by the agility of systems brought by SOA. The primary way of doing this is implementing loosely coupled systems. Loosely coupled systems enable an organization to strategically operate in a constantly changing environment by being able to manage its systems more efficiently. The business has the capability to couple and decouple with external elements according to prevailing market conditions. The business is able to determine early enough when to decouple from elements that would lead to the incurring of further costs. This can be from a competitive or increasingly regulated market.

The business is able to easily pull out and decide on the course of action (Rosen, et al, 2012). XML is a markup language that provides a way to easily structure information so that it can be extracted and used by other applications. Allowing entire subsets of the language to be created. XML lets businesses and other users decide how data will be presented. It is extensible because it does not have a fixed format (Nolan, & Lang, 2014). XML as a generic data storage format that can be used as a mode of communication between to incompatible systems. This means that a client does not need to use a similar system to access services from the server. A client using Linux should be able to access a server that uses Windows Server. The communication exchange between these two different systems is made possible by XML.

As each system can read XML messages it becomes the medium through which the exchange is facilitated. Web Services Description Language (WSDL) honors the contract a web service has with its clients on the messages it accepts and generates. WSDL can be used to create files that act as identifiers of the services and the set of operations within each service supported by the server. The WSDL file will also describe the format that has to be followed by clients when requesting operations. Defined by the style attribute , operations requested by the WSDL file can either be document oriented, where the request and response messages contain XML documents or RPC-oriented where the request contains the input parameters of the operation and the response contains the results. Web service clients need to discover where the web services are located. The Universal Description, Discovery, and Integration (UDDI) is an XML-based registry of providers of web services and can be accessed by an XML-based discovery document and a protocol for retrieving that document. Web service providers are able to put up their services on the registry and the clients will be able to locate them there.

A messaging protocol can also be used for the exchange of information between the client and the server. Simple Object Access Protocol (SOAP) is an XML-based application communication protocol. It enables communication to take place between applications running on different operating systems. However, since it moved away from being simply used to access objects to a general XML messaging framework, it usually referred to by the acronym, SOAP. SOAP uses XML tools for defining the messaging framework providing a paradigm that is exchangeable over various protocols. XKMS (XML Key Management Specification) integrates PKI and digital certificates with XML applications for secure transactions with web services. Signature processing is delegated to a web trust server and this ensures that mobile or thin clients do not have to move around with these. There are two parts of XKMS, XML Key Information Service Specification (X-KISS) and XML Key Registration Service Specification (X-KRSS). X-KISS defines a protocol for a trust service, which resolves PKI in XML-SIG elements. The client can delegate part or all of tasks needed to process elements which is information about the key signer.

X-KRSS describes how public key information is registered (Nolan, & Lang, 2014). Tight coupling refers to a system where the hardware and the software are not only linked to each other, but are also highly dependent on each other. It also refers to software that can only work in one part of a system and is highly dependent on other software. Loose coupling on the other hand is a situation where multiple computer systems can be joined together to conduct transactions. This is regardless of hardware, software or even if the systems are incompatible with each other. Loosely coupled systems have an exchange relationship that requires little input from each other. While they are able to interact, loosely coupled systems do not depend on each other to work. Loosely coupled software executes its function when they are needed and not when the application is being launched (Luhman, 2012).

Total cost of ownership obviously increases in tightly coupled systems. The interdependent nature of the system components has it that right from the start; the system has to be acquired in its entirety, lest it will not function as envisioned. Any maintenance activities will have to encompass the entire system and the incompatibility with other systems means that the users cannot enjoy the benefits of using third party applications. This is even when these outside applications and services are of benefit. Decommissioning a tightly coupled system retires the whole system at once. Components cannot be salvaged for use with other applications because of issues of incompatibility. Loosely coupled systems on the other hand has operational independence at its core. From the start of the TCO cycle, the initial investment is much lower in comparison with tightly coupled systems.

Any additional costs to be borne for purposes of maintenance of the system are directed at a single place. They also allow their use with and of third party services and applications without regard for compatibility. This puts in a better position of producing a much favorable score in terms of TCO. Loosely coupled systems promote reusability, and this has it that a system is likely to be in commission for a while longer. Even when it is decommissioned, it will barely affect the operations of another component within the same operating environment. Maintaining loosely coupled systems is fairly straightforward. These systems are built to be flexible and as such are much more maintainable. As stated above, by reducing interdependencies between system components, then even if one component requires a maintenance action of some sort, this will be restricted to just that component.

Since they were implemented to work independent of each other, maintenance can then be conducted in the same way. This is with no regard as how that activity will affect another component. Tightly coupled systems on the other hand present a very big challenge when it comes to matters of maintenance. Failure in a single system component will disable the entire system when it is tight coupling that has been deployed. The downside is that to ensure that the system does not breakdown, tightly coupled systems must be maintained as a whole. This means that maintenance activities cannot be focused on a single component, but rather the entire system to ensure nothing drags everything down when it malfunctions. In the implementation of tightly coupled systems, clients usually have to stop after making a request and wait. This ‘stop and wait’ relationship has it that the client will not be able to work until the service request has been responded to.

This is a symbiotic relationship between the two components and one cannot work without the other. Should there be a problem with any of the parties involved, then the other will have to be shut down until the problem has been fixed. This is contrasted by loosely coupled systems where a client requesting a service can continue with other functions as the response is being processed. This is because the two systems operate independent with each other and most of the times are even incompatible. The failure of one does not affect the functioning of the other. Tight coupling occurs in large scale systems for the purposes of optimal design for the system and the minimizing of redundancies among components of the system. These systems are characterized by a large number of critical interdependencies between its components. Loose coupling is implemented to reduce interdependencies between system components and reduce the risk of a change in one component necessitating the change in another (Luhman, 2012).

Standards-based integration helps in setting minimum specifications for meeting security levels. This can be in areas that include credential exchange, message confidentiality and message integrity. Undertaking standards-based integration will then be guided by the security requirements that a service will be need to meet before been declared as being safe. Touting the meeting of these standards and the subsequent adherence to them helps in not only offering assurances to the consumers of the services, but also in differentiating the service provider from others who have not done the same. An existing standard that can be used is the Security Assertion Markup Language (SAML) security standard. Reliability is demanded by service consumers on all systems. Reliability promotes an image of consistency and that users of the system will come to expect a certain level of functionality every time they are using a service. Service consumers and service providers exchange a host of documents during their interactions on the service. There are mission critical systems, which depend on services like at-most-once delivery, guaranteed message delivery, once-and-only-once delivery, duplicate message elimination, and acknowledgment.

By implementing standards in the integration of the various systems, the owners of these systems can rest assured that these systems will carry out their functions correctly. Reliability is addressed by standards like WS-Reliability and WS Reliable Messaging. Integration of data silos, components and applications can be done using services. A controller directing these web services can do so using BPEL4WS or WSBPEL (Web Services Business Process Execution Language) standards. This process, known as orchestration, creating business processes using a set of distinct service, will include parallel processing, asynchronous communication, data transformation, and compensation. The standardization of these tasks should make the orchestration process that much smoother for the controller. (Rosen, et al, 2012). Owners are forced to choose between either a resource-oriented or function-oriented model when conducting the integration. While resource is more towards data, function aligns more with services. Choosing either model will deprive the owner of the benefits of the other.

As with most standard-based decision making, the passage of time might lead to the review of some of these standards. What happens is that had the integration been rigid, it becomes challenging for the owners of the system to realign to a more in tune integration. This is because among other things, it might require additional injection of capital to fund this or that the realignment might cause a serious disruption of business processes. Given that adopting of the standards-based method was not regulatory but rather self-imposed, the organization is forced to bear the costs. Change in standards is usually precipitated by emergence of new technologies. Most of these technologies are meant to disrupt the old way of doing things and usually competitive advantages to those who adopt them. The fact that XML is a fairly recent adoption, and the current standards are developed around it, it stands to reason that a new technology will also lead to the setting of other standards. These standards are largely industry-based.

What this means is that they are usually set by the industry players coming together and agreeing on what will make up the standards. This is usually for among other factors, achieving intra-sector interoperability. However, these industry players are still businesses and are driven by profits. The effect of this is that should one of them chance upon a different way of doing things that they believe will bring more tangible benefits to their integration efforts, they will adopt it. In the interest of staying ahead of competitors, they might be willing to share it. They could be willing to sacrifice the interoperability if they believe they are at a position of profiting more (Anandamurugan, & Priyaa, 2014). The application of service-oriented architecture to be successful must be aligned to business goals to provide the highest potential for success. This ensures that any decision taken in regard with the system architecture has direct impact on an organization’s business operations for the better.

References

Rosen, M., Lublinsky, B., Smith, K. T., & Balcer, M. J. (2012). Applied SOA: service-oriented architecture and design strategies. John Wiley & Sons.

Luhman, N. (2012). Introduction to Systems, Theory. Politi Press.

Nolan, D., & Lang, D. T. (2014). An Introduction to XML. In XML and Web Technologies for Data Sciences with R (pp. 19-52). Springer New York.

Serrano, N., Hernantes, J., & Gallardo, G. (2014). Service-oriented architecture and legacy systems. Software, IEEE, 31(5), 15-19.

Anandamurugan, S., & Priyaa, T. (2014). Service oriented architecture.