A service Oriented Architecture & Web Service Technology

1. A service Oriented Architecture&Web Service Technology

3. The case for developing SOA • Level of Software complexity continues to increase, and traditional architectures seem to be reaching the limit of their ability • Need to respond quickly to new requirements of the business • Need to continually reduce the cost of IT to the business • Ability to absorb and integrate new business partners and new customer sets

4. Problems • Cumulative effect of decades of growth and evolution has produced severe complexity • Redundant and non-reusable programming • Real integration killer - multiplicity of interfaces

5. Requirement for a SOA • Leverage existing assets. • Existing systems can rarely be thrown away, and often contain within them great value to the enterprise. • Support all required types of integration. • User Interaction • Application Connectivity • Process Integration • Information Integration • Build to Integrate

6. Requirement for a SOA • Allow for incremental implementations & migration of assets • Include a development environment that will be built • around a standardcomponent framework, • promote better reuse of modules and systems, • allow legacy assets to be migrated to the framework, • allow for the timely implementation of new technologies. • Allow implementation of new computingmodels; • specifically, new portal-based client models, Grid computing, and on-demand computing

7. A service-oriented architecture -- not just Web services • First, though, it must be understood that Webservicesdoes not equal service-oriented architecture. • Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI, • SOA is "an application architecture within which all functions are defined as independent services with well defined invocable interfaces which can be called in defined sequences to form business processes".

8. A service-oriented architecture -- not just Web services • All functions are defined as services. • All services are independent. • Operate as "black boxes"; • external components neither know nor care how boxes are executed • merely that they return the expectedresult. • The interfaces are invocable; • At an architectural level, it is irrelevant whether • they are local or remote • what interconnect scheme or protocol is used to effect the invocation, • what infrastructure components are required to make the connection.

9. A service-oriented architecture -- not just Web services • Interface is the key, & the focus of the calling application. • It defines the requiredparameters and the nature of the result • It is the system'sresponsibility to effect and manage the invocation of the service, • This allows two critical characteristics to be realized: • Services are truly independent, • they can be managed. Management includes many functions, including: Security, Deployment , Logging, Dynamic rerouting,and Maintenance

10. The Nature of a Service • Typically within a business environment • means business functions, business transactions, and system services. • The difference in the types of services. • Business functions are from the application's perspective, non-system functions that are effectively atomic. • Services might be low-level or complex high-level (fine-grained or course grained) functions

12. An SOA - Constituent Parts • To determine what the constituent parts of an SOA are it is first necessary to break down the question into the design-time and run-time requirements. • The idea that SOA encapsulates both design-time and run-time is critical to understanding SOA • SOA is really about both physical and logical architectures.

13. SOA Design-time requirements • UDDI directory of External web services • provides the definition of a set of services • a directory of external web services already being used by the enterprise. • Directory of Enterprise Internal web services • internal directory indicates whether the web service is externally available • re-use available web services when designing new business processes. • Agile Design Methodology • methodology which is oriented towards re-use, • methodology needs to emphasize the requirement for cross-project information and working.

14. SOA Design-time requirements • Process Driven Development • based upon the modeling or re-modeling of business processes. • The start point should be the expansion or re-working of the set of modeled business processes. • Workflow Oriented Development • One of the key paradigms for SOA development is that the business processes are seamless • Each step in each process should be linked, as an automatic next step • Multi-level Design Management • Design management must be based primarily on the business objectives each project is to deliver

15. SOA Design-time requirements • Agile Toolset For SOA Development • abstraction of existing functionality into new web services • minimize coding, Ability to plug in existing middleware, • Information Routing Modeling • incorporates the need to integrate & deliver information and to deliver to the right people at the right time. • SOA solution must also be able to model the flows of information across the enterprise and the extended supply chain. • Debugging And Simulation Capability • Multi-Language Capability

16. SOA – Run-time requirements • Consolidated Process Management • ability to present transactional and information flows visually by business process, organizational unit and server. • Process Oriented Monitoring & Administration Tools • Run Time env should display information at the process level and allow activation / de-activation of any process (stopping the process at a specific step) as a means of handling problems / implementation. • Business Activity Monitoring (BAM) • SOA tool-set should include BAM capability; the run-time environment should feed data to the BAM module.

17. SOA – Run-time requirements • Persistence Of Message-Based Asynchronous Process Data • SOA requires a data store external to the applications that provide the underlying functionality, akin to an Operational Data Store, to store potentially long-term but essentially transient process related data • Scalability Of The Environment • Scaleable means that the toolset supports the deployment of further servers, the assignment of specific processes or organizational units to servers and the management of software across servers. • Resilience • must provide sufficient resilience to support the business • User Access And Security • SOA solution should offer a browser-based, role-oriented experience for the user which incorporates task lists based on the users’ roles and the relevant collaboration and knowledge content as well as links to the key web sites for the role.

18. SOA – Run-time requirements • Workflow • Availability of work-flow functionality in any SOA solution facilitates the Easy linking of processes / process parts or Browser-based task lists for the users • Event driven • The link between processes (or between a process and the external world) will often be in the form of an event • Simulation capability • The ability to simulate traffic across any process is very useful when reviewing performance and scalability questions. • Error Management • A key criterion for any SOA run-time environment is its error management. The criteria for error management are; • Visibility of errors, Re-start capability, Error notification, Workflow linking

20. SOA Model • A service provider • provides a service interface for a software asset that manages a specific set of tasks. • A service requester • discovers and invokes other software services to provide a business solution.. • A service broker; • acts as a repository, yellow pages, or clearing house for software interfaces that are published by service providers.

21. Service Requester • Content Aggregation • Activity where an entity interacts with a variety of content providers to process/reproduce such content in the desired presentation format of its customers. • Service Aggregation • Activity where an entity interacts with a variety of serviceproviders to re-brand, host, or offer a composite of services to its customers.

22. Service Provider • Independent software vendors are prime examples of potential service providers. • They own and maintain a software asset that performs tasks. • Software assets could be made available as an aggregation of services or broken down into distinctly separate software service resources. • Processes that are proven and generalized for a diverse set of applications would be good candidates for service providers. • For example, if a bank felt that its business process for loan processing was a strong enough asset to be made publicly available and was willing to support it as a business offering, then that bank could view itself as a loan processing service provider.

23. Registry • Is an entity that collects and catalogs data about other entity and then providing that data to others (a form of SOA Broker.) • Usually, a registry would collect data such as • Entity name, • Description, and contact information. In UDDI terms, this SOA role is often referred to as the White Pages.

24. Enabling technologies • XML: The Extensible Markup Language • SOAP: • Simple Object Access Protocol is an XML-based lightweight protocol for the exchange of information in a decentralized, • WSDL: • The Web Services Description Language is an XML vocabulary that provides a standard way of describing service IDLs. • UDDI: • The Universal Description, Discovery, and Integration specification provides a common set of SOAP APIs that enable the implementation of a service broker.

25. 12 Steps to implement a SOA • Understand Functional objectives and define success. • Define your problem domain. • Understand all application semantics in your domain. • Understand all services available in your domain. • Understand all information sources and sinks available in your domain. • Understand all processes in your domain.

26. 12 Steps to implement a SOA • Identify and catalog all interfaces outside of the domain you must leverage (services and simple information). • Define new services/information bound to the services. • Define new processes, services, and information bound to the processes. • Select your technology set. • Deploy SOA technology. • Test and evaluate

27. Web service

28. What a Web Service in a Few Words? • Web Services are the basis for Grid Services, which are the cornerstones of OGSA and OGSI. • Understanding the Web Services architecture is fundamental to using GT3 and programming Grid Services • what exactly are Web Services? • To put it quite simply, they are yet anotherdistributed computing technology (like CORBA, RMI, EJB, etc.) They allow to create client/server applications. http://www.casa-sotomayor.net/gt3-tutorial/core/service_data/sd_ogsa.html

29. Web Service • The clients (the PCs at the store) • contact the Web Service in the server • send a service request asking for the catalog • The server returns the catalog through a service response. • This is a very sketchy example of how a Web Service works.

30. Web Services have certain advantages over other technologies Why cannot we use RMI, CORBA, EJBs, and countless other technologies. • So, what makes Web Services special? • Web Services are platform-independent and language-independent (standard XML) • Most Web Services use HTTP for transmitting messages (such as the service request and response).

31. Web Services also have some disadvantages • Overhead. Transmitting all data in XML is not as efficient as using a proprietary binary code. • What you win in portability, you lose in efficiency. • This overhead is usually acceptable for most applications, but you will probably never find a critical real-time application that uses Web Services. • Lack of versatility. Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. • CORBA, for example, offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc.) • Grid Services actually make up for this lack of versatility.

32. One important characteristic that distinguishes Web Services • While technologies such as CORBA and EJB are oriented toward highly coupled distributedsystems, where the client and the server are very dependent on each other • Web Services are oriented towards loosely coupled systems, where the client might have no prior knowledge of the Web Service until it actually invokes it.

33. A Typical Web Service Invocation • First step will be tofind a Web Service that meets our requirements: contact a UDDI registry. • The UDDI registry will reply, telling what servers can provide the service required. • the location of a Web Service is now known, but the actually invocation method is still unknown. The second step is to ask the Web Service to describeitself • The Web Service replies using WSDL. • The Web Service is located and invocation method is known. The invocation is done using SOAP (a SOAP request is sent asking for the needed information. • The Web Service will reply with a SOAP response which includes the information we asked for, or an error message if our SOAP request was incorrect

34. Web Services Addressing • At one point, the UDDI registry tells the client where the Web Service is located. But, how exactly are Web Services addressed? • The answer is very simple: just like web pages. We use plain and simple URIs (Uniform Resource Identifiers). For example, the UDDI registry might have replied with the following URI: http://webservices.mysite.com/weather/us/WeatherService • This could easily be the address of a web page. • However, remember that Web Services are always used by software (never directly by humans). • When you have a Web Service URI, you will usually need to give that URI to a program. In fact, most of the client programs we will write will receive the Grid Service URI as a command-line argument.

35. Web Services Architecture • Service Discovery • Service Description • Service Invocation • Transport

36. What a Web Service Application Looks Like

37. What a Web Service Application Looks Like • The client application invoke the Web Service, by calling the client stub. The client stub will turn this 'local invocation' into a proper SOAP request. • The SOAP request is sent over a network using the HTTP protocol. The Web Services container receives the SOAP requests and hands it to the server stub. The server stub converts the SOAP request into something the service implementation can understand • The service implementation receives the request from the service stub, and carries out the work it has been asked to do. • The result of the requested operation is handed to the server stub, which turns it into a SOAP response. • The SOAP response is sent over a network using the HTTP protocol. The client stub receives the SOAP response and turns it into something the client application can understand. • Finally the application receives the result of the Web Service invocation and uses it

38. What a Web Service Application Looks Like • Despite having a lot of protocols and languages floating around, Web Services programmers usually never write a single line of SOAP or WSDL. • Once we've reached a point where our client application needs to invoke a Web Service, we delegate that task on a piece of software called a client stub. • The good news is that there are plenty of tools available that will generate client stubs automatically for us, usually based on the WSDL description of the Web Service. • A Web Services client doesn't usually do all those steps in a single invocation. A more correct sequence of events would be the following: • We locate a Web Service that meets our requirements through UDDI. • We obtain that Web Service's WSDL description. • We generate the stubs once, and include them in our application. • The application uses the stubs each time it needs to invoke the Web Service.

39. Programming the server • Implement all the functionality of our Web Service • Generate a server stub • server stub can be generated from a WSDL description or from other interface definition languages (such as IDL). • Charge of interpreting requests and forwarding them to the service implementation • generate the appropriate SOAP response Note: Both the service implementation and the server stubs are managed by a piece of software called the Web Service container, which will make sure that incomingHTTP requests intended for a Web Service are directed to the server stub.

40. Web services Framework • Simple Object Access Protocol (SOAP) • Web Service Description Language (WSDL) support a service interface definition that is distinct from the protocol bindings used for service invocation • WS-Inspection mechanisms for registering, discovering interface, endpoint implementation description and for dynamically generating proxies based on bindings for specific interfaces.

41. References • Paul A Moore “Characteristics of a Service Oriented Architecture”, www.iryx.com • David S. Linthicum “12 Steps to Implementing a Service Oriented Architecture” www.grandcentral.com • Dan Gisolfi “Web services architect, Part 1: An introduction to dynamic e-business” www.us/ibm.com • Dan Gisolfi “Web services architect, Part 2: An introduction to dynamic e-business” www.us/ibm.com • Sotomayor “Web service Tutorial” http://www.casa-sotomayor.net/gt3tutorial/core/service_data/sd_ogsa.html