Service Oriented Architecture Concepts

User Generated

wjsn

Business Finance

Description

Unit 3 Completed

Service Design

1.) Choose four of the primary design principles of SOA and explain how they differ from the goals of traditional software development.

2.) Identify the stage of service oriented design that most affects the granularity of the services that compose the software solution. Explain your rationale and use research and your own experience to justify your argument.

3.) Using a simple business problem as an example, identify and explain the characteristics of the software solution that would be favored with top-down design. How would these characteristics be different if the design methodology used the bottom-up approach instead? Explain which of these approaches would make the most sense for the chosen business problem. Explain which choice would make the most sense for the overall organization creating the solution.

4.) Choose two types of granularity (from service, capability, or data) and analyze how each one would affect the reusability of a service if it was coarse or fine grained.

Requirements:

Learner successfully applied critical thinking to the case study analysis &

recommendations/actions taken - 25 pts max.

- Learner successfully incorporates a minimum of three scholarly sources in every essay

question to support their position. (No more than 10% of the entire submission should be

from referenced sources. In other words, the references should support the learner’s work

not be the bulk of what is written.) - 25 pts max.

- Learner met the criteria for academic writing (i.e. no spelling or grammar errors, properly

formatted paragraphs, APA formatting used for references, etc.) - 15 pts max.

- Learner met the minimum 300 words per question- 10 pts max.

- please separate the answers like how the questions are provided

Unformatted Attachment Preview

