This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Supporting A Service-Oriented Architecture
Derek T. Sanders J.A. Hamilton, Jr., Ph.D. Computer Science & Software Engineering Auburn University Auburn, Alabama 36849 email@example.com , firstname.lastname@example.org Richard A. MacDonald, Ph.D. RAM Laboratories, Inc. 10525 Vista Sorrento Pkwy San Diego California 92121 email@example.com Keywords Service-Oriented Architecture, DoDAF, MoDAF, TOGAF Abstract Service-oriented Architectures (SOA) have become increasingly popular as a way to support the business processes of an organization. A Service-Oriented Architecture approach to system design is one where application design and development are done with the goal of producing usable services. This approach allows for the integration of applications as reusable system services. The services must have platform independent specifications which abstract the underlying complexity of the service, are loosely coupled, and, perhaps most importantly, are reusable. This paper gives an in depth overview of SOA concepts, and will briefly introduce current Enterprise Architectures, such as the Department of Defense Architecture Framework (DoDAF), Ministry of Defense Architecture Framework (MoDAF), and The Open Group Architecture Framework (TOGAF), and what is being done to address the current need for SOA. 1. INTRODUCTION Service-oriented Architecture (SOA) has become an increasingly popular buzzword in industry and government operations alike. Disperse systems and distributed systems rely heavily on the operations of other nodes of a system in order to complete a collectively single task. In times past operations have been carried out by multiple tiers of systems, and now there is shift towards making the systems work together in an SOA. SOA, however, is not necessarily a new approach to software and system design, and it can be seen that the underlying concepts to SOA have been around since the 1970s.  The increasing popularity of SOA has been due to popular use of Web services, and the heterogeneity of today’s systems. However, the use of Extensible Markup Language (XML) web services is but one way to implement the ideas behind SOA. SOA does not define a specific implementation technology, but rather the architectural components and concepts to describe a specific service in a certain context. While, SOA is growing in popularity there is also a cloud of misguidance of what SOA can accomplish and what it is not for. The outline for the remainder of this paper is as follows. In section 2 there will be a comprehensive introduction to SOA, the concepts and misconceptions revolving around it, and the problems it were intended to solve. Following the SOA overview, introductions will be given for the DoDAF, MoDAF, and the TOGAF in their respective sections. 2. SERVICE-ORIENTED ARCHITECTURE Implementing an SOA is not a trivial task, and this is especially true if there is a limited understanding what constitutes a service and what exactly an SOA is designed to accomplish. Prior to divulging into the driving forces, challenges, and misconceptions of SOAs it is important to have a solid grasp on the definition of a service. 2008 SpringSim 325 1-56555-319-5 2.1 Services SOAs begin with a collection of services, and these can be generally regarded as a collection of software components which individually carry out business processes, like computing interest on a bank account. Many organizations have taken on the ask of defining what constitutes a service, such as IBM , OASIS , and OMG  to name a few, but while they may maintain their esoteric view on the definition there do exist common underlying themes. A service should have well defined platform independent interfaces with selfcontained functionality that is loosely coupled with other services. Self-containment refers to the service being able to “provide the same functionality, independently, of other services.” Loosely coupled refers to the concept of allowing the service or application using the service, to be agnostic to the underlying technical details of partner services in order to use them to their fullest functionality. In an architectural sense what this points to are the services being represented by “black boxes”, that is, we know what must go in and come out but are not concerned with how it does the translations. Requiring that the services be loosely coupled is important for the maintainability, scalability, and future upgrade paths of applications using the services. Tight coupling makes it considerably
Tight coupling Physical connections Communication style Data model Type system Interaction pattern Control of process logic Binding Platform Transactionality Deployment Point-to-point Synchronous Common complex types Strong harder for the applications to adapt with evolving requirements. This is due to the fact that without loose coupling, any changes to one service will have an additional impact on any partner service. What follows from this specification is that the service becomes a reusable system component. The table below gives a brief list several design considerations and how they might differ for loose coupling versus tight coupling: Additional details to a service which are hidden from the end user and/or partner service are the physical locations of the service. Allowing a service to be location transparent adds additional flexibility to the SOA. Furthermore, just like the services should be platform independent, the service should also be protocol independent. This means that “messages are sent in a platformneutral, standardized format delivered through the service specification.” A final note about services is with regard to the traditionally held view that services should only support business processes. It is true that SOA came out with the intention to help support business processes. However, this is not the only area in which SOA concepts can be applied. One area in which there has been considerable use of SOA concepts is with regard to infrastructure services. The paper
Loose coupling Via mediator Asynchronous Simple common types only Weak Data-centric, self-contained message Distributed control Dynamically Platform independent Compensation At different times Implicit upgrades Navigate through complex object trees Central control Statically Strong platform dependencies 2PC (two-phase commit) Simultaneous Explicit Upgrades Versioning Table 1 Possible forms of loose coupling in SOA  1-56555-319-5 326 2008 SpringSim in  gives an example using the Open Grid Services Architecture (OGSA) that defines services for things like data transfer and computation scheduling collaboration mechanisms. This is an example of a distributed system taking advantage of SOA. In conclusion not every service used to support a business process directly implements a business theme. Any component which demonstrates reusable functionality in varying applications can be a candidate for a service. 2.2 SOA Goals At its core SOA is essentially a distributed architecture with a design focus on services, and the services are designed to support business processes, but as mentioned earlier there is an exception to this rule. The business processes get “mapped to a systems architecture description with specific applications that support the process cast[ed] as services.” The translation from a set of independent, but collaborative services, to the completion of a business process is what makes SOA such an attractive venture for most businesses. The previously described definition of a service with their physical and protocol agnostic viewpoints makes them ideal for businesses to use what are in essence commercial-off-the-shelf (COTS) services. However, there are some things which should be noted about SOA before a business decides it wishes to support an SOA. According to Michael Stal  there are five driving forces which need to be balanced for any serviceoriented software system. • Distribution: Systems are made up of various software components running on different networks using varying communication protocols. Heterogeneity: The distributed software components reside in remote heterogeneous (differing from another) environments, and developers have no • • • control over their implementation details. Dynamics: The environments are dynamic so there can be no a priori decision made, rather components must be configured at runtime. Transparency: As mentioned previously, services should be protocol independent, allowing for transparency among providers and consumers. Process-orientation: “Services often implement fine-grained functionality, while clients need to compose services that result in more coarse-grained building blocks. So, it’s essential to compose multiple services for coordinated workflows.” Balancing these forces result in an optimal and loosely coupled system.  According to  there are essentially three primary functions of a SOA: 1. Describe and Publish service 2. Discover a service 3. Consume/interact with a service Figure 1 Sample SOA Setup  • The above image is a trivial sample of a SOA framework. Enterprises A and B each have a consumer service (B and C) and a provider service (A and D). There exists a registry from which the different organizations, or as shown 2008 SpringSim 327 1-56555-319-5 in figure 1, enterprises, can lookup service details in order to use them. This is represented by the Universal Description, Discovery Infrastructure (UDDI) which is a generally accepted standard for SOA.  The information exchange between the enterprises and the service registry are done with the Web Service Description Language (WSDL). Finally, the messages between the services are exchange using the Simple Object Access Protocol (SOAP). This is but one example of an SOA and these protocols and standards used are not the same across all organizations’ architectures. 2.2 Roadblocks In addition to considering how to balance those forces, there are often misled ideas, mainly from software marketers, about what SOA can accomplish and what it exactly is. Lewis et al.  provide a non-comprehensive list of some of these misconceptions. Briefly there are a few that will be highlighted in this section. 2.2.1 Misconceptions One of the first misconceptions held is that SOA describes a complete architecture. This however is far from the truth. “In reality, SOA is not an architecture, but an architectural design pattern from which an infinite number of architectures can be derived.”  The pattern that a SOA describes merely provides the architect with guidance on how to best implement design practices. Furthermore, SOA “defines a set of element types, a topological layout of the elements that show their relationships, semantic constraints on elements, and interaction mechanisms.”  Any organization wishing the leverage the advantages of SOA will be doing just that, they should and can not use it to describe the completeness their system. For this purpose SOA is best suited to be teamed with an architecture framework like the DoDAF to describe a complete system. An additional area in which organizations look to SOA to solve their problems is with regard to legacy systems. This is indeed a very attractive promise for a company wishing to expand their system. Many organizations use legacy components in their systems, and this might hinder their ability to move forward in the technological revolution. However, it is not optimal for these organizations to simply start over, so they look to SOA as a solution for reusing their previously built, and probably comprehensively tested, legacy systems, an example being the U.S. Government. Something to consider is that the migration of legacy systems is not a trivial task. This is because legacy systems are not easily transposed as a service without some rework. Before jumping onto the bandwagon some analysis must be done on the legacy system to determine its feasibility as a service. Lewis et al.  recommend asking these questions prior to trying to incorporate a legacy system versus simply replacing it with a new code base and service. 1. Is it technically feasible to create a service from the legacy system or part of the system? 2. How much would it cost to expose the legacy system as services? 3. Is this cost, plus the cost of maintaining the existing legacy system, more than the cost of replacing the legacy system with a new one? 4. What changes will have to be made to the legacy system in order to use these services? 5. How much will these changes affect the current end users of the legacy 1-56555-319-5 328 2008 SpringSim and other dependent production systems? Answering these questions will help assess how to move forward with the usability of a legacy system in an SOA. One final area that Lewis et al.  point out that is a common misconception is the ability to rapidly develop and implement an SOA. Applications that use the services require a different approach to testing, verification and validation then those used in a traditional system. One obvious problem is that testing for an SOA must occur at runtime and in real-time. However, much like traditional testing the service providers need to exhaustively test their systems for stress and load testing.  In addition to the problems with developing and testing applications in an SOA environment, there exists the problem of implementing an SOA. “Moving to a service-oriented computing environment is a continuous and evolving process… An enterprise needs to understand and identify the benefits of SOA in its business context and then tailor the SOA environment in order to best suit its needs.”  2.2.2 Challenges In the previous section commonly misled held views of SOA were brought to light and shown to the reader. In this section the goal is to provide challenges that are present in SOA, and there is however some overlap. One of the misconceptions was that it was easy to develop applications for a SOA, and this is in turn a challenge. As previously stated testing for both a service provider and a service customer is challenging and time consuming. However, a challenge which creeps into any environment which is revolved around net-centric computing is security. 188.8.131.52 Security Figure 2 Security Triad Securing an open architecture, like an SOA, can prove to be much more difficult than securing a closed system in traditional software development. SOA security can however leverage the advancement made in net-centric computing security. Like net-centric applications, the heterogeneity of SOA presents a problem from a security standpoint, and security also could prove to be problematic for an SOA. SOAs are based on high interoperability between the varying “software islands”, and there exists the potential for a communication path issue with these heterogeneous systems and their security mechanisms. SOAs require a fine balance in this respect and there exist varying views on the security requirements for an SOA.     For brevity sake the security requirements given by  will be discussed as they appear to be the most comprehensive while being agnostic to a specific SOA ideology. In addition to the traditional security triad show in Figure 2, the author lists several other areas specific to SOA. Collectively these are: • • • • • Authentication Authorization Confidentiality Integrity Availability 2008 SpringSim 329 1-56555-319-5 • • Accounting Auditing can use standard protocols, such as Web services.”  And this leads to reduced development costs 2.4 SOA Conclusions This section provided a comprehensive coverage of SOA concepts including their roadblocks, and their advantages. However, there still exists the need to be able to use SOA in a complete architecture, and the next section will address this problem. 3. SOA FRAMEWORKS SOA as mentioned earlier is not a complete system view and alone is not sufficient for the description of an entire system’s architecture. While it is possible to use SOA by itself for describing just the services and their interaction, this would be inefficient for a system as a whole. This is why it is important to understand how SOA is supported in some of the more familiar architecture frameworks. As of writing this paper there are several frameworks which have widespread awareness in the software architecture community. The first is the DoDAF followed by a close cousin the MoDAF, and the TOGAF. 3.1 DoDAF The DoDAF was developed specifically to “provide guidance for describing architectures for both warfighting operations and business operations and processes.”  DoDAF grew from the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework Version 2.0. It provides four views in order “to specify processes for scope definition, data requirements definition, data collection, architecture objectives analysis and documentation.”  Of these the only unfamiliar to a security analyst might be “Accounting” which appears to be a business oriented security requirement, though in its purest sense it is the relation of resources and keeping them accountable. This should not be confused with auditing which merely maintains a historic record of the accounting. Furthermore, availability is a crucial aspect to the balance of SOA and security, as there security mechanisms should not hinder the availability of the services and their resources. 2.3 SOA Advantages Up until this point SOA has appeared to be not as appealing as once thought, but it was necessary for a minimal set of roadblocks to be presented in order to cast SOA into the proper light. SOA is a rapidly increasing business venture for a reason. The first advantage is that an “operational process orchestrates simple services into complex services” , that is to say that SOA allows the collection of individual services to cooperate to complete a complex process. The next advantage is that the services allow for communications to exist between “different computers, from different vendors, and different programs, from different functional areas”.  Furthermore, as mentioned earlier in this paper SOA allows for the “globalization and the integration of geographically dispersed organizations through service orchestration of distributed services owned and executed across ownership boundaries.”  While there is a misconception that applications can be developed quickly, it should most certainly be seen as an advantage to reuse the services of another organization. This reuse does increase product development but only because “developers don’t have to spend an inordinate amount of time writing new lines of code to connect applications. Instead, they 1-56555-319-5 330 2008 SpringSim • • • • All Views – “overview, summary and integrated dictionary of the architectures”  Operational Views – “describe the business and operation of the architecture…the operations nodes, node connectivity, information exchange, organization relationship, operation rules, event-trace and logical data model”  System Views – “describe the system and its components”  Technical Views – “describe the current standard profile and future technical standards forecast.”  1.0 would be fully compliant in its ability to support an SOA. 3.2 MoDAF The MoDAF is the Ministry Of Defense’s Architectural Framework which is based upon DoDAF Version 1.0. The similarities between the DoDAF, MoDAF and how they relate to the TOGAF are considered in detail in . According to the MoDAF website  the driving forces for the need to expand the DoDAF are:
• Using the DoDAF for SOA is worthy consideration since doing so would leverage “the existing body of knowledge and architecture products within DoD.”  Tailoring the DoDAF for SOA allows the “architects to more effectively describe SOA as an alignment of services to operational activities and to identify common functionality as a set of re-usable services.”  The authors in  describe how the DoDAF should be tailored to support SOA. They accomplish by introducing new elements and relationships, and by modifying the composition of elements and relationships of other products. Briefly, the new elements introduced are Port, Service Specification, and a Service Requirement Contract. They mention that the Operational Views would not need to be modified, but that the System Views would need to be tailored to support the introduction of the new elements and relationships. For the sake of brevity their solution in its entirety will not be discussed, and it is recommended for those considering DoDAF to do a perusing of the paper presented in . With the modifications presented in  it is the author’s impression that the DoDAF Version • • • • • • The need to model incremental acquisition programmes as these represent an increasingly common form of defence procurement The need to model transformational programmes and their interdependencies The need to model capabilities as the outcome from force development and capability integration programmes The need to model solution resources in terms of people as well as technical system resources The need to model physical attributes and capabilities and, by extension, flows of personnel, energy and materiel not just information The need to integrate programme models into traditional architecture models in order to meet the needs of enterprise architects A drive towards a more coherent object oriented underpinning for the Architectural Framework. Due to the extreme similarities, and the minor differences, the MoDAF will not be discussed in detail, and it is worth reading the information located in  for the comprehensive list of differences, and the 2008 SpringSim 331 1-56555-319-5 reasons for the differences. Much to no surprise SOA is not directly supported by the MoDAF, as it was in the DoDAF. Like the TOGAF discussed below, there is an undertaking to allow the ability of SOA representation in the MoDAF. The paper located  discusses how the MoDAF could support SOA concepts in the form of a NATO SOA extension to the MoDAF. Since this paper was written as in introduction to SOA, their changes will not be listed and it is recommended that  be read for an in depth analysis. 3.3 TOGAF Like the DoDAF and MODAF, the TOGAF is an enterprise architecture which is considered an industry standard framework.  The TOGAF consists mainly of three parts: (1) Architecture Development Model (ADM), (2) Enterprise Continuum, and (3) a Resource Base. The ADM is the key to the TOGAF in that it is “a reliable, proven approach for developing enterprise architecture descriptions that meets the needs of the specific business.”  This is an important part that differs the TOGAF from the DoDAF/MoDAF since the others were meant to support defense operations an can become domain specific. The Enterprise Continuum is a “virtual repository of all architectural assets that include models, patterns, and architecture descriptions.”  Additionally, it also specifies a Technical Reference Model (TRM) “that represents a system in terms of Application, Application Platform and Communication Infrastructure and their inter-connectivity.”  Finally, the Resource Base is a collection of resources, templates, and background information that enable an architect to use the TOGAF. SOA support in the TOGAF is feasible, but not unlike the DoDAF it requires adjustments in order to be fully supported. At this time there is a group  undertaking the task of presenting a practical guide  for merging SOA and TOGAF, and it would be beneficial to review the guide prior to considering TOGAF for SOA implementation. Conclusion SOA is a very promising move forward in systems design and representation. Not only does it allow for the use of disperse systems and their services, but it allows for both business and data processes to be completed in a distributed manner. There are many things to consider when deciding whether SOA is an appropriate approach to solving an organizations problem. This paper covered the roadblocks and the advantages to SOA, and gave an introduction to several popular enterprise architectures. Based on the reading of the supplicant articles to these separate frameworks it is this author’s conclusion that the DoDAF would be more suited for the task. However, there are other frameworks that were left unconsidered, most notable is the Service Oriented Architecture Framework (SOAF) presented in . If SOA has the proper environment and people to work with it, then it can be an exceedingly useful business asset. When it is used properly SOA can bring the different groups of an organization together to provide a powerful system. The benefits in most cases far exceed the initial negatives. Biography Derek Sanders graduated from Auburn University, Auburn, AL with a Bachelors of Wireless Engineering and currently is a graduate student with Auburn University pursuing a Master’s in Software Engineering with a concentration in information assurance. Currently a research assistant and a member of the Information Assurance Center’s Information Assurance Lab, his research interests include 1-56555-319-5 332 2008 SpringSim obfuscation, anti-tamper protection mechanisms, wireless security mechanisms, and co-processor secure execution environments. His work is currently being funded by RAM Laboratories. John A. "Drew" Hamilton, Jr., Ph.D., is an associate professor of computer science and software engineering at Auburn University and director of Auburn's Information Assurance Center. He has a B.A. in Journalism from Texas Tech University, an M.S. in Systems Management from the University of Southern California, an M.S. in Computer Science from Vanderbilt University and a Ph.D. in Computer Science from Texas A&M University. He is currently President of the Society for Modeling and Simulation, International. Richard A. MacDonald, Ph.D. co-founded RAM Laboratories, Inc. in 1997 and has been serving in the capacity of President and Chief Executive Officer since the company’s inception. With twenty years experience in high technology and defense businesses, Dr. MacDonald has overseen the strategic planning and growth of RAM Laboratories into a recognized defense technology leader with a national customer base spanning coast-to-coast, supporting multiple branches of the Department of Defense including the Army, Navy, Air Force, Coast Guard and the Department of Homeland Security. Dr. MacDonald earned both a Ph.D. and Masters of Science (M.S.) in Electrical Engineering from the University of Virginia, and a Bachelor of Science (B.S.) degree in Computer Engineering from the University of Michigan References eed_to_Know_About_Service_Oriented_Archit ecture, November 2007. M. Endrei, J Ang, A Arsanjani, S. Chua, P. Comte, P. Krogdahl, M. Luo, T. Newling. 2004. Patterns: Service-Oriented Architectures and Web Services. IBM RedBooks, IBM 2004, http://publibb.boulder.ibm.com/Redbooks.nsf/RedbookAbstr acts/sg246303.html?Open, November 2007 3 Organization for the Advancement of Structured Information Standards (OASIS). 2006. Service Oriented Architecture (SOA) Reference Model Public Review Draft 1.0 (Feb), http://www.oasisopen.org/committees/download.php/16587/wdsoa-cd1ED.pdf, November 2007 4 Open Management Group. SOA SIG. http://SOA.omg.org, November 2007 5 Thanh, D.v. and Jorstad, I. 2005. A Serviceoriented Architecture Framework for Mobile Services. In the Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/E-Learning on Telecommunications Workshop. IEEE, Piscataway, N.J., 65 – 70. 6 Dandashi, F. and Ang, H.W. 2006. Tailoring DoDAF For Service Oriented Arhitectures: A Recommended Guide. Military Communications Conference (Oct. 23 – 45). IEEE, Piscataway, N.J., 1 – 8. 7 Josuttis, M.N.; 2007. SOA In Practice The Art of Distributed Syste, Design. O’Reilly Media, Inc., Sebastopol, CA. 8 Lewis, G.A., Morris, E., Simanta, S. and Wrage, L. 2007. Common Misconceptions About Service-Oriented Architectures. Sixth International IEEE Conference on Commercialoff-the-shelf (COTS)-Based Software Systems (Feb. 26 – Mar. 2). IEEE, Piscataway, N.J., 123 – 130. 9 Stal, M. 2006. Using Architectural Patterns and Blueprints for Service-Oriented
2 Datz, T. 2004. What You Need to Know About Service-Oriented Architectures. http://www.cio.com/article/32060/What_You_N
1 2008 SpringSim 333 1-56555-319-5 Architecture. IEEE Software 23, no. 2 (Mar. – Apr.): 54~61. 10 Liegel, P. 2007. The strategic impact of service oriented architectures. In the Proceedingsof the 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (Mar. 26 – 29). IEEE, Piscataway, N.J., 475 – 484. 11 Hinton, H., Hondo, M. and Hutchison, B. 2006. Security Patterns within a ServiceOriented Architecture. http://searchwebservices.techtarget.com/search WebServices/downloads/SecuritySOA_(2).pdf, November 2007. 12 Cotroneo, D., Graziano, A. and Russo, S. 2004. Security Requirements in Service Oriented Architectures for Ubiquitous Computing. In the Proceedings of the 2nd workshop on Middlware for pervasive and adhoc computing (Toronto, Ontario, Canada, Oct.). ACM Press, New York, N.Y., 172 – 177. 13 Durbeck, S., Schillinger, R. and Kolter, J. 2007. Security Requirements for a Semantic Service-oriented Architecture. Second International Conference on Availability, Reliability, and Security (Vienna, Apr. 10 – 13). IEEE, Piscataway, N.J., 366 – 373. 14 DoD Architecture Framework Working Group. 2004. DoD Architecture Framework Version 1.0 – Volume I: Definitions and Guidelines, http://www.tricare.mil/jmis/download/DoDArch itectureFrameworkVersion1Feb2004.pdf, November 2007 15 Chen, P., Han, J. and Tang, A. 2004. A Comparative Analysis of Architecture Frameworks. In the Proceedings of the 11th Asia-Pacific Software Engineering Conference (Nov. 30 - Dec. 3). IEEE, Piscataway, N.J., 640 – 647. 16 MODAF. http://www.hiq.co.uk/modaf_togaf_mapping/, November 2007 MODAF. http://www.modaf.org.uk/3Modelling/56/howdoes-modaf-relate-to-dodaf, November 2007 18 MODAF. MODAF AND SERVICE ORIENTED ARCHITECTURE. http://www.modaf.org.uk/files/SOAarticle2.doc, November 2007 19 Leist, S. and Zellner, G. 2006. Evaluation of Current Architecture Frameworks. In Proceedings of the 2006 ACM symposium on Applied computing (Dijon, France). ACM, New York, N.Y., 1546 – 1553. 20 http://www.opengroup.org/projects/soatogaf/, November 2007 21 TOGAF. http://www.opengroup.org/projects/soa/uploads/ 40/11475/Practical_Guide_to_SOA_Project_v1. 2.doc, November 2007 22 Anand, S., Erradi, A. and Kulkarni, N. 2006. SOAF: An Architectural Framework for Service Definition and Realization. IEEE International Conference on Services Computing (Sept.). IEEE, Piscataway, N.J., 151 – 158. 17 1-56555-319-5 334 2008 SpringSim ...
View Full Document
- Spring '10
- Software engineering