Introduction to Grid Computing, Lecture 2.1

396 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
396
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Strategically, the objective is to build a new architecture that will yield all the value hoped for, but tactically, the existing systems must be integrated such that, over time, they can be componentized or replaced in manageable, incremental projects. User Interaction -- being able to provide a single, interactive user experience Application Connectivity -- communications layer that underlies all of the architecture Process Integration -- choreographs applications and services Information Integration -- federates and moves the enterprise data Build to Integrate -- builds and deploys new applications and services
  • this will enable one of the most critical aspects of developing the architecture: the ability to produce incremental ROI. Countless integration projects have failed due to their complexity, cost, and unworkable implementation schedules
  • The service may be within the same application, or in a different address space within an asymmetric multiprocessor, on acompletely different system within the corporate Intranet, or within an application in a partner's system used in a B2B configuration.
  • Security -- authorization of the request, encryption and decryption as required, validation, etc. 2. Deployment -- allowing the service to be redeployed (moved) around the network for performance, redundancy for availability, or other reasons 3. Logging -- for auditing, metering, etc. 4. Dynamic rerouting -- for fail over or load balancing 5. Maintenance -- management of new versions of the service
  • We will look at the two separately, and then propose a single view of an SOA by combining them.
  • Content Aggregation  An examples of such entities would be an internet portal or information service provider. Service Aggregation An example of such an entity would be a mobile portal the likes of OnStar (www.onstar.com)
  • A fundamental aspect of a successful implementation is the reliance on open Internet standards.
  • 1. since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux. 2. This is a major advantage if you want to build an Internet-scale application, since most of the Internet's proxies and firewalls won't mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls)
  • - Highly coupled systems are ideal for intranet applications, but perform poorly on an Internet scale. - Web Services, however, are better suited to meet the demands of an Internet-wide application, such as grid-oriented applications.
  • 1. A client may have no knowledge of what Web Service it is going to invoke. So, our first step will be to find a Web Service that meets our requirements. For example, we might be interested in locating a public service. We'll do this by contacting a UDDI registry. 2. The UDDI registry will reply, telling us what servers can provide us the service we require. We now know the location of a Web Service, but we have no Idea of how to actually invoke it., but what is the actual service invocation? The method I have to invoke can have any name and any number of arguments We have to ask the Web Service to describe itself (i.e. tell us how exactly we should invoke it) 4. The Web Service replies in a language called WSDL. 5. We finally know where the Web Service is located and how to invoke it. The invocation itself is done in a language called SOAP. Therefore, we will first send a SOAP request asking for the temperature of a certain city. 6. The Web Service will kindly reply with a SOAP response which includes the infomration we asked for, or maybe an error message if our SOAP request was incorrect
  • We have just seen a simple Web Service invocation. If you're more familiar with the term URL (Uniform Resource Locator), don't worry: URI and URL are practically the same thing.
  • Service Discovery: This part of the architecture allows us to find Web Services which meet certain requirements. This part is usually handled by UDDI (Universal Description, Discovery, and Integration). GT3 currently doesn't include support for UDDI. Service Description : One of the most interesting features of Web Services is that they are self-describing. This means that, once you've located a Web Service, you can ask it to 'describe itself' and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL). Service Invocation : Invoking a Web Service (and, in general, any kind of distributed service such as a CORBA object or an Enterprise Java Bean) involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responds. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the
  • 1. Whenever the client application needs to invoke the Web Service, it will actually call the client stub. The client stub will turn this 'local invocation' into a proper SOAP request. This is often called the marshalling process. 2. 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 will convert the SOAP request into something the service implementation can understand (this is usually called unmarshalling ) 3. The service implementation receives the request from the service stub, and carries out the work it has been asked to do. For example, if we are invoking the int add(int a, int b) method, the service implementation will perform an addition. 4. The result of the requested operation is handed to the server stub, which will turn it into a SOAP response. 5. 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. 6. Finally the application receives the result of the Web Service invocation and uses it
  • 1. This is often called the marshalling process. 2. (this is usually called unmarshalling ) 3. For example, if we are invoking the int add(int a, int b) method, the service implementation will perform an addition
  • Despite having a lot of protocols and languages floating around, Web Services programmers usually never write a single line of SOAP or WSDL. If you've ever programmed with CORBA or RMI, this structure will look pretty familiar.
  • Programming the server side is just as easy. We don't have to write a complex server program which dynamically interprets SOAP requests and generates SOAP responses. We can simply implement all the functionality of our Web Service, and then generate a server stub (the term skeleton is also used) which will be in charge of interpreting requests and fowarding them to the service implementation. When the service implementation obtains a result, it will give it to the server stub, which will generate the appropriate SOAP response. The server stub can also be generated from a WSDL description, or from other interface definition languages (such as IDL). Furthermore, 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 incoming HTTP requests intended for a Web Service are directed to the server stub.
  • WSDL Multiple bindings for a single interface, including distributed communication protocol as well as locally optimized bindings.
  • Introduction to Grid Computing, Lecture 2.1

    1. 1. A service Oriented Architecture & Web Service Technology
    2. 3. The case for developing SOA <ul><li>Level of Software complexity continues to increase, and traditional architectures seem to be reaching the limit of their ability </li></ul><ul><li>Need to respond quickly to new requirements of the business </li></ul><ul><li>Need to continually reduce the cost of IT to the business </li></ul><ul><li>Ability to absorb and integrate new business partners and new customer sets </li></ul>
    3. 4. Problems <ul><li>Cumulative effect of decades of growth and evolution has produced severe complexity </li></ul><ul><li>Redundant and non-reusable programming </li></ul><ul><li>Real integration killer - multiplicity of interfaces </li></ul>
    4. 5. Requirement for a SOA <ul><li>Leverage existing assets. </li></ul><ul><ul><li>Existing systems can rarely be thrown away, and often contain within them great value to the enterprise. </li></ul></ul><ul><li>Support all required types of integration . </li></ul><ul><ul><li>User Interaction </li></ul></ul><ul><ul><li>Application Connectivity </li></ul></ul><ul><ul><li>Process Integration </li></ul></ul><ul><ul><li>Information Integration </li></ul></ul><ul><ul><li>Build to Integrate </li></ul></ul>
    5. 6. Requirement for a SOA <ul><li>Allow for incremental implementations & migration of assets </li></ul><ul><li>Include a development environment that will be built </li></ul><ul><ul><li>around a standard component framework, </li></ul></ul><ul><ul><li>promote better reuse of modules and systems , </li></ul></ul><ul><ul><li>allow legacy assets to be migrated to the framework, </li></ul></ul><ul><ul><li>allow for the timely implementation of new technologies. </li></ul></ul><ul><li>Allow implementation of new computing models ; </li></ul><ul><ul><li>specifically, new portal-based client models , Grid computing , and on-demand computing </li></ul></ul>
    6. 7. A service-oriented architecture -- not just Web services <ul><li>First, though, it must be understood that Web services does not equal service-oriented architecture . </li></ul><ul><li>Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI, </li></ul><ul><li>SOA is &quot;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&quot;. </li></ul>
    7. 8. A service-oriented architecture -- not just Web services <ul><li>All functions are defined as services. </li></ul><ul><li>All services are independent. </li></ul><ul><ul><li>Operate as &quot;black boxes&quot;; </li></ul></ul><ul><ul><ul><li>external components neither know nor care how boxes are executed </li></ul></ul></ul><ul><ul><ul><li>merely that they return the expected result . </li></ul></ul></ul><ul><li>The interfaces are invocable; </li></ul><ul><ul><li>At an architectural level, it is irrelevant whether </li></ul></ul><ul><ul><ul><li>they are local or remote </li></ul></ul></ul><ul><ul><ul><li>what interconnect scheme or protocol is used to effect the invocation, </li></ul></ul></ul><ul><ul><ul><li>what infrastructure components are required to make the connection . </li></ul></ul></ul>
    8. 9. A service-oriented architecture -- not just Web services <ul><li>Interface is the key, & the focus of the calling application. </li></ul><ul><ul><li>It defines the required parameters and the nature of the result </li></ul></ul><ul><li>It is the system's responsibility to effect and manage the invocation of the service, </li></ul><ul><li>This allows two critical characteristics to be realized: </li></ul><ul><ul><li>Services are truly independent, </li></ul></ul><ul><ul><li>they can be managed. Management includes many functions, including: Security, Deployment , Logging, Dynamic rerouting,and Maintenance </li></ul></ul>
    9. 10. The Nature of a Service <ul><li>Typically within a business environment </li></ul><ul><ul><li>Service means business functions , business transactions , and system services . </li></ul></ul><ul><li>The difference in the types of services. </li></ul><ul><ul><li>Business functions are from the application's perspective , non-system functions that are effectively atomic. </li></ul></ul><ul><ul><li>Services might be low-level or complex high-level (fine-grained or course grained) functions </li></ul></ul>
    10. 11. An SOA - Constituent Parts <ul><li>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. </li></ul><ul><li>The idea that SOA encapsulates both design-time and run-time is critical to understanding SOA </li></ul><ul><ul><li>SOA is really about both physical and logical architectures. </li></ul></ul>
    11. 12. SOA Design-time requirements <ul><li>UDDI directory of External web services </li></ul><ul><ul><li>provides the definition of a set of services </li></ul></ul><ul><ul><li>a directory of external web services already being used by the enterprise. </li></ul></ul><ul><li>Directory of Enterprise Internal web services </li></ul><ul><ul><li>internal directory indicates whether the web service is externally available </li></ul></ul><ul><ul><li>re-use available web services when designing new business processes. </li></ul></ul><ul><li>Agile Design Methodology </li></ul><ul><ul><li>methodology which is oriented towards re-use, </li></ul></ul><ul><ul><li>methodology needs to emphasize the requirement for cross-project information and working. </li></ul></ul>
    12. 13. SOA Design-time requirements <ul><li>Process Driven Development </li></ul><ul><ul><li>based upon the modeling or re-modeling of business processes. </li></ul></ul><ul><ul><li>The start point should be the expansion or re-working of the set of modeled business processes. </li></ul></ul><ul><li>Workflow Oriented Development </li></ul><ul><ul><li>One of the key paradigms for SOA development is that the business processes are seamless </li></ul></ul><ul><ul><li>Each step in each process should be linked, as an automatic next step </li></ul></ul><ul><li>Multi-level Design Management </li></ul><ul><ul><li>Design management must be based primarily on the business objectives each project is to deliver </li></ul></ul>
    13. 14. SOA Design-time requirements <ul><li>Agile Toolset For SOA Development </li></ul><ul><ul><li>abstraction of existing functionality into new web services </li></ul></ul><ul><ul><li>minimize coding, Ability to plug in existing middleware, </li></ul></ul><ul><li>Information Routing Modeling </li></ul><ul><ul><li>incorporates the need to integrate & deliver information and to deliver to the right people at the right time. </li></ul></ul><ul><ul><li>SOA solution must also be able to model the flows of information across the enterprise and the extended supply chain. </li></ul></ul><ul><li>Debugging And Simulation Capability </li></ul><ul><li>Multi-Language Capability </li></ul>
    14. 15. SOA – Run-time requirements <ul><li>Consolidated Process Management </li></ul><ul><ul><li>ability to present transactional and information flows visually by business process, organizational unit and server. </li></ul></ul><ul><li>Process Oriented Monitoring & Administration Tools </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Business Activity Monitoring (BAM) </li></ul><ul><ul><li>SOA tool-set should include BAM capability; the run-time environment should feed data to the BAM module. </li></ul></ul>
    15. 16. SOA – Run-time requirements <ul><li>Persistence Of Message-Based Asynchronous Process Data </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Scalability Of The Environment </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Resilience </li></ul><ul><ul><li>must provide sufficient resilience to support the business </li></ul></ul><ul><li>User Access And Security </li></ul><ul><ul><li>SOA solution offers 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 . </li></ul></ul>
    16. 17. SOA – Run-time requirements <ul><li>Workflow </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Event driven </li></ul><ul><ul><li>The link between processes (or between a process and the external world) will often be in the form of an event. </li></ul></ul><ul><li>Simulation capability </li></ul><ul><ul><li>The ability to simulate traffic across any process is very useful when reviewing performance and scalability questions. </li></ul></ul><ul><li>Error Management </li></ul><ul><ul><li>A key criterion for any SOA run-time environment is its error management. The criteria for error management are; </li></ul></ul><ul><ul><li>Visibility of errors, Re-start capability, Error notification, Workflow linking </li></ul></ul>
    17. 18. SOA Model <ul><li>A service provider </li></ul><ul><ul><li>provides a service interface for a software asset that manages a specific set of tasks. </li></ul></ul><ul><li>A service requester </li></ul><ul><ul><li>discovers and invokes other software services to provide a business solution.. </li></ul></ul><ul><li>A service broker ; </li></ul><ul><ul><li>acts as a repository, yellow pages, or clearing house for software interfaces that are published by service providers. </li></ul></ul>
    18. 19. Service Requester <ul><li>Content Aggregation </li></ul><ul><ul><li>Activity where an entity interacts with a variety of content providers to process/reproduce such content in the desired presentation format of its customers. </li></ul></ul><ul><li>Service Aggregation </li></ul><ul><ul><li>Activity where an entity interacts with a variety of service providers to re-brand , host , or offer a composite of services to its customers. </li></ul></ul>
    19. 20. Service Provider <ul><li>Independent software vendors are prime examples of potential service providers. </li></ul><ul><ul><li>They own and maintain a software asset that performs tasks. </li></ul></ul><ul><ul><li>Software assets could be made available as an aggregation of services or broken down into distinctly separate software service resources. </li></ul></ul><ul><li>Processes that are proven and generalized for a diverse set of applications would be good candidates for service providers. </li></ul><ul><ul><li>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. </li></ul></ul>
    20. 21. Registry <ul><li>Is an entity that collects and catalogs data about other entity and then providing that data to others (a form of SOA Broker.) </li></ul><ul><li>Usually, a registry would collect data such as </li></ul><ul><ul><li>Entity name, </li></ul></ul><ul><ul><li>Description, and contact information. </li></ul></ul>In UDDI terms, this Registry role is often referred to as the White Pages .
    21. 22. Enabling technologies <ul><li>XML: The Extensible Markup Language </li></ul><ul><li>SOAP: </li></ul><ul><ul><li>Simple Object Access Protocol is an XML-based lightweight protocol for the exchange of information in a decentralized, </li></ul></ul><ul><li>WSDL: </li></ul><ul><ul><li>The Web Services Description Language is an XML vocabulary that provides a standard way of describing service IDLs. </li></ul></ul><ul><li>UDDI: </li></ul><ul><ul><li>The Universal Description, Discovery, and Integration specification provides a common set of SOAP APIs that enable the implementation of a service broker. </li></ul></ul>
    22. 23. 12 Steps to implement a SOA <ul><li>Understand the functional objectives and define success. </li></ul><ul><li>Define your problem domain. </li></ul><ul><li>Understand all application semantics in your domain. </li></ul><ul><li>Understand all services available in your domain. </li></ul><ul><li>Understand all information sources and sinks available in your domain. </li></ul><ul><li>Understand all processes in your domain. </li></ul>
    23. 24. 12 Steps to implement a SOA <ul><li>Identify and catalog all interfaces outside of the domain you must leverage (services and simple information). </li></ul><ul><li>Define new services/information bound to the services. </li></ul><ul><li>Define new processes, services, and information bound to the processes. </li></ul><ul><li>Select your technology set. </li></ul><ul><li>Implement & Deploy SOA technology. </li></ul><ul><li>Test and evaluate </li></ul>
    24. 25. Web Service
    25. 26. What a Web Service in a Few Words? <ul><li>Web Services are the basis for Grid Services, which are the cornerstones of OGSA and OGSI. </li></ul><ul><ul><li>Understanding the Web Services architecture is fundamental to using GT3.X and GT4.X and programming Grid Services </li></ul></ul><ul><li>What exactly are Web Services? </li></ul><ul><ul><li>To put it quite simply, they are yet another distributed computing technology (like CORBA, RMI, EJB, etc.) They allow to create client/server applications. </li></ul></ul>http://www.casa-sotomayor.net/gt3-tutorial/core/service_data/sd_ogsa.html
    26. 27. Web Service <ul><li>The clients (the PCs at the store) </li></ul><ul><ul><li>contact the Web Service in the server </li></ul></ul><ul><ul><li>send a service request asking for the catalog </li></ul></ul><ul><ul><li>The server returns the catalog through a service response . </li></ul></ul><ul><li>This is a very sketchy example of how a Web Service works. </li></ul>
    27. 28. Web Services have certain advantages over other technologies <ul><li>Why cannot we use RMI, CORBA, EJBs, and countless other technologies. </li></ul><ul><ul><li>So, what makes Web Services special? </li></ul></ul><ul><li>Web Services are platform-independent and language-independent (standard XML) </li></ul><ul><li>Most Web Services use HTTP for transmitting messages (such as the service request and response). </li></ul>
    28. 29. Web Services also have some disadvantages <ul><li>Overhead. Transmitting all data in XML is not as efficient as using a proprietary binary code. </li></ul><ul><ul><li>What you win in portability , you lose in efficiency . </li></ul></ul><ul><ul><li>This overhead is usually acceptable for most applications, but you will probably never find a critical real-time application that uses Web Services. </li></ul></ul><ul><li>Lack of versatility. Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. </li></ul><ul><ul><li>CORBA offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc.) </li></ul></ul><ul><ul><li>Grid Services actually make up for this lack of versatility . </li></ul></ul>
    29. 30. One important characteristic that distinguishes Web Services <ul><li>While technologies such as CORBA and EJB are oriented toward highly coupled distributed systems , where the client and the server are very dependent on each other </li></ul><ul><li>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. </li></ul>
    30. 31. A Typical Web Service Invocation <ul><li>First step will be to find a Web Service that meets our requirements: contact a UDDI registry. </li></ul><ul><li>The UDDI registry will reply, telling what servers can provide the service required . </li></ul><ul><li>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 describe itself </li></ul><ul><li>The Web Service replies using WSDL . </li></ul><ul><li>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. </li></ul><ul><li>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 </li></ul>
    31. 32. Web Services Addressing <ul><li>At one point, the UDDI registry tells the client where the Web Service is located. But, how exactly are Web Services addressed? </li></ul><ul><ul><li>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: </li></ul></ul><ul><ul><ul><li>http://webservices.mysite.com/weather/us/WeatherService </li></ul></ul></ul><ul><li>This could easily be the address of a web page. </li></ul><ul><ul><li>However, remember that Web Services are always used by software (never directly by humans). </li></ul></ul><ul><ul><li>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. </li></ul></ul>
    32. 33. Web Services Architecture <ul><li>Service Discovery </li></ul><ul><li>Service Description </li></ul><ul><li>Service Invocation </li></ul><ul><li>Transport </li></ul>
    33. 34. What a Web Service Application Looks Like
    34. 35. What a Web Service Application Looks Like <ul><li>Client application invoke the Web Service, by calling the client stub. </li></ul><ul><ul><li>The client stub will turn this 'local invocation' into a proper SOAP request . </li></ul></ul><ul><li>The SOAP request is sent over a network using the HTTP protocol . </li></ul><ul><ul><li>WS container receives the SOAP requests & hands it to the server stub. </li></ul></ul><ul><ul><li>The server stub converts the SOAP request into something the service implementation can understand </li></ul></ul><ul><li>The service implementation receives the request from the service stub, and carries out the work it has been asked to do. </li></ul><ul><li>The result of the requested operation is handed to the server stub, which turns it into a SOAP response . </li></ul><ul><li>The SOAP response is sent over a network using the HTTP protocol . </li></ul><ul><ul><li>The client stub receives the SOAP response and turns it into something the client application can understand. </li></ul></ul><ul><li>The application receives the result of the Web Service invocation </li></ul>
    35. 36. What a Web Service Application Looks Like <ul><li>Web Services programmers usually never write a single line of SOAP or WSDL. </li></ul><ul><li>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 . </li></ul><ul><ul><li>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 . </li></ul></ul><ul><li>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: </li></ul><ul><ul><li>We locate a Web Service that meets our requirements through UDDI. </li></ul></ul><ul><ul><li>We obtain that Web Service's WSDL description . </li></ul></ul><ul><ul><li>We generate the stubs once , and include them in our application. </li></ul></ul><ul><ul><li>The application uses the stubs each time it needs to invoke the Web Service . </li></ul></ul>
    36. 37. Programming the server <ul><li>Implement all the functionality of our Web Service </li></ul><ul><li>Generate a server stub </li></ul><ul><ul><ul><li>server stub can be generated from a WSDL description or from other interface definition languages (such as IDL). </li></ul></ul></ul><ul><ul><ul><li>Charge of interpreting requests and forwarding them to the service implementation </li></ul></ul></ul><ul><ul><ul><li>generate the appropriate SOAP response </li></ul></ul></ul><ul><li>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 incoming HTTP requests intended for a Web Service are directed to the server stub. </li></ul>
    37. 38. Web services Framework <ul><li>Simple Object Access Protocol (SOAP) </li></ul><ul><li>Web Service Description Language (WSDL) </li></ul><ul><ul><li>support a service interface definition that is distinct from the protocol bindings used for service invocation </li></ul></ul><ul><li>WS-Inspection </li></ul><ul><ul><li>mechanisms for registering, discovering interface, endpoint implementation description and for dynamically generating proxies based on bindings for specific interfaces. </li></ul></ul>

    ×