06_0132344823_05.qxd 6/13/07 4:44 PM Page 103 Chapter 5 W I L S O N , J A M I E Understanding Design Principles 5.1 Using Design Principles 5 0 Design Pattern References 5 Principles that Implement vs.1Principles that Regulate B Principles and Service Implementation Mediums U Principles and Design Granularity 5.2 Principle Profiles 5.3 5.4 5.5 5.6 5.7 Case Study Background SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 104 P rinciples help shape every aspect of our world. We navigate ourselves through various situations and environments, guided by principles we learned from our family, society, and from our own experiences. Historically, many parts of the IT world encourW aged the use of design principles so that when you did something, you would “do it I use was optional or just recommended. right” on a consistent basis. Often, though, their They were viewed more as guidelines than standards, providing advice that we could L choose to follow. S When moving toward a service-oriented architecture, principles take on renewed O importance primarily because the stakes are higher. Instead of concentrating on the N delivery of individual application environments, we usually have a grand scheme in , A “do it right the first time” attitude has mind that involves a good part of the enterprise. therefore never been more appropriate. SOA projects have the potential to shape and position solution logic in ways that can significantly transform an enterprise. We want J to make sure we steer this transformation effort in the right direction. A As documented in Chapter 4, the design principles M explored in this book establish a paradigm with many roots in previous computing generations. None of them are really that I new. What is distinct about service-orientation is which of these existing principles have E been included and excluded—that and the high-minded goals promised by its successful application. 5 0 5.1 Using Design Principles The Design Fundamentals section of Chapter 35formally defined the term “design princi1 ple” and determined that it essentially is “a recommended guideline for shaping solution logic with certain goals in mind.” We subsequently covered the following list of B service-oriented computing benefits: U • Increased Intrinsic Interoperability • Increased Federation • Increased Vendor Diversification Options • Increased Business and Technology Domain Alignment SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 105 105 5.1 Using Design Principles • Increased ROI • Increased Organizational Agility • Reduced IT Burden These benefits represent the most common strategic goals associated with serviceorientation. The application of the eight principles explored in this book results in the realization of very specific design characteristics, all of which support these goals. W We therefore need to ensure that the principles are effectively applied. Following is a set I of best practices for getting the most out of the design principles in this book. L S Incorporate Principles within Service-Oriented Analysis O Because we have labeled the principles in this book as design principles, there is a natuN during the design stage only. However, ral tendency to focus on their application because of the unique form of analysis carried , out as part of the common SOA delivery lifecycle, it can be highly beneficial to begin working with a subset of the principles during the analysis phase. J While iterating through the service modeling process of a typical service-oriented analyA sis, we are tasked with defining a conceptual blueprint for the inventory of services we M This provides us with an opportunity to will eventually be designing and building. I service design characteristics ahead of time. begin conceptually forming some of the key E Of the eight service-orientation design principles, the following three are most commonly incorporated within the service modeling process: 5 • Service Reusability—Reusability considerations are highly relevant to defining the inventory blueprint because they help0 us group logic within the contexts of proposed agnostic service candidates and5further encourage us to refine the definition and functionality behind agnostic capability candidates. 1 • Service Autonomy—One of the goals of the information gathering steps that comB prise the parent service-oriented analysis process is to determine where, within an U enterprise, autonomy will ultimately be impacted. Knowing this in advance allows us to adjust service candidate granularity and capability candidate grouping in response to practical concerns. This prevents the inventory blueprint from becoming too abstract and out of touch with the realities of its eventual implementation. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 106 6/13/07 4:44 PM Page 106 Chapter 5: Understanding Design Principles • Service Discoverability—Although service meta data can be added to a contract at any time prior to deployment, the analysis stage enables us to leverage the expertise of subject matter experts that will not be participating in subsequent project phases. This is particularly relevant to the definition of business services. Analysts with a deep insight into the history, purpose, and potential utilization of business logic can provide quality descriptions that go far beyond the definition of the candidate service contract. W As illustrated in Appendix B, a separate step dedicated to applying select serviceI modeling process. orientation principles is part of a standard service L FOR EXAMPLE S O expanded variation of the service A US-based shipping company created their own modeling process documented in Appendix B.N Instead of bundling service-orientation considerations into one step, it included the following separate steps: , • Business Reusability Survey—A step during which representatives from different business domains were questioned as to the applicability of a given service that was J to provide feedback about how any being modeled. Those surveyed were asked agnostic service could be potentially extended A in support of business processes that resided in their domains. M I required to encapsulate functionality that resided in an existing COTS environment. It E provided insight into potential autonomy constraints for some of the planned services. • COTS Evaluation—This was carried out for each service capability candidate • Service Profile Copyedit—This was a step toward the end of the modeling process during which the service profile document5was refined by one of the on-staff technical writers (which is also a best practice discussed in Chapter 12). 0 Each of these steps was carried out by different 5 individuals, all part of the service modeling project team. 1 B Incorporate Principles within Formal Design U Processes The key success factor to leveraging service-orientation design principles is in ensuring that they are applied consistently. When services are delivered as part of different projects that are perhaps even carried out in different geographical locations, there is a constant danger that the resulting service inventories will be comprised of incompatible and misaligned services, varying in both quality and completeness. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 107 107 5.1 Using Design Principles Design synchronicity is important to achieving the harmonization and predictability required to ultimately compose services into different configurations. Establishing formal service design processes that exist as part of the organization’s over-arching project delivery methodology requires that project teams give serious thought as to how each principle can or should be applied to their planned services. The design processes listed in Appendix B have steps dedicated to applying serviceorientation principles. These processes can be further customized and expanded to W incorporate a dedicated step for each principle. I L FOR EXAMPLE S The aforementioned shipping company formalized service design processes that included separate steps for applying Service OReusability, Service Autonomy, and Service Composability principles. The remaining principles were also incorporated in the design N processes but grouped together with other design considerations. , The Service Composability step actually introduced a sub-process during which service contracts were combined into a variety of composition configurations in order to assess J data exchange compatibility. A Establish Supporting Design StandardsM I Design principles are design guidelines, essentially recommended approaches to designing software programs. Due to the E importance of creating consistent programs (services) in support of service-oriented computing, it is highly recommended that design principles take on a larger, more prominent role. 5 Once an organization has determined to what 0 extent it wants to realize service-orientation, design standards need to be put in place in full support of the consistent applica5 tion of these design principles. This often leads to the principles themselves forming the 1 basis for multiple design standards. B Either way, if you are expecting to attain meaningful strategic benefit from a transition toward SOA, design standards need to beU in place to ensure the consistent realization and proliferation of service-orientation across all affected services. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 108 108 Chapter 5: Understanding Design Principles FOR EXAMPLE An enterprise design specification for a government agency contained upwards of 300 separate design standards, many of which were directly or indirectly defined in support of service-orientation. One of these standards, for example, required that all XML schema definitions support null values by allowing an element to exist zero or more times (via the minOccurs="0" attribute setting). If the element was not present, Wits value was considered to be null. This simple design standard ensured that null Ivalues were consistently expressed across all XML document instances, thereby supporting the Service Contract Standardization L and Service Reusability principles and also avoiding some of the negative coupling S types described in Chapter 7. Apply Principles to a Feasible Extent O N , Each of the eight service-orientation design principles can be applied to a certain extent. It is rare that any one principle will be fully and purely realized to its maximum potential. A fundamental goal when applying anyJprinciple is to implement desired, corresponding design characteristics consistently within A each service to whatever measure is realistically attainable. M The fact that principles are always implemented I to some extent is something we need to constantly keep in the back of our minds as we are working with them. For example, it’s E not a matter of whether a service is or is not reusable; it’s the degree of reusability that we can realize through its design that we are primarily concerned with. 5 Most of the chapters in this book explore specific measures to which a principle can be 0for how these levels can be classified and applied and further provide recommendations documented. Additional supporting practices5are provided in Chapter 15. • 1 SUMMARY OF KEY B POINTS Design principles can be effectively realized U by applying them as part of formal analysis and design processes. • Design principles can be further applied consistently by incorporating them into official design standards. • Every principle can be applied to a certain extent. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 109 109 5.2 Principle Profiles 5.2 Principle Profiles Each of the chapters in Part II contains a section that summarizes a design principle within a standard profile table. Provided here are brief descriptions of the fields within the standard profile table: • Short Definition—A concise, single-statement definition that establishes the fundamental purpose of the principle. Wthe principle that provides more detail as • Long Definition—A longer description of to what it is intended to accomplish. I L are expected from the application of • Goals—A list of specific design goals that the principle. Essentially, this list provides S the ultimate results of the principle’s realization. O • Design Characteristics—A list of specificNdesign characteristics that can be realized via the application of the principle. This provides some insight as to how the prin, ciple ends up shaping the service. • Implementation Requirements—A list of common prerequisites for effectively applyJ ing the design principle. These can range from technology to organizational A requirements. M • Web Service Region of Influence—A simple diagram that highlights the regions I affected by the application of the princiwithin a physical Web service architecture ple. The standard Web service representation (consisting of core service logic, mesE saging logic, and the service contract) is used repeatedly. Red shaded spheres indicate the areas of the Web service the principle is most likely to affect. The 5 darker the shading, the stronger the potential influence. 0 5 Abstract—An introductory section that explains each design principle outside of 1 the context of SOA. This is a helpful perspective in understanding how serviceorientation positions design principles.BThe title of this section incorporates the U Name] in Abstract. name of the principle as follows: [Principle Chapters are further supplemented with the following sections: • • Origins—A section that establishes the roots of a given principle by drawing from past architectures and design approaches. By understanding the history of each design principle, it becomes clear how service-orientation is truly an evolutionary paradigm. The format of this section’s title is as follows: Origins of [Principle Name]. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 110 6/13/07 4:44 PM Page 110 Chapter 5: Understanding Design Principles • Levels—As explained earlier in the Apply Principles to a Feasible Extent section, each principle can be realized to a certain degree. Most chapters provide suggested labels for categorizing the level to which a principle has been applied, primarily for measuring and communication purposes. The section title is structured as follows: Levels of [Principle Name]. • Service Design—Several chapters explore supplementary topics that highlight additional design considerations associated with a principle. These are found in a secW tion called [Principle Name] and Service Design. (Note that the following Service Models and Relationships sections exist as Isub-sections to the Service Design section.) L • Granularity—Whenever the application of a design principle raises issues or concerns regarding any of the four designSgranularity types (as explained in the upcoming Principles and Design Granularity Osection) a separate section entitled [Principle Name] and Granularity is added.N • Service Models—Where appropriate, a principle’s influence on the design of each of , the four primary service models (entity, utility, task, and orchestrated task) is described in a section titled [Principle Name] and Service Models. J • Relationships—To fully appreciate the dynamics behind service-orientation, an A understanding of how the application of one principle can potentially affect others M titled How [Principle Name] Affects is required. Each chapter provides a section I Other Principles wherein inter-principle relationships are explored. Ea design principle concludes with a list • Risks—Finally, every chapter dedicated to of risks associated with using or abstaining from the use of the principle. This list is provided in a section titled Risks Associated 5 with [Principle Name]. Every effort was made to keep the format of0the next eight chapters consistent so that aspects of individual principles can be effectively compared and contrasted. 5 1 NOTE B Principle profiles should not be confused with service profiles. The former represents a regular section format within U the upcoming chapters, whereas the latter is a type of document for recording service meta details. Service profiles are described in Chapter 15. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 111 5.4 Principles that Implement vs. Principles that Regulate 111 SUMMARY OF KEY POINTS • Each chapter summarizes a design principle using a standard profile section. • Design principles are further documented with additional sections that explore various aspects of their origin and application. W I documented in alignment with an SOA The eight design principles in this book were design pattern catalog published separately L in the book SOA: Design Patterns, another title that is part of the Prentice Hall Service-Oriented Computing Series from Thomas Erl. This S book expresses service-orientation through a fundamental pattern language and proO for solving common problems. vides a collection of advanced design patterns N Because these two books were written together, there is a strong correlation between the , utilization of design principles and select design patterns that provide related solutions 5.3 Design Pattern References in support of realizing service-orientation. Fundamental design patterns are often tied directly to the design characteristics established by a particular design principle, J whereas advanced design patterns more commonly solve problems that can be encounA tered when attempting to apply a principle under certain circumstances. M Throughout the chapters in Part II, references to related design patterns are provided. I These references are further summarized in Appendix C. E 5.4 Principles that Implement vs. Principles that Regulate 5 Before exploring the design principles individually, it is worth positioning them as they 0 relate to the realization of physical service design characteristics. On a fundamental level 5 we can group principles into two broad categories: 1 • Principles that primarily result in the implementation of specific service design B characteristics. U the application of other principles. • Principles that primarily shape and regulate The following principles fall into the first category: • Standardized Service Contract • Service Reusability SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM 112 Page 112 Chapter 5: Understanding Design Principles • Service Autonomy • Service Statelessness • Service Discoverability As explained throughout Chapters 6, 9, 10, 11, and 12, the application of any one of these principles results in very specific design qualities. Some affect the service contract, while others are more focused on the underlying service logic. However, all result in the W physical service design. implementation of characteristics that shape the I L • Service Loose Coupling S • Service Abstraction O • Service Composability N After studying Chapters 7, 8, and 13, it becomes evident that while these principles , This leaves us with the remaining three that fall into the “regulatory” category: also introduce some new characteristics, they primarily influence how and to what extent the service design characteristics associated with other principles are impleJ mented (Figure 5.1). A M I E 5 0 5 1 B U SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 113 5.4 Principles that Implement vs. Principles that Regulate 113 W I L S O N , J A M I E Figure 5.1 While the principles on the right-hand side want to add specific physical characteristics to the service design, the principles on the left act as regulators to ensure that these characteristics are implemented in a coordinated and appropriate manner. 5 0 5 Furthermore, each chapter explores how principles inter-relate. Specifically, the manner in which a design principle affects the application of others is documented. Figure 5.2, 1 for example, provides an indication as to how two of the “regulatory” principles relate B to each other. U SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 114 4:44 PM Page 114 Chapter 5: Understanding Design Principles • W I L Figure 5.2 S principles share a common dynamic in The Service Loose Coupling and Service Abstraction that the application of each supports the other. O N POINTS SUMMARY OF KEY , concrete service design Five of the eight design principles establish characteristics. • The remaining three design principles also J introduce design characteristics but act more as regulatory influences. 5.5 A M I Principles and Service Implementation Mediums E Service logic can exist in different forms. It can be implemented as the core logic component within a Web service, as a standalone component with a public interface, or even 5 of implementation medium or format within an event-driven service agent. The choice can be influenced by environmental constraints, 0 architectural considerations, as well as the application of various design patterns. 5 Service-orientation design principles shape 1 both service logic and service contracts. There is an emphasis on the Web service medium because it provides the most potential B to apply key principles to the greatest extent. For example, contract-related principles U may not apply as much to logic encapsulated within an event-driven service agent. This does not make the logic any less service-oriented; it only limits the principles that need to be taken into account during its development. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 115 115 5.6 Principles and Design Granularity “Capability” vs. “Operation” vs. “Method” To support the on-going distinction between a service in abstract and a service implemented as a Web service, separate terms are used to refer to the functions a service can provide. A service capability represents a specific function of a service through which the service can be invoked. As a result, service capabilities are expressed within the service contract. A service can have capabilities regardless of Whow it is implemented. A service operation specifically refers to a capability within a service that is implemented I as a Web service. Similarly, a service methodLrepresents a capability that is part of a service that exists as a component. S Note that as mentioned early on in Chapter 3, when the term “capability” is used in this O book, it implicitly refers to capabilities expressed by the service contract. If there is a N need to reference internal service capabilities that are not part of the contract, they will , be explicitly qualified as such. J 5.6 Principles and Design Granularity A The term “granularity” is most commonly used to communicate the level of (or absence M program design. Within the context of of) detail associated with some aspect of software service design, we are primarily concerned I with the granularity of the service contract and what it represents. E Within a service, different forms of granularity exist, all of which can be impacted by how service-orientation design principles are applied. The following sections document four 5 specific types of design granularity, three of which are further referenced in Figure 5.3. 0 5 1 B U SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 116 4:44 PM Page 116 Chapter 5: Understanding Design Principles W I L S O Figure 5.3 In this example, an Invoice entity service will tendNto have a coarse-grained functional scope. However, it is exposing both coarse-grained (Get), and fine-grained (GetHeader) capabilities. Furthermore, because the GetHeader capability will return less data than the Get capability (which returns an entire invoice document), the GetHeader capability’s data granularity is also considered fine. J A Service Granularity M as determined by its functional context, The granularity of the service’s functional scope, is simply referred to as service granularity. A service’s I overall granularity does not reflect the amount of logic it currently encapsulates but instead the quantity of potential logic it could E encapsulate, based on its context. A coarse-grained service, for example, would have a broad functional context, regardless of whether it initially expresses one or ten capabilities. 5 0 Capability Granularity 5 scope of a specific capability as it curCapability granularity represents the functional rently exists. As a rule of thumb, a fine-grained 1 capability will have less work to do than a coarse-grained one. B U Data Granularity The quantity of data a capability needs to exchange in order to carry out its function represents its level of data granularity. There has been a tendency for services implemented as Web services to exchange document-centric messages—messages containing entire information sets or business documents. Because the quantity of data is larger, this would be classified as coarse-grained data granularity. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 6/13/07 4:44 PM Page 117 117 5.6 Principles and Design Granularity Document-centric messages are in sharp contrast to traditional RPC-style communication, which typically relies on the exchange of smaller (fine-grained) amounts of parameter data. Constraint Granularity The amount of detail with which a particular constraint is expressed is referred to as a measure of constraint granularity. The schema W or data model representing the structure of the information being exchanged by a capability can define a series of specific valiI dation constraints (data type, data length, data format, allowed values, etc.) for a given L (detailed) constraint granularity for that value. This would represent a fine-grained value, as opposed to a coarse-grained levelSof constraint granularity that would permit a range of values with no predefined length Oor format restrictions, as represented by the first element definition in Example 5.1. J A M I E 5 0 5 1 B U Example 5.1 Three variations of the same XML schema element definition. The first is clearly a coarse-grained constraint because it allows the product code to exist as an open-ended string value. The second is less coarse-grained because it restricts the product code length to one to four characters. The last element is a fine-grained constraint because it dictates that the product code must be four characters and that each character be a number between 0 and 9. Constraint granularity can be associated with individual parameters processed by a capability or with the capability as a whole. For example, the same capability may accept SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc. 06_0132344823_05.qxd 118 6/13/07 4:44 PM Page 118 Chapter 5: Understanding Design Principles a body of input data comprised of two separate values, one of which is subject to finegrained constraints and the other of which is validated against a coarse-grained constraint. The three code samples in Example 5.1 could alternatively exist as different types with different names but with the same constraints and as part of the same service capability (or Web service operation). It is also important to note that constraint granularity is generally measured in relation to the validation logic present in the service contract only. This measure therefore W excludes validation constraints that may be applied by the underlying service logic. I may have coarse constraint granularity, Whereas a capability defined within a contract the actual capability logic may apply more fine-grained constraints after input values L have been validated against the service contract. S O N There are no rules about how forms of granularity can be combined. For , a coarse-grained service to proexample, it would not be uncommon for NOTE vide fine-grained capabilities that exchange coarse-grained data validated against fine-grained constraints. J A Sections on Granularity Levels M There is no one principle that dictates granularity levels for a service design. Instead, I several service-orientation principles impact the various types of granularity in differE affecting design granularity typically ent ways. Those chapters that cover principles address this issue within the standard [Principle Name] and Service Design section. • • • 5 SUMMARY OF KEY 0 POINTS Service granularity refers to the functional5scope of the service as a whole, as defined by its functional context. 1 Capability granularity refers to the functional scope of a specific capability. B Data granularity refers to the volume of data exchanged by a service U capability. • Constraint granularity refers to the level of detail to which validation logic is defined for a particular parameter or capability within the service contract. SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
Purchase answer to see full attachment
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Attached.

Running head: SERVICE DESIGN

1

Service Design
Name
Institution

SERVICE DESIGN

2
Service Design

1.) Choose four of the primary design principles of SOA and explain how they differ
from the goals of traditional software development.
Service-oriented design principles present SOA as being superior to traditional software
development. Service loose coupling is one of the most prominent design principles of SOA.
Loose coupling allows contracts that could be evolved without necessarily affecting the
implementation of services. As compared to traditional software development, the traditional
method involved a change process for classes whereby the change could affect the overall
relationship for the operation of the software program. In loose coupling, changes made to
classes do not affect the entire program thus making it easy to make changes to parts of the
program without affecting the entire operational basis of the software (Erl, 2007).
Another principle of SOA is service autonomy that is included in the design. Essentially,
autonomy means that programs are more independent of their execution environments. The
reliability of the service is boosted especially because it can operate with little dependence on
resources that it cannot control. Further, the service reusability principle focuses on creating a
service, in SOA, that can be reused in businesses (Li, 2010). This takes away the need to depend
on business or technology in using the solution logic. Therefore, unlike traditional software
development, this principle allows more independence of the software.
A standardized service contract is the fourth principle that allows SOA to stand out. First,
it allows service contracts within a service enterprise or domain to adhere to the same design.
That facilitates the reusability of the contained services. Essentially, this design principle
increases the reusability of software and the production of standardized containers that ease the
design process (Rosen, 2012). Therefore, it beats the traditional software design by allowing a

S...


Anonymous
Awesome! Perfect study aid.

Studypool
4.7
Trustpilot
4.5
Sitejabber
4.4

Related Tags