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. –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

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

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

OASIS (Organization for the Advancement of Structured Information Standards) DefiitionOrganization for the Advancement of Structured Information Standards 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.

SOA Elements

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

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

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

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

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

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

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

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

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

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)

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 Ajax program 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

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

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

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

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 needed for additional Proof

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

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.

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

SOA Lifecycle Stages

IBM SOA Lifecycle Stages