Service Oriented Architecture


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Service Oriented Architecture

  1. 1. SERVICE ORIENTED ARCHITECTURE SOA Presented by: G Emmanuel sandeep MBA(SEM)
  2. 2. AGENDA <ul><li>What is SOA? </li></ul><ul><li>Elements of SOA </li></ul><ul><li>Why SOA ? </li></ul><ul><li>Objectives of SOA </li></ul><ul><li>SOA principles </li></ul><ul><li>Technologies Used </li></ul><ul><li>Service-oriented analysis and development </li></ul><ul><li>Service contract </li></ul><ul><li>challenges faced in SOA adoption </li></ul>
  3. 3. WHAT IS SOA? <ul><li>There is no widely-agreed upon definition of Service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle. Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation . These concepts can be applied to business, software and other types of producer/consumer systems. </li></ul>
  4. 4. WHAT IS SOA? [CONTD..] <ul><li>SOA should be business oriented </li></ul><ul><li>SOA is a way of thinking </li></ul><ul><li>SOA is not Web Services </li></ul><ul><li>Loosely coupled architecture that uses messaging </li></ul><ul><li>Enriched by creating composite apps </li></ul><ul><li>Move from batch to real-time </li></ul>
  5. 5. Elements of SOA
  6. 6. WHY SOA ? <ul><li>The main drivers for SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro level (objects). </li></ul><ul><li>To gain some type of ROI </li></ul><ul><ul><li>Internal (for the organization) </li></ul></ul><ul><ul><li>External (for customers or partners) </li></ul></ul><ul><li>To be competitive </li></ul><ul><ul><li>Time to market </li></ul></ul><ul><ul><li>More robust applications </li></ul></ul>
  7. 7. OBJECTIVES OF SOA <ul><li>Technology Independence </li></ul><ul><ul><li>The Consumer of a Service component is completely independent of the technology of the Provider component and vice-versa. </li></ul></ul><ul><li>Life-cycle Independence </li></ul><ul><ul><li>Each of the Provider and Consumer Service components should be able to operate in a separate life- cycle. </li></ul></ul><ul><li>Loose Coupling </li></ul><ul><ul><li>The Service Consumer Component must define its specification independent of the Service Provider Component </li></ul></ul>
  8. 8. OBJECTIVES OF SOA[CONTD..] <ul><li>Invokable interfaces </li></ul><ul><ul><li>The Service interfaces must be invokable either locally or remotely. </li></ul></ul><ul><li>Communication Protocol </li></ul><ul><ul><li>A Service must be invokable by variety of protocol. </li></ul></ul><ul><ul><li>Binding to a specific protocol must take place at run-time/deployment-time, and not at the design or development time. </li></ul></ul><ul><ul><li>The choice of protocol must not restrict the behavior of the Service. </li></ul></ul>
  9. 9. SOA PRINCIPLES <ul><li>The following guiding principles define the ground rules for development, maintenance, and usage of the SOA </li></ul><ul><ul><li>Reuse, granularity, modularity, composability, componentization, and interoperability </li></ul></ul><ul><ul><li>Compliance to standards (both common and industry-specific) </li></ul></ul><ul><ul><li>Services identification and categorization, provisioning and delivery, and monitoring and tracking </li></ul></ul>
  10. 10. SOA PRINCIPLES: SPECIFIC ARCHITECTURAL PRINCIPLES <ul><li>Service Encapsulation </li></ul><ul><li>Service Loose coupling </li></ul><ul><li>Service contract </li></ul><ul><li>Service abstraction </li></ul><ul><li>Service documentation </li></ul><ul><li>Service reusability </li></ul><ul><li>Service composability </li></ul><ul><li>Service autonomy </li></ul><ul><li>Service optimization </li></ul>
  11. 11. TECHNOLOGIES USED <ul><li>Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including: </li></ul><ul><ul><li>REST- Representational state transfer </li></ul></ul><ul><ul><li>RPC- Remote Procedure Call </li></ul></ul><ul><ul><li>DCOM- Distributed Component Object Model </li></ul></ul><ul><ul><li>CORBA- Common Object Request Broker Architecture </li></ul></ul><ul><ul><li>Web Services </li></ul></ul><ul><li>SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. </li></ul>
  12. 12. SERVICE-ORIENTED ANALYSIS AND DEVELOPMENT <ul><li>The modeling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SOAD. SOAD is a design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer. </li></ul>
  14. 14. SERVICE CONTRACT <ul><li>A service contract needs to have the following components </li></ul><ul><li>Header </li></ul><ul><ul><li>Name - Name of the service. Should indicate in general terms what it does, but not be the only definition </li></ul></ul><ul><ul><li>Version - The version of this service contract </li></ul></ul><ul><ul><li>Owner - The person/team in charge of the service </li></ul></ul>
  15. 15. SERVICE CONTRACT[CONTD..] <ul><li>RACI </li></ul><ul><ul><li>Responsible - The role is the person/team responsible for the deliverables of this contract/service. All versions of the contract </li></ul></ul><ul><ul><li>Accountable - Ultimate Decision Maker in terms of this contract/service </li></ul></ul><ul><ul><li>Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision. </li></ul></ul><ul><ul><li>Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action. </li></ul></ul>
  16. 16. SERVICE CONTRACT[CONTD..] <ul><li>Type - This is the type of the service to help distinguish it in the layer in which it resides. </li></ul><ul><ul><ul><li>Data </li></ul></ul></ul><ul><ul><ul><li>Process </li></ul></ul></ul><ul><ul><ul><li>Functionality </li></ul></ul></ul><ul><ul><ul><li>Presentation </li></ul></ul></ul>
  17. 17. SERVICE CONTRACT[CONTD..] <ul><li>Functional </li></ul><ul><ul><li>Functional Requirement (From Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished. </li></ul></ul><ul><ul><li>Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides. </li></ul></ul><ul><ul><li>Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for internal and external clients each with a different invocation means and interface. Examples: </li></ul></ul><ul><ul><ul><li>SOAP </li></ul></ul></ul><ul><ul><ul><li>REST </li></ul></ul></ul><ul><ul><ul><li>Events Triggers </li></ul></ul></ul>
  18. 18. SERVICE CONTRACT[CONTD..] <ul><li>Non-Functional </li></ul><ul><ul><li>Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke. </li></ul></ul><ul><ul><li>Quality of Service - Determines the allowable failure rate </li></ul></ul><ul><ul><li>Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that? </li></ul></ul><ul><ul><li>Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions </li></ul></ul><ul><ul><li>Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service </li></ul></ul><ul><ul><li>Process - Describes the process, if any, of the contracted service </li></ul></ul>
  19. 19. CHALLENGES FACED IN SOA ADOPTION <ul><li>One obvious and common challenge faced is managing services metadata . </li></ul><ul><li>Another challenge is providing appropriate levels of security . </li></ul><ul><li>Interoperability is another important aspect in the SOA implementations. </li></ul><ul><li>There is significant vendor hype concerning SOA that can create expectations that may not be fulfilled. </li></ul>
  20. 20. REFERENCES <ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul>
  21. 21. THANK YOU
  22. 22. EXAMPLE: AUTOMOTIVE WORK ORDER <ul><li>The Automotive Work Order domain describes the process by which an automotive maintenance company manages its customer operations. We will use this domain problem to illustrate the issues of SOAD. </li></ul><ul><li>A work order represents an agreement between the auto service company and a customer to perform a set of scheduled or emergency maintenance activities such as a scheduled 50,000-mile service, a brake pad or tire replacement, or an oil change. </li></ul>
  24. 24. AUTOMOTIVE WORK ORDER[CONTD..] <ul><li>If you constructed Work Order as an OO application, these software objects would contain all the necessary business rules and would understand the business processes that should be followed. </li></ul><ul><li>However, there are some practical disadvantages to this approach: </li></ul><ul><li>Many of the steps involve interfacing with existing legacy systems and databases such as billing, scheduling, and inventory systems, which were probably not designed adhering to the OO paradigm (applying an adapter or mediator pattern helps in such situations). </li></ul><ul><li>In order to make the system as flexible as possible, it would be helpful to have some of the rules externalized so that the processes or workflow can be modified without changes to the code. For example, rules like: </li></ul><ul><ul><li>A standard 24,000-mile service includes four liters of oil. Additional charges for oil should only be made if more than four liters are used, or if the customer requests a premium grade oil (such as a synthetic oil). </li></ul></ul><ul><ul><li>There are a set of industry-standard labor estimates for common automotive maintenance activities available through a legacy application. The customer should be billed the standard labor costs unless the mechanic exceeds that estimate by more than X% and reports a valid reason for the difference. </li></ul></ul><ul><li>The customer should be contacted for confirmation if the estimate is exceeded by more than Y%. </li></ul>
  25. 25. AUTOMOTIVE WORK ORDER[CONTD..] <ul><li>SOAD provides an excellent solution to these issues. Since it groups services on the basis of related behavior, rather than encapsulated (behavior plus data), the set of services will be subtly different from a business object model. </li></ul><ul><li>For example, you would probably group Work Order and Work Order Item together, into Work Order Services, and create Scheduling, Catalog, and Inventory services. Also, because there are no services instances, there are no equivalents to relationships between services. </li></ul>