Service Orientation and Interoperability
In this article, we will take a look at the Service Oriented Architecture principles of service orientation and interoperability. Let’s start with service orientation first. Service orientation can be thought of as a design paradigm that is used to specify the creation of automation logic in the form of services. Service orientation is applied as a strategic goal in the development of Service Oriented Architecture. Like a lot of other design paradigms, service orientation should successfully provide a means of attaining a separation of concerns.
The History of Service Orientation Principles
The definition of service orientation varies according to which Service Orientation Architecture platform is being utilized. Some vendors promote different principles over others. The fact of the matter is, however, that a lot of commonalities can be found among the different ones.
One of the first individuals to present a set of service orientation guidelines was Don Box of the Microsoft Corporation. Box’s service orientation principles were described in relation to the Microsoft Indigo, which is now known as the Windows Communication Foundation. Such principles have since evolved as the main design guidelines for Microsoft based documentation, for instance the Service Orientation and Its Role In Your Connected Systems Strategy, an article that was published on MSDN.
The first piece of researched that was published in a public forum about service orientation was by Thomas Erl of SOA Systems Inc. Erl defined eight service orientation principles that were common to all primary Service Oriented Architecture platforms. Such principles were published in the article Service Oriented Architecture: Concepts, Technology, and Design.
Then there was an article published in late 2005 called the Impact of Service Orientation at the Business Level. This article was a study on how service orientation relates to componentization as well as the IBM Component Business Model.
This was followed by an article called SOA Simplified. In this article, Sandy Carter, IBM’s Vice President for Strategy, focused on the importance of service orientation as well as its relevance to the attainment of true reuse.
Paul Allen authored a book in which Service Orientation was defined as a paradigm with three major components. These included Service Oriented Architecture, Business Architecture, and Software Oriented Management. The seven service oriented viewpoints listed by Allen include transparence, customer fit, one stop experience, partner connectivity, adaptation, optimization, and multi channel capability.
The viewpoints of course do have a more high level approach. They are not quite as specific and interlinked as Erl’s service orientation principles. Allen rather utilizes them as a starting point for asking questions during the process of design.
Service Orientation and Object Orientation
Oftentimes, service orientation gets compared to object oriented design. Most people are aware of the fact that many service orientation principles have their roots in object oriented design. Many feel that service orientation will one day replace object orientation as the primary design paradigm. Still, others feel that the two design platforms compliment one another, and thus there will always be a need for both.
Service Orientation and Service Oriented Design
The phrase “service oriented design” is typically employed in reference to the formal process where by services are design for Service Oriented Architecture. When it is used in general terms to designate an approach for the design of solution logic as services for Service Oriented Architecture, then service oriented design may be considered to be the same thing as service orientation.
Service Orientation Future
Service orientation is consistently recognized as a vital component of the service oriented computing landscape, as well as a nifty design approach to attaining service oriented architecture. It should be kept in mind that the principles of service orientation are oftentimes referred to as Service Oriented Architecture principles.
Owing to the full range of interpretations endowed upon the notion of Service Oriented Architecture, it may not always be clear what exactly is being talked about. Allan and El alike stress the aspect of service orientation as an encompassing paradigm.
Interoperability
Interoperability refers to the process whereby people, systems, and data are connected. The word interoperability can be viewed in a broad way, or a more technical way. It may take in to account software procedures, but also social and political meaning.
One definition of interoperability considers it as the ability of several systems or components to exchange data and to utilize the data that has been exchanged.
In the field of telecommunications, interoperability has a twofold definition. It is first thought of as the ability of forces, systems, or units to provide services while also accepting services from other systems, forces, or units, and to utilize services exchanged as a means of enabling them to effectively operate together.
The other half of the definition of interoperability refers to the condition that is attained among electronics and communications systems or items of such equipment when services or data can be exchanged directly between them and their users. The amount of interoperability must be defined when referring to particular cases.
In the case of two way radio, interoperability consists of three dimensions. One is devoted to scalable capacity; another to compatible communications paths, such as equipment, signaling, and compatible frequencies; and a third is devoted to radio system coverage or adequate signal strength.
Software
In terms of software, the word interoperability is employed as a means of describing different programs’ capability to exchange information through a common set of Business procedures, while simultaneously writing and reading the same file formats and utilizing identical protocols. The ability to execute the same binary code on various processor platforms is typically not a part of the definition of interoperability.
When interoperability is lacking, it implies that the products in question were not designed with standardization in mind. Indeed, interoperability is certainly not taken for granted in the computing and electronic data processing worlds, particularly in the non standards based portion.
Interoperability has been defined as the capability of communicating, executing programs, and transferring data among various functional units in a fashion that necessitates that the user have at least some knowledge of those units’ unique characteristics. Such a definition tends to focus on interoperability’s more technical side. At the same time, some will argue that interoperability is indeed more of an organizational concern.
To be precise, interoperability tends to have a huge impact on the organization in question, engulfing questions of ownership (i.e. do people have any desire to share their data?), employment (i.e. are individuals willing to undergo training?), as well as usability concerns. In such a context, it might be more precise to speak of “Business process interoperability.”
Interoperability can have major financial consequences, such as network externalities. In the event that a competitor’s products are not interoperable (this often happens owing to such problems as trade secrets, patents, or failure of coordination), then the result can be either market failure or monopoly.
It is for this reason that governments and user communities are encouraged to take steps to show the positive aspects of interoperability in various situations. In the United Kingdom, for instance, there is interoperability on the eGovernment level known as e-GIF.
In terms of user communities in the United Kingdom, Neutral Third Party has been creating standards in recent years for Business process interoperability. Another good example of a third party that is neutral is the Request for Comments documents located on the Internet Engineering Task Force.
Interoperability is typically attained in one of four ways – via the engineering of products, the partnership between an industry and a community, the implementation of service standards, and good access to IP and other forms of technology.
It is a well known fact that interoperability tends to be viewed as a concern for experts in the field only. The implications of interoperability for daily living are oftentimes overlooked or underrated. The recent case, however, of Microsoft versus the European Commission is a good indicator of how interoperability can become wrapped up in vital questions regarding relationships of power.
It was in the year 2004 that the European Commission reached the conclusion that Microsoft had abused its market power through deliberately restricting the degree of interoperability that existed between Window PCs and non Microsoft work group servers.
In restricting interoperability in this fashion, Microsoft managed to a acquire a major portion of the market share for work group server operating systems, which form the heart of corporate Information Technology networks. As a result of this case, Microsoft was asked to disclose accurate, complete interface info, which enabled rival vendors to compete on equal footing.
The most recent Microsoft efforts surrounding the subject of interoperability indicate a shift in their approach and commitment to interoperability. Such attempts include the migration of Microsoft Office file formats to ECMA Office Open XML, as well as several interoperability partner agreements – one of the most notable examples of this is their recent partnership with Novell. Microsoft has yet to fully resolve this issue.
There was also a recent debate, in the year 2005, about interoperability in the European parliament regarding software patents.
