Service oriented architecture

1. Service oriented architecture

2. Service-Oriented Architecture SOA • “A service-oriented architecture (SOA) is an application framework that takes everyday business applications and breaks them down into individual business functions and processes, called services. An SOA lets you build, deploy, and integrate these services independent of applications and the computing platforms on which they run.” –IBM“ • Some of the characteristics • Increasing nature of distributed systems • Heterogeneity of systems and computing environments • Transparency of communication infrastructure details

3. SOA is a specification and methodology for providing platform and language independent services for use in distributed applications. • A service is a repeatable task within a business process and business task is a composition of services. • SOA describes a message passing taxonomy for component bases architecture that provides services to clients upon demand.

4. SOA Enabling Technologies • Enterprise Service Bus (ESB) • Web Services (SOAP, WSDL, UDDI)

5. SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on different operating systems (such as Windows and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML). • UDDI is an XML-based standard for describing, publishing, and finding web services. UDDI stands for Universal Description, Discovery, and Integration. • WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information

6. Business Process Modeling (BPM) • BPM addresses process flow and service invocations to form useful works. • Two integration methods • Orchestration • Choreography • WS- BPEL (orchestration-like) • A language standard for WS interactions • View business process as a collection of activity graphs • Provides command for defining logic using conditional statements, loops, variable etc.

7. Orchestration • A middleware service centrally coordinates all different web service operations. • All set of services send and receive messages from orchestrator. • The logic of compound business process is found in orchestrator alone.

8. Orchestration

9. Choreography • There is no central coordination function. • Each web service that is a part of business process is aware of when to process a message and with what client it needs to interact with. • All members are responsible for determining which operations to execute and when to execute them, structure of messages and their timings and other factors.

10. Choreography

11. Orchestration Most mature SOA implementations favor orchestration over choreography for a number of reasons. • With orchestration a single central service manages the various processes, and changes to the business logic can be made in that one location. • The integration of Web services into the architecture is easier than with choreography because these services don't need to know anything about the business process. • Centralizing the business logic also makes it easier to put error handling mechanisms in place and to account for, manage, and analyze events that occur outside the business process that relate to a part of the process.

12. ESB • An ESB is not a physical bus in the sense of a network: rather it is an architectural pattern comprised of set of network services that manage transactions in a Service Oriented Architecture. • An ESB is necessary but not essential to a SOA. • An ESB plays a role of transaction broker in SOA, ensuring that messages get to where they are supposed to go and acted upon properly. • The bus performs the task of message translation, registration, routing, logging, auditing and managing transactional integrity.

13. The Enterprise Service Bus An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA).

14. Managing and Monitoring SOA Software for monitoring and managing an SOA infrastructure plays an important role in large SOA deployments. While SOA offers a logical design and reusable components, it does not make the task of network management any easier. If anything, SOA management requires proactive oversight because you can't wait for a particular application to fail before taking corrective action. Therefore, tools for managing SOAs tend to be multifaceted and run constantly

15. SOA management tools • HP Software and Solutions OpenView SOA Manager • IBM Tivoli Framework Composite Application Manager for SOA • Oracle BPEL Process Manager

16. SOA security • Security Assertion Markup Language (SAML) is an XML standard that provides for data authentication and authorization between client and service. The SAML technology is used as part of Single Sign-on Systems (SSO) and allows a user logging into a system from a Web browser to have access to distributed SOA resources. • WS-Security (WSS) is an extension of SOA that enforces security by applying tokens such as SAML or X.509 to messages. Through the use of XML Signature and XML Encryption, WSS aims to offer client/service security. • WS-SecureConversionis a Web services protocol for creating and sharing security context. WS-SecureConversion is meant to WS-Policy are in use, and it attaches a security context token to communications such as SOAP used to transport messages in an SOA enterprise.

17. WS-Trust extends WS-Security to provide a mechanism to issue, renew, and validate security tokens. A Web service using WS-Trust can implement this system through the use of a Security Token Service (STS), a mechanism for attaching security tokens to messages and a set of mechanisms for key exchanges that are used to validate tokens and messages. • WS-Security Policy provides a set of network policies that extend WS-Security, WS-Trust, and WS-Secure Conversion so messages complying to a policy must be signed and encrypted. The Security Policy is part of a general WS-Policy framework.

18. The Open Cloud Consortium OCC working groups perform these functions: • They develop benchmarks for measuring cloud computing performance. • They provide testbeds that vendors can use to test their applications, including the Open Cloud Testbed. • They support the development of open-source reference implementations for cloud computing. • They support the management of cloud computing infrastructure for scientific research as part of the Open Science Data Cloud (OSDCP) Working Group's initiative

19. Relating SOA and Cloud Computing • Cloud computing is still in its infancy, and although Web services can implement a Service Oriented Architecture, it is not a requirement. Most of the large implementations of cloud computing described in this book are single-purpose applications that have been optimized on a grand scale: Carbonite's backup, and Twitter's Instant Messaging (IM) are several examples • SOA is loosely coupled because the service is separated from the messaging. If a component doesn't provide the capabilities required, it is an easy task to switch to a different component, and switching requires almost no programming • SOA components are often best-of-breed service providers that can provide a measured service level and can play a role in Business Process Management (BPM) systems. The separation of services from their design allows for much easier system upgrades and maintenance.