1 / 29

Service-oriented architecture

Service-oriented architecture. The Basic. main concepts Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users.

giona
Download Presentation

Service-oriented architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service-oriented architecture

  2. The Basic • main concepts • 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 • a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services

  3. SOA • Services inter-operate based on a formal definition (or contract, e.g., WSDL) • independent of the underlying platform and programming language • Interface definition hides the implementation of the language-specific service • Independent of development technologies and platforms (such as Java, .NET etc) • Support integration and consolidation activities within complex enterprise systems

  4. SOA definitions • Design for linking business and computational resources on demand to achieve the desired results for service consumers

  5. OASIS (Organization for the Advancement of Structured Information Standards) Defiition A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

  6. SOA Elements

  7. Why SOA? • Traditionally, IT works with the business owners, who are influenced by application vendors. • using a point-to-point approach that connected the application to both upstream and downstream systems • may not be integrated into the existing architecture • Redundant infrastructure solutions • Impossible and impractical to modify this portfolio to reflect a change in a business process

  8. Business Problems Impact IT • Globalization • Economic Pressures • Business Process Outsourcing • Technology • Lack of Cohesive Business Information Strategy • Standards

  9. Business Problems Impact IT • Business and IT operations teams frequently differ in their approaches • For example, some business operations teams prefer to demonstrate “quick wins” to validate an approach, while IT operations prefer to build out the infrastructure. • Fortunately, SOA offers both

  10. Why SOA? • main drivers • links computational resources and promotes their reuse • help businesses respond more quickly and cost-effectively to changing market conditions • style of architecture promotes reuse at the macro (service) level rather than micro level (objects) • simplify interconnection to - and usage of - existing IT (legacy) assets

  11. Why SOA? • Considered an architectural evolution • Better than a revolution and captures many of the best practices of previous software architectures • Different to modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s) • SOA separats users (consumers) from the service implementations • Services can therefore be run on various distributed platforms and be accessed across networks • maximise reuse of services

  12. Service-oriented design and development (SOAD) • SOA uses SOAD concept. • SOAD • design methodology for developing highly-agile systems in a consumer/producer model • abstracts implementation from process, • a service-provider can be modified or changed without affecting the consumer

  13. Service-oriented design and development (SOAD) • Service contract • Header • Name - Name of the service • Version - The version of this service contract • Owner - The person/team in charge of the service • RACI • Responsible - the person/team responsible for the deliverables of this contract/service. • Accountable - Ultimate Decision Maker in terms of this contract/service • Consulted - Who must be consulted before action is taken • Informed - Who must be informed that a decision or action is being taken. • Type - the type of the service • Data • Process • Functionality • Presentation

  14. Service-oriented design and development (SOAD) • Functional • Functional Requirement (From Requirements Document) • Service Operations – • Methods, actions etc. • Must be defined in terms of what part of the Functionality it provides. • Invocation – • Indicates the invocation means of the service. • This includes the URL, interface, etc. • Examples: • SOAP • REST • Events Triggers

  15. Service-oriented design and development (SOAD) • Non-Functional • Security Constraints – • Defines who can execute this service in terms of roles or individual partners, etc. • which invocation mechanism they can invoke • Quality of Service – • Determines the allowable failure rate • Transactional – • Is this capable of acting as part of a larger transaction • and if so, how do we control that? • Service Level Agreement – • Determines the amount of latency the service is allowed to have to perform its actions • Semantics – • Defines the meaning of terms used in the description and interfaces of the service • Process – • Describes the process of the contracted service

  16. SOA and Web service protocols • Web services standards relevant to SOA • XML • HTTP (or HTTPS) • SOAP • Web Services Description Language (WSDL) • Universal Description, Discovery, and Integration (UDDI)

  17. SOA and Web 2.0 • Web 2.0 • Refers to a "second generation" of web sites • Distinguished by the ability of visitors to contribute information for collaboration and sharing • Use Web services and may include Ajaxprogram interfaces, Web syndication, blogs, and wikis • no set standards for Web 2.0 • building on the existing web server architecture and using services • regarded as displaying some SOA characteristics

  18. The challenges faced in SOA adoption • Managing services metadata • SOA-based environments can include many services which exchange messages to perform tasks • E.g., a single application may generate millions of messages • Provide appropriate levels of security • Application-managed security is not the right model for securing services • Interoperability is another important aspect in the SOA implementations

  19. Criticisms of SOA • Some criticisms of SOA are based on the assumption that SOA is the equivalent of Web Services • SOA results in the addition of XML layers introducing XML parsing and composition • Applications may run slower and require more processing power without RPC (Remote Procedure Calls) • Increases costs

  20. Criticisms of SOA • Stateful services • require both the consumer and the provider to share the same consumer-specific context • included in or referenced by messages exchanged between the provider and the consumer • may reduce the overall scalability of the service provider • because it may need to remember the shared context for each consumer • Also increases the coupling between a service provider and a consumer • makes switching service providers more difficult

  21. Criticisms of SOA • WS standards and products are still evolving • E.g., transaction, security, etc • Can thus introduce risk • Need properly managed and estimated • Aadditional budget and contingency neededfor additional Proof

  22. SOA Lifecycle Stages • Initiate SOA • decide which business function and underlying processes SOA will enable, enhance, or even replace. • The company establishes a project team, objectives, and timelines & deliverables • For the purpose to create a roadmap that combines business and IT efforts

  23. SOA Lifecycle Stages • Develop Roadmap • spells out the process for conducting an SOA assessment • developing the SOA principles • define the SOA principles in a clear and concise manner • defining the reference architecture • describe the “future state” for the IT organization • making the transition from the current situation to the future state. • define the phases for deploying business solutions and the infrastructure required to support them.

  24. SOA Lifecycle Stages • SOA Execution Plan • describes how to execute towards the SOA roadmap. • execute projects in the sequence described in the roadmap • build out the infrastructure as required to provide the business capability

  25. SOA Lifecycle Stages

  26. IBM SOA Lifecycle Stages

More Related