Service Oriented Architectures (SOA)

Table of Contents

INDEX OF GRAPHICS

INDEX OF ABBREVIATIONS

1. INTRODUCTION

2. FUNDAMENTALS
2.1 DEFINITION
2.2 HISTORIC DEVELOPMENT
2.3 TECHNICAL DETAILS

3. ANALYSIS
3.1 METHODOLOGY
3.2 SWOT ANALYSIS
3.2.1 Strengths
3.2.2 Weaknesses
3.2.3 Opportunities
3.2.4 Threats
3.3 SUMMARY OF ANALYSIS
3.4 PROPOSED FRAMEWORK

4. SCENARIO ANALYSIS
4.1 SCENARIO “INTERNAL SOLUTION”
4.2 SCENARIO “HOST-BASED SOLUTION”
4.3 SCENARIO “VENDOR-BASED SOLUTION”
4.4 SCENARIO “OFF-THE-SHELF SOLUTION”
4.5 SUMMARY

5. EVALUATION OF RESULTS

6. FUTURE ISSUES

7. CONCLUSION

APPENDICES
APPENDIX 1: THE SOA NAVIGATOR
APPENDIX 2: FURTHER DETAILS ON NAVIGATOR DIMENSIONS
APPENDIX 3: NAVIGATOR PROFILES OF SCENARIOS

REFERENCES

Index of Graphics

PICTURE 1: SERVICE ORIENTED ARCHITECTURE

PICTURE 2: SERVICE ORIENTED ARCHITECTURE USING WEB SERVICES

PICTURE 3: SWOT-MATRIX FOR WS-BASED SOAS

PICTURE 4: SCHEMATIC VIEW ON THE SOA NAVIGATOR

PICTURE 5: DETAILED VIEW ON THE SOA NAVIGATOR

PICTURE 6: NAVIGATOR PROFILE OF SCENARIO “INTERNAL SOLUTION”

PICTURE 7: NAVIGATOR PROFILE OF SCENARIO “HOST-BASED SOLUTION”

PICTURE 8: NAVIGATOR PROFILE OF SCENARIO “VENDOR-BASED SOLUTION”

PICTURE 9: NAVIGATOR PROFILE OF SCENARIO “OFF-THE-SHELF SOLUTION”

Index of Abbreviations

Abbildung in dieser Leseprobe nicht enthalten

1. Introduction

Service oriented architecture (SOA), often enthusiastically emphasized as the future IT infra­structure is currently a big topic in the IT community. IT consultants as well as the software providers are presenting the advantages and possibilities of SOA, but even in the magazines and journals a critical discussion does not seem to occur. The technical features seem to be promising but the advantages from a management perspective remain unclear.

The ideas and principles of SOA are not new but existed for about twenty years. Focusing on the development of IT within this period with its various characteristics and technological developments like the mass production of personal computers, the internet and programming languages uncoupled from the absolute programming it can be clearly stated that from this perspective the concept of SOAs is rather old. Hence, it is interesting to demystify SOA by questioning why it has become such a popular topic during the recent years. Two answers can be given: First of all, even though the concept of service oriented architecture is not new, the technology standard today is for the first time sophisticated enough to make the concept reality and secondly, a lot of companies follow the management trend to restructure their business towards a customer-oriented and process efficient architecture. For those who follow this trend, a SOA offers the flexibility to adapt the IT infrastructure to this new management perspective.

This seminar thesis should provide an introduction into the technology and management possibilities of SOA by describing the status of SOA today, including the advantages and disadvantages from both, technological and management view. Hence, technical and non­technical issues are treated equally. Generic dimensions and strategies should clarify the company specific relevance of SOA and provide a strategic decision-framework. Examples are given and the results are evaluated. Finally, an outlook for possible developments in the future is given.

For the seminar thesis, the assumption is made to focus on companies with an IT infrastruc­ture with a level of complexity and customization requiring constant IT expertise. Both IT and business processes are seen as relevant. For the amortization of both terms it is to be assumed that the business process is in a generic way the disposal of activities whereas the IT process has the supportive status to organize the data flow.

To clearly differentiate between the two, in the following the term IT process is used for describing the IT process and business processes are called business processes.

For this thesis, SOA is the object of examination. The objective is whether the SOA is habile to facilitate or even ameliorate the supportive function of the IT process.

The conceptual design expatiates, next to the introduction four chapters: Fundamentals, Analysis, Future Issues and Conclusion.

In the fundamentals of SOA, as the term already suggests, the basic principles and the deriva­tion of SOA is explained by defining the term as well as the history and technical details.

Both, the historical derivation and technical details are the premises for the contestation. History is important for gaining an understanding of today’s status of service oriented archi­tecture and the ability to be able to make future predictions. The technical details explain the function of SOA and are the fundament for the consecutive analysis.

The body of the seminar thesis is the analysis. The analysis is based on a Strengths, Weak­nesses, Opportunities and Threats matrix based on Andrews¹ whereby each section covers technical and non-technical occurrences. The result of this analysis should be a comprehen­sive but general picture of SOAs today. Using this picture, admissible generic dimensions can be deducted which cover the second part of the analysis.

In the second part, a navigator is affiliated from the identified dimensions. This navigator should be a veritable analysis tool for assessing the relevance of SOA. A practical application by companies is designated. Subsequently, four scenarios are presented that on the one hand demonstrate the use of the navigator and on the other hand deduce generic strategies to deal with SOA.

For the outcome of the analysis, best practice examples and statistics provide little insight and are therefore not included in this paper. That is because statistics, like for instance the number of US companies which have already implemented service oriented architecture, do not sim­plify the decision-making process of a company. On the contrary, best practice examples can simplify the process but the usage is limited to a specific and exemplified industry, e.g. bank­ing. This seminar thesis has a general pretension. Hence, an evaluation of the results of the analysis by an expert in SOA is exposed to proof the generic occurrence.

The future issues present the authors’ view of the future development of service oriented architecture. The conclusion summarizes the results of the seminar paper.

2. Fundamentals

After introducing SOAs as the object of examination of this thesis it is important to further clarify this term. As a foundation for the subsequent analysis, this chapter will try to find a definition for SOAs. Afterwards, a section will be dedicated to the historical development of these architectures and their underlying concepts. In the end of this chapter, the technical details of a possible SOA implementation will be given.

2.1 Definition

To clarify the object of examination of this paper, this section will try to give a definition what SOA is. When trying to define SOA it is very important to understand that it is not a concrete technical implementation of an idea, but that it describes this idea as an abstraction from all underlying technical questions. The advantage of this is that such an abstraction allows focusing on the relevant concepts on which SOA is based. Picture 1 illustrates the general actors and their relations in a SOA:

illustration not visible in this excerpt

Picture 1: Service Oriented Architecture ²

In essence, a SOA expresses a software architectural concept that defines the use of services to support the requirements of software users. In a SOA environment, nodes on a network make resources available to other participants in the network as independent services that the participants access in a standardized way.³ Services are self-contained, stateless business functions which accept one or more requests and return one or more responses through a well-defined, standard interface.⁴ Ideally, these business functions are modular, i.e. they provide one bit of very specialized functionality.⁵ Another important aspect of services in a SOA is the fact that they are encapsulated.⁶ This means that their functionality is contained in an interface layer.

In order to detail out the above definition, two steps will be done. Firstly, the roles of the network nodes will be explained. Secondly, core principles will be identified that constitute a SOA.

The explanation of the components is very straightforward. The Service Requestor⁷ is the entity in the network that has a particular need. This can be a calculation program that needs a particular mathematical operation or a software DVD player that requires a special codec. The solution to these problems is offered by the integration of external services, offered by a Service Provider⁸. In order to allow the client to find a proper service, and to be able to com­pare certain services based on relevant criteria to the user, a central repository that contains this information is integrated into the architecture. This Service Broker⁹ holds information comparable to the white/yellow/green pages to facilitate the search and integration of these external services.

While the above roles can also be realized in what is known as object-oriented message ex­change architectures, SOA is very literally much more than just the sum of these parts. The reasons for this are the core principles that constitute a SOA. While current literature lists plenty of principles that are regarded to be fundamental¹⁰, 4 core principles can be identified.

- Loose Coupling¹¹: This describes the characteristic that the services are generally not dependant on each other. The only dependence is in following the service contracts that are established between a service and a client and that are described in the description at the broker.
- Open Standards¹²: Due to the limited success of older, proprietary implementations of SOAs that often created vendor dependencies and limited the interoperability that is es­sential for a real distributed architecture, open standards are regarded a very important principle of modern SOAs. This holds especially true when considering the distribution across organizational boundaries and the necessary interoperability.
- Modularity¹³: Service should provide a “granular” functionality. Application-like com­plexity or business processes are generally realized by composing these granular services. This becomes apparent when considering the statelessness of a service¹⁴, i.e. the inde­pendence of any preset condition. Adherence to this principle is necessary to guarantee the dynamic combination of any services, closely related to the loose coupling above. Modu­larity has already been integrated into early SOA implementations and clearly improves this solution over prior concepts.¹⁵
- Simplicity¹⁶: The final core principle is that interfaces created, messages exchanged and protocols used are as simple as possible. The necessity to realize this is also derived from the limited success of past implementations of the SOA concept.

2.2 Historic Development

SOA as such is not a new concept. As early as 1999, first implementations of a SOA could be found in the market such as HP’s e-Speak. But even before the term SOA appeared, the evo­lution of what lead to SOAs started in the mid 80’s of the last century. Large mainframe computers as a centralized resource executed applications for either local or distant terminals. Over time, the development of more powerful and cheaper micro-processors and more readily available network capacity lead to the creation of Distributed Systems.¹⁷ A problem with this topology was that systems needed to be able to execute programs that were located on a po­tentially distant resource. Furthermore, data necessary to run this program could be stored on yet another machine. In order to cope with these demands, Remote Procedure Calls (RPCs) were developed and embodied in standards such as the Distributed Computing Environment Standard.

In the mid 90’s, Object Oriented and Component Based Programming emerged and started to replace earlier concepts. Within this setting, multiple standards for the realization of distrib­uted systems in an object oriented world started to be realized. Good examples for such sys­tems are Microsoft’s Distributed Component Object Model (DCOM)¹⁸, Sun’s Remote Method Invocation (Java RMI)¹⁹, or the above mentioned e-Speak of HP. All of these models however have a substantial flaw: they are based on proprietary platforms or programming languages and are hence restricted to a deployment in the respective worlds. As it can be seen later in this paper, one of the major advantages of SOA is the fact that the modular services can be integrated into a business’s value chain even across organizational boundaries.²⁰ When being limited to a MS operating system or the Java language, it becomes virtually impossible to capitalize on this advantage. It cannot be assumed that all businesses involved are running the same platform. Hence, expensive porting would be necessary which often also limits functionality.²¹ Furthermore, being limited to any proprietary requirement is often regarded as a hurdle for wide-spread acceptance of a new technology. A good example here is the e-Speak solution that failed to generate any substantial market impact.²²

A more promising because independent approach was the establishment of the Common Object Request Broker Architecture (CORBA)²³ by the Open Management Group (OMG). CORBA is the first independent architecture to realize a Service Oriented Architecture. The way it works²⁴ is already very close to the structure of SOAs with Web Services (WS), the most recent development in the area of Service Oriented Architectures. However, the CORBA had and still has some points of critique. The most important one is the inherent complexity of the CORBA. The Carnegie Mellon Software Engineering Institute has analyzed this complex­ity and concluded that these factors constitute a major challenge to adoption. Especially the fact that SOA implementations of different vendors are still not fully interoperable is pointed out in this analysis.²⁵

The next development was the adoption of WS to be used as implementation technology for the concept of SOA. Their both major and yet plain advantage is their inherent simplicity. This simplicity is mainly derived from the use of the Extensible Markup Language (XML)²⁶. Through the fact that XML is a generic format for messages, it provides the necessary inde­pendence from underlying programming languages and operating system interfaces. Together with the independence of XML from specific vendors, the use of this message format pro­vides a solution to the dependability problem identified above. This concept of XML allows for the realization of the modularity principle and forces developers to use the principle of loose coupling.

The use of WS is the most recent development in the implementation of SOA. But before the analysis of the SWOT-profile of this solution, it is necessary to draw out in more detail how this technology actually works.

2.3 Technical Details

As indicated above SOA is a bare concept, a proposed architecture for an IT landscape. Hence, it is surprising that technical details are offered on something that is explicitly sup­posed not to be technical. This is the reason why tying the SOA concept to any technical implementation has be critiqued quite recently.²⁷

The necessity to do so anyway is derived by the purpose of the analysis of this paper. When trying to aggregate the business and IT context of SOA to derive strategic implications for businesses that are confronted with the potential opportunities of this IT architecture, a tangi­ble technology is more easily assessable than a generic concept.

In the past, as lined out above, such an analysis would have resulted in the examination of a proprietary vendor standard such as RMI or DCOM. The most abstract alternative would have been CORBA. But with WS on the rise as the most promising development in this area, analysis of the technical implementation of SOA with WS seems to be viable and sustainable.

The claims about the future of WS are impressively underlined by the development of market figures for WS. In their report “Web Services Market 2004-2008” the Radicati Group indi­cates that the market for WS solutions, management, integration and security will rise from USD 950 million in 2004 to USD 6.2 billion on 2008.²⁸ Given the fact that about 75% of all IT decision makers surveyed by the Yankee Group plan to invest in SOAs in 2005,²⁹ a con­siderable share of this growth will come from SOA implementations. The development of WS based SOAs can therefore be considered to be sustainable enough to base our analysis on it. When explaining how WS work in a SOA it is advisable to extend the triangle with the ac-tors.³⁰ Especially the transactions between these actors need to be detailed out. Picture 2 provides an overview of the actors, their interactions and details on the transactions.

To describe how the above works, the entire process of creating, publishing, searching, find­ing, contacting and binding a Service will be examined.

How to access services?

Picture 2: Service Oriented Architecture using Web Services³¹

First of all, the functionality of a Service has to be implemented. When doing so, it does not matter which programming language and/or operating system this functionality is realized in. As described above, the encapsulation of this functionality creates an interface that allows for the exchange of standardized messages rather than specialized program code. In order to create this interface, the Web Service Description Language (WSDL)³² is used. WSDL is used to describe the Service that is offered. Besides information about the method offered, also input and output parameters are detailed out and the transport protocol in use is specified.

This set of data is also called meta-data and can contain much more information than just the examples listed above.³³ These things are new and are also a main differentiator of as WS-based solution compared to the earlier implementations.³⁴ In the area of SOA, where interop-erability is an important topic, the Top-Down Method is generally used for the creation of the WSDL interfaces. Instead of writing the interface for a service first and then generating the interface description (Bottom-Up Method), the description is used to generate the interfaces. This is done because of the possibility that, if the WSDL description is generated based on the provider’s interface using one tool, the client side using another tool might not be able to interpret the WSDL correctly.³⁵ If the WSDL is created by hand, a matching interface can be created on the client side, independent from the tool used.³⁶

These interfaces work a bit like the classical machine code example from JAVA. Imagine the following: a service is implemented in JAVA and the client of the requestor is implemented in C++. It is likely that these two cannot communicate directly with one another. To solve this dilemma, the provided service is hidden or encapsulated behind a layer of software that inter­prets and translates the incoming message. In order to make sure that the service’s translator does not need to know all possible incoming languages, an abstract language is used. To allow the client’s software to also speak this abstract language, it also needs a translator. These translators are called Skeleton on the service side and Stub on the client side, repre­sented by the dark grey elements in picture 2. As the Stubs are created dynamically when communication with the service is needed, the WSDL is necessary to provide the correct “blueprint” to build the translator.

During communication the abstract language mentioned above is used. This abstract language is called SOAP³⁷,³⁸. It is the messaging format used with WS and is based on XML as a data exchange format. Since WS use the everyday internet as the transport platform for the mes­sages exchanged, the HTTP³⁹ became accepted as the transport protocol for SOAP mes-sages.⁴⁰

But before the exchange of messages can be realized, the client needs to find a service. While the classical peer-to-peer principle, searching of the entire network when the need for a serv­ice is realized, certainly is the most dynamic method to do so, response time considerations limit the potential of this method. Hence, SOA with WS generally realize an infrastructure based architecture, as seen above. Centralized service repositories, such as the UDDI Busi­ness Registry⁴¹ established by IBM, Microsoft, SAP, and NTT-Communications, serve as public, central contact points. As the name of the above database already indicates, Universal Description, Discovery and Integration (UDDI)⁴² is very important in this step. It realizes the repository that allows for the search for services and the exchange of information how to contact the service. Optimally the WSDL descriptions are available via an UDDI service.⁴³ The general operations of how this architecture works during run time can be divided into two phases: (1) the development phase and (2) the use phase. The first one covers the establish­ment of the connection between the requestor and the provider. As already indicated above, the requestor contacts the broker using a XML based message to browse the UDDI directory. Once a proper service has been found, the requestor is supplied with the WSDL description of the service and can create the Stub. This concludes the development phase.

During the use phase the client software of the requestor uses the generated stub to generate a XML based SOAP message. It contains the specified inputs and the service request.⁴⁴ The Skeleton in the service side receives the message and interprets the content. The input vari­ables are than delivered to the method requested. Afterwards, the operation is reversed and the Skeleton wraps the output of the method in a SOAP message that is delivered to the requestor. Here the Stub interprets the content and delivers the result.

This concludes the second chapter in which the general principles of SOAs were defined, a brief overview over the history and development of these concepts was given, and the most recent implementation using WS was introduced. These insights will be the basis for the subsequent analysis of the SWOT-profile of SOAs in a business context in the next chapter.

[...]

---

¹ Cf. ANDREWS (1971), quoted in: FLEISHER, BENSOUSSAN (2003), p. 103.

² Cf. DOSTAL et. al. (2005), p. 12.

³ Cf. WIKIPEDIA (2005).

⁴ Cf. WIKIPEDIA (2005).

⁵ Cf. GAINES (1977), pp. 16-21.

⁶ Cf. DOSTAL et. al. (2005), p. 12; CRAWFORD et. al. (2005), p. 104.

⁷ For the purpose of this paper, the termsrequestorandclientwill be used synonymously.

⁸ For the purpose of this paper, the terms server and service will be used synonymously.

⁹ For the purpose of this paper, the termsbrokerandrepositorywill be used synonymously.

¹⁰ Cf. ERL (2005); KOSSMANN, LEYMANN (2004), pp. 118-119.

¹¹ Cf. ERL (2005).

¹² Cf. DOSTAL et. al. (2005), p. 9.

¹³ Cf. BROWN, HAGEL (2003), p. 54.

¹⁴ Cf. WIKIPEDIA (2005).

¹⁵ Cf. ESTREM (2003), p. 513.

¹⁶ Cf. DOSTAL et. al. (2005), p. 9.

¹⁷ Cf. TANNENBAUM (2003), quoted in: MIHAJLOSKI (2004), p. 10.

¹⁸ Cf. HORSTMANN, KIRTLAND (1997).

¹⁹ Cf. SUN (1997).

²⁰ See section 3.2, p. 11.

²¹ Cf. MIHAJLOSKI (2004), p. 19.

²² Cf. GISOLFI (2001).

²³ Cf. OMG (2004).

²⁴ Cf. MIHAJLOSKI (2004), pp. 15-18.

²⁵ Cf. WALLNAU (1997).

²⁶ Cf. YERGEAU et. al. (2004).

²⁷ Cf. MACVITTIE (2005), p. 77.

²⁸ Quoted in KERNER (2004a).

²⁹ Quoted in KERNER (2004b).

³⁰ See picture 1, p. 3.

³¹ In dependence on: MIHAJLOSKI (2004), p. 12.

³² Cf. CHRISTENSEN et. al. (2001).

³³ Cf. KOSCHEL, STARKE (2005), p 18.

³⁴ Cf. KOSCHEL, STARKE (2005), p. 19.

³⁵ Cf. MIHAJLOSKI (2004), p. 23.

³⁶ Cf. MIHAJLOSKI (2004), p. 23.

³⁷ Cf. GUDGIN et. al. (2003).

³⁸ Originally SOAP stands for “Simple Object Access Protocol”. Since version 1.2 this acronym is no longer in use.

³⁹ Cf. BERNERS-LEE et. al. (1999).

⁴⁰ For a more detailed discussion on how SOAP works cf. WOLTER (2001).

⁴¹ Cf. IBM (2005).

⁴² Cf. BELLWOOD et. al. (2002).

⁴³ UDDI as the respective standard is still not as accepted as the other protocols, cf. QUANTZ, WICHMANN (2003), pp. 25-36.

⁴⁴ Based on the general structure of a SOAP message other information can also be included. As this level of technical detail is not relevant in the context of this paper, the simple case above is assumed.