Web Services and Service Oriented Architecture

1. Web Services and Service Oriented Architecture Irina Astrovskaya Stefan Gremalschi CSC8350 Dr. Xiaolin Hu

2. Outline • Introduction • Service Oriented Architecture (SOA) • Web Services • SOAP • WSDL • UDDI • Web Services and Patterns for e-Business • Business Intelligence (BI) and Service Orientation (SO) • Enterprise Service Bus • Patterns in eBusiness • Example • Web Services and Security • Security Issues • ESB Security Patterns • Web Services Security Patterns

3. Service Oriented Architecture (Motivation) It takes too much time, money and energy to bring even a simple change to life!!! How do I make my system more flexible and responsive to the changes in business logic? This change should bring $X00 million in the next two years How can I make heterogeneous systems and applications communicate as seamlessly as possible? We need to incorporate 50 new services next 6 months. How can I achieve it without bankrupting the enterprise? Well…How about moving to this new technology? • Heterogeneity (platform, age, technology, etc.) • Change

4. Composable Re-Usable Interoperable SOA LooselyCoupled Service Oriented Architecture (SOA) • SOA is an architectural style that encourages the creation of loosely coupled, interoperable, evolvable distributed applications. • Service is an autonomous, platform-independent entity with interface-based description (XML) which exists as a single instance and interacts with applications and other services through a loosely coupled, message-based communication model.

5. Applications Operational Requirements State composed of enforce manage Policies governed by bound by exchange have Message Exchange Pattern Messages Contracts describe is a set of Schemas define structure of contain Service Orientation Services

6. Service is… • Not an object • Services consumes and produces sets of objects passed-by-value (~ transaction). • Services are hosted than forward-deployed. • Encapsulation is at the interface, rather than at implementation. • All platforms can consume contracts and messages. • Not a component • Service is a manager object for its set of components. • Service -> business function; component -> business rule or entity.

7. SOA Terminology • Service provider implements • a service specification. • Service consumer is a • “client” (application, service). • Service locator acts as a • registry (service provider • interfaces, service locations). • Service broker can pass • service requests to additional • service provider(s).

8. SOA Collaborations • ‘Find, bind, invoke’ paradigm:

9. Web Services • The most promising implementation of SOA. • Web Service “is a platform-independent, loosely coupled, self-contained programmable Web-enabled application that can be described, published, discovered, coordinated, and configured using XML artifacts and open standards (SOAP, WSDL, UDDI) for the purpose of developing distributed interoperable applications in Internet.” • Web Services Interoperability Organization (WS-I) promotes Web services interoperability with the use of generic protocols for messaging between services.

10. SOAP: Simple Object Access Protocol • SOAP is lightweight messaging protocol in distributed environment • Simplicity (XML) • Portability • Firewall-friendly • Use of open standards • Interoperability • Universal acceptance • Resilience to change • Initially tired to HTTP • Stateless • Serializes by values

11. SOAP Example in HTTP HTTP Request POST /Accounts/Henrik HTTP/1.1Host: www.webservicebank.comContent-Length: nnnnContent-Type: text/xml; charset="utf-8“ SOAPAction: "Some-URI“ <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"  SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">   <SOAP:Header>       <t:Transaction xmlns:t="some-URI" SOAP:mustUnderstand="1">               5       </t:Transaction>   </SOAP:Header>   <SOAP:Body>       <m:Deposit xmlns:m="Some-URI">           <m:amount>200</m:amount>       </m:Deposit>   </SOAP:Body></SOAP:Envelope> SOAP Method Name SOAP Header SOAP Body SOAP Envelope

12. WSDL: Web Services Describing Language • WSDL is an XML-based language used to define Web services and describe how to access them.

13. WSDL: Syntax <definitions> <types> …. </types> <message> <part> function call </message> <portType> operations of web service </portType> <binding> communication protocols </binding> </definitions>

14. UDDI: Universal Description, Discovery and Integration • UDDI presents itself as the “infrastructure for Web • services”, mostly used in constrained environments • (within a company, among set of business partners) • Entry is an XML document

15. UDDI: Universal Description, Discovery and Integration • The UDDI specification is complete and encompasses many aspects of an UDDI registry from its use to its distribution across several nodes and the consistency of the data in a distributed registry. • Most UDDI registries are private. • UDDI is the least critical part due to the complexities of Business-to-Business interactions (establishing trust, contracts, legal constrains and procedures, etc.)

16. Web Services and Patterns for e-Business

17. Business Intelligence (BI) and Service Orientation (SO) • Similarities and differences between Business Intelligence (BI) and Service Orientation (SO), two architectural paradigms that have developed independently. • SO Benefits: • Best suited to application-to-application integration and wellsuited to low-volume, high-frequency events • Provides an operational platform, tightly defines data formats andstructures, and encapsulates and abstracts functionality • Supports reuse of enterprise components and allows agilechange in business processes • BI Benefits: • Best suited for data-to-data integration and able to handle large data volumes • Provides a combined model of the enterprise data and provides foundation for business decisions and the ability to ask any question of the data • Good tools and mechanisms for transforming data

18. SO + BI= SoBI • It is… • BI:the single version of the truth for data. • SO:the architectural approach for application integration. • It will… • BI: provide open access to data services,support ad hocanalysis, andprecannedanagement reporting,consolidate data. • SO: provide application-to-application integration, some event feeds to the DW, and theinfrastructure services forall applications. • It will not… • BI: become a dumping ground for all data, or the data owner, be the default data source to other applications, and support operational reporting. • SO: be used in every circumstance and replace data import interfaces.

19. Enterprise Service Bus • Web services are becoming more widely used in enterprise application development and integration. • Critical issues arising: • is finding more efficient and effective ways of designing, developing and deploying Web services based business systems; • moving beyond the basic point-to-point Web services communications to broader application of these technologies to enterprise-level business processes. • Enterprise Service Bus (ESB) model is emerging as a major step forward in the evolution of Web services and service-oriented architecture.

20. What is an enterprise service bus? • An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. • It is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond. • ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models. • For a business, an ESB can manage connectivity needs by providing standards based application integration with support for Web services, message based transport and mediation (transformation and routing) oriented toward a SOA.

21. Key characteristics of an ESB • An enterprise service bus: • Is standards-based • Enable all parts of a business to react instantly to changes • Minimizes risk by using industry standard interfaces and protocols • Overcomes differences in platform, software architecture and network protocols • Assures delivery of transactions, even when systems and networks go off-line • Re-routes, logs and enriches information without rewriting applications • Provides an infrastructure that is highly distributed and yet can be managed centrally • Can be deployed incrementally • May combine new and existing technologies and standards • Supports message, service and event oriented architecture

22. Benefits of an ESB • Potential IT Benefits: • Create additional value from existing applications and information • Quickly add best-of-breed applications • Reduce the total cost of ownership through a standards based SOA • Quickly respond to changing value-chain requirements • Leverage existing assets in new ways • Simplify complex programming tasks • Reduce software development and maintenance cost • Improve system security, scalability, availability and robustness • Potential Business Benefits: • Improve customer service and business agility • Lower operating costs • Access real time business information accurately and rapidly • Accelerate mergers and acquisitions • Lower inventory costs • Improve return on assets • Eliminate manual process errors • Improve and automate value-chain management

23. Pattern Language Overview • SYNCHRONOUS SERVICEACTIVITY: synchronous service invocation in a business processactivity. • FIRE AND FORGETACTIVITY: a service invocation without anyexpected output of the service. • (MULTIPLE) ASYNCHRONOUS REPLY SERVICE: service invocations withasynchronous replies in a business process. • ASYNCHRONOUSSUB-PROCESS SERVICE: design a servicethat only instantiates a sub-process – without waiting in the calling process for the termination ofthe sub-process. • FIRE EVENT ACTIVITY: activities that firecertain events to be processed by external systems. • TERMINABLE DELIVERY: time-bound dependencies of business processes on required states ofbusiness objects.

24. Synchronous Service Activity • Synchronous invocations of a service in a process flow need to be modelled such that theprocess is able to consider the functional interface of the service and the datadependencies to the service, and may react on the possible results of the service. • Model the service invocation as aSYNCHRONOUS SERVICE ACTIVITYsuch that it: • maps thefunctional input parameters of the associated service to its input data objects and thefunctional output parameters of the service to its output data objects. • The service is fedwith the input parameters from the input objects of the activity, and the outputparameters of the service are given back and stored in the output objects of the activity. • The process flow, which follows the invoking activity, implements the decision logic toreact on the results of the service based on the attributes of the output objects.

25. Synchronous Service Invocation Pattern

26. Asynchronous Reply Service • Service invocations from a process flow need to be modelled that are not synchronousblocking calls, but rather event-based. That is, the service invocation just places theservice request and picks up the service result later on in the process flow, analogous tothe well-known callback concept. • Split the request for service execution and the request for the corresponding result intotwoSYNCHRONOUS SERVICE ACTIVITIESand relate the two activities by aCORRELATIONIDENTIFIER[Hohpe et al. 2003] that is kept in a control data object. ThisCORRELATIONIDENTIFIERis the output of the first service request, is temporarily saved in a requestrepository, and is then – later in time – used as an input for the second request thatrepresents picking up the result.

27. Structure of One Reply Asynchronous Service

28. Placing a Service Request and Getting the Service Reply Asynchronously

29. Example: A Service-oriented Architecture for Business Intelligence • The first step in the legacy system is tobreak down the legacy components into service-orientedreusable components able to communicate through openstandard messaging protocols, based on XML, WS-* andSOAP. • The key benefits of SOA-ITPA architecture are: • Integrated and consistent “single version oftruth” data architecture • Scalable and flexible ETL processes • Reusable and extensible services, providingacceptablereturn on investment • Actionable insight BI solutions to send BI analyticalresults to users and help them tounderstandthe information so the appropriate actionscan be taken in BI real time environment

30. Service Oriented Architecture for ITPerformanceAnalytic (SOA-ITPA) Integrated reporting data store: The essential part is the integrated centralizedintegrated reporting data store (RDS). RDS consistsof historic, current and predictive data. A number ofcomponent services are built to populate data fromsources into RDS. SOA enabled BI component services:The implementation of BI analytical modules for dashboard and reporting, performancemanagementguided analysis application or other decision makingapplications is made easier and quicker by the use of thepublisher-subscriber communicationparadigm. Analytical application solutions: The data marts are engineeredto meet different applications requirements.They can be in different formats

31. Web Services and Security

32. Security Core • Authentication: credentials prior to accessing a Web service (WS-Security, SAML) • Authorization: restricted access based on policies (XACML) • Confidentiality (XML-Encryption, WS-Security). • Integrity of information (XML-Signature, WS-Security). • Non-repudiation: the service provider should be able to prove that a requester used a certain Web service and vice-verse (XML Digital Signature). • Privacy (WS-Policy and WS-Security Policy) • Audit of user access and behavior. • Trust ( WS-Trust) • Accounting, Charging.

33. ESB Security (Security as a Service) • Application provides enforcement functionality for external access control but relies on service to acquire a decision. • Multiple enforcement points can reuse the same decision point functionality. • SES : Security Enforcement Service

34. ESB Security Patterns Application Managed Security Brokering Security (Reverse Proxy) Gateway Based ESB

35. Web Services Security Patterns • Security patterns can be used to build secure systems, including hardware or organizational problems.

36. Role-Based Assertion Coordinator(SAML: Security Assertion Markup Language) • SAML expresses security assertions than can be exchanged. • Role-Based Assertion Coordinator allows seamless exchange of security data in distributed environment to coordinate role-based access control to protected resources. • Context Distributed environment including heterogeneous systems and web services. • Problem • Lack of feasible solutions for providing precise access control to resources. • Need in means to exchange security information in a standardized format that is flexible and not expensive to change at the same time. • The security of the shared data. • Consistency of data exchange. • Adding a new security verification policies (cost, time).

37. Role-Based Assertion Coordinator • Exchange security information in form of SAML assertions via SOAP over HTTP. • AssertionCoordinator creates and distributes Assertions to requesting parties, uses the UserAccount to retrieve information needed to create the SAML assertions. Authenticated clients are Principals. When it make service requests to PolicyDecisionEnforcers(PED) , AssertionCoordinator issue Assertions on behalf of them. PED grants or revokes access based onAssertion’s role attributes. · Centralized data exchange. · Standardized approach. · Role-based access. · Extensibility.

38. XACML: eXtensible AccessControl Markup Language (OASIS) • Web service policy language (WSPL), an access decision language (XML-based) • Policy Enforcement Point (PEP): access control by requesting an access decision from Policy Decision Point (PDP). The PDP uses policies (from Policy Administration Point (PAP)) and attributes (from Policy Information Point (PIP)) to render its decision. Context Handler (CH) is an adapter between the XACML components and the protected application.

39. XACML Authorization • Unifies definition of authorization rules in organization • Example Financial company (many actors-> policies: many syntaxes; no global view; conflicts) • Context Complex environment with many actors and relations with other enterprises. Various actors may access the resources, web services, sensitive documents or system components. • Problem How do we unify the definition of access policies, making the system simpler and less error-prone? • The policies with different syntaxes are issued by a variety of actors and may be stored in many locations. • They are constantly changing and need to be updated. • Some policies can require a set of actions to be performed in conjunction with policy enforcement .

40. XACML Authorization: Solution • Write all policies in a common language using a standard format. Format is generic enough to implement some common high level policies or models. In addition, define a combining algorithm for policies to resolve conflicts. PolicyAdministrationPoint is a rule repository of policy definitions. Rule associates sets of Subjects , Resources, and Actions, Environments (rule is applicable), a condition (constraints) and an effect (“Permit” or “Deny”). Target identifies the applicable rules in a given context. Composite Pattern for Policies. Policies are combined by policy CombiningAlgorithm (Strategy).

41. XACML Authorization: Implementation and Consequences • Implementation • Decide to use XACML for security for docs and services. • Define semantics for the subject, the resource and the environment’s attributes for each intended authorization. • Translate existing rules into the XACML format. • Define new rules as XACML rules and policies. • Add/Remove policies when needed. • Consequences • Policies to control access are easily defined This makes the whole system less complex, and more secure. • A variety of policy types can be described. • Policies and rules can be easily combined. • This pattern enables different actions through the obligation.

42. XACML Access Control Evaluation • Defines a request/response syntax for access control decisions • Problem How do we enforce the rules defined in numerous authorization systems for its? Enforcement points could be in many systems. Any security policy should be enforced. Subject accesses Resource iff XACMLAccessResponse authorizes it. All access requests are submitted to a unique PolicyDecision Point in a common format. It returns access decision, based on ApplicablePolicy (XACMLAccessRequest, XACMLAccessResponse.) The PolicyInformationPoint provides attributes from the subject. ContextHandler is an adapter between any enforcement mechanism and XACML PolicyDecisionPoint.

43. XACML Access Control Evaluation • Implementation • Implement a ContextHandler for applications that already have a PolicyEnforcementPoint with another access decision language • Implement XACML PolicyEnforcementPoint for applications that do not implement access control • Add the translated existing and new authorization rules to the PolicyAdministrationPoint • Consequences • Access decision becomes independent from its enforcement. Many enforcement mechanisms could be supported and can evolve separately from the PolicyDecisionPoint. • Pattern can support multilevel models for access control.

44. XML Firewall • Filters XML messages to/from applications, based on the business access control policies and the content of the message. • Context User-defined applications (web services or applications using web services) communicate through XML messages. • Problem The XML documents may contain harmful data or can be used to perform attacks against applications. Moreover, network firewalls provide infrastructure security but become useless when these high level protocols and formats are used. • Firewall must adapt easily to new XML formats. • Firewall must adapt easily to new types of attacks. • Filtering code should be separated from the application code. • New applications may be integrated into the system. This integration should not require additional costs.

45. XML Firewall • A client can access to service iff specific policy authorizes and message content is considered to be safe. Policies for each application are centralized within PolicyDefinitionPoint. Application is accessed by a client through a PolicyEnforcementPoint: authenticates client by data in PolicyDefinitionPoint, looks for a mapping policy for the request and checks message content ( valid XML schemas, harmful data). · More secure system · As authentication of Clients is performed, it holds regular users responsible of their actions. · New applications are easily integrated (add their policies). · New clients can de accommodated (add new policies)

46. THANKS!