JavaPerformanceChapter_11
•
0 likes•14 views
This document discusses strategies for optimizing web services performance. It covers topics like XML performance, using the appropriate XML parsing API, validating XML efficiently, optimizing external entity resolution, partial XML processing, web service benchmarking, factors affecting performance like message size and schema complexity, and best practices such as using MTOM, custom providers, and Fast Infoset.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to JavaPerformanceChapter_11
Similar to JavaPerformanceChapter_11 (20)
More from Saurav Basu
Recently uploaded
Recently uploaded (20)
JavaPerformanceChapter_11
- 1. Java Performance Chapter 11 1 Saurav Basu 20/3/2020
- 2. Organization 1. Strategies, Approaches, and Methodologies 2. Operating System Performance Monitoring 3. JVM Overview 4. JVM Performance Monitoring 5. Java Application Profiling 6. Java Application Profiling - Tips & Tricks 7. Tuning the JVM - Step by Step 8. Benchmarking Java Applications 9. Benchmarking Multitiered Applications 10. Web Application Performance 11. Web Services Performance 12. Java Persistence & Enterprise Java Beans Performance 2
- 3. Web Services Performance 3 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 4. Web Services Performance 4 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 5. Web Services Performance 5 XML Performance XML Processing LifeCycle JAVA API for XML Processing (JAXP) JAVA API for XML Binding (JAXB) Simple API for XML (SAX) Document Object Model(DOM) Streaming API for XML (StAX)
- 6. Web Services Performance 6 XML Performance XML Processing LifeCycle
- 7. Web Services Performance 7 XML Performance Parse/Unmarshall Not thread safe
- 8. Web Services Performance 8 XML Performance Parse/Unmarshall Not thread safe
- 9. Web Services Performance 9 XML Performance Parse/Unmarshall
- 10. Web Services Performance 10 XML Performance Parse/Unmarshall 1. (SAX and DOM): Create Pool of Parser Instances for reuse 2. JAXB: Create pool of unmarshaller instances for reuse Not thread safe
- 11. Web Services Performance 11 XML Performance Access DOM JAXB SAX StAX In Memory Cache Streaming Parsers
- 12. Web Services Performance 12 XML Performance Modify (DOM API) 1. Check hasAttribute before fetching attribute List to prevent unnecessary creation of AttributeMap 2. Method getElementByTagName and getElementByTagNameNS are expensive. Implement Custom traversal to search specific part of DOM tree 3. Set strictErrorChecking to false to prevent unnecessary error Checks 4. Disable deferNodeExpansion on small documents to prevent the use of compact representation for small documents 5. Use adoptNode to prevent copying of node when moving a subtree from one document to another
- 13. Web Services Performance 13 XML Performance Serialize/Marshall XMLStreamWriter (StAX) Transformer (DOM) Marshaller (JAXB)
- 14. Web Services Performance 14 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 15. Web Services Performance 15 Validation (Best Practices) 1. Turning on validation significantly reduces parser performance 1. Use Schema caching if application has to validate against a limited set of schemas
- 16. Web Services Performance 16 Validation Compile Schemas to use Schema caching
- 17. Web Services Performance 17 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 18. Web Services Performance 18 Resolving External Entities
- 19. Web Services Performance 19 Resolving External Entities
- 20. Web Services Performance 20 Resolving External Entities Catalog File Sample CatalogManager.PropertiesFile
- 21. Web Services Performance 21 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 22. Web Services Performance 22 Partial Processing of XML Documents
- 23. Web Services Performance 23 Partial Processing of XML Documents
- 24. Web Services Performance 24 Partial Processing of XML Documents
- 25. Web Services Performance 25 Partial Processing of XML Documents
- 26. Web Services Performance 26 Partial Processing of XML Documents
- 27. Web Services Performance 27 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 28. Web Services Performance 28 Selecting the Right API
- 29. Web Services Performance 29 Selecting the Right API
- 30. Web Services Performance 30 Selecting the Right API
- 31. Web Services Performance 31 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 32. Web Services Performance 32 JAX-WS Stack
- 33. Web Services Performance 33 JAX-WS Stack Data Processing Cost (JAX-WS) Application Message Process Cost Request Processing Cost(WebContainer) Network Performance Total Cost Minimal
- 34. Web Services Performance 34 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 35. Web Services Performance 35 Web Service Benchmarking 1. Message Payload 2. Web Service Operation 3. Client Driver
- 36. Web Services Performance 36 Web Service Benchmarking 1. Message Payload 2. Web Service Operation 3. Client Driver
- 37. Web Services Performance 37 Web Service Benchmarking Message Payload
- 38. Web Services Performance 38 Web Service Benchmarking 1. Message Payload 2. Web Service Operation 3. Client Driver
- 39. Web Services Performance 39 Web Service Benchmarking Web Service Operation
- 40. Web Services Performance 40 Web Service Benchmarking 1. Message Payload 2. Web Service Operation 3. Client Driver
- 41. Web Services Performance 41 Web Service Benchmarking Sno. Thick Client Thin Client 1 Easy to Implement Harder to Implement 2 Measure JAX WS Perf at both client and server Measure JAX WS Perf on server 3 Can handle application fault Can handle http error code 4 Represents real life use case Represents scalability test scenario 5 Powerful client system is required Client system processing is minimal
- 42. Web Services Performance 42 Web Service Benchmarking
- 43. Web Services Performance 43 Web Service Benchmarking
- 44. Web Services Performance 44 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 45. Web Services Performance 45 Factors that affect Web Service Performance 1. Message Size 2. Complexity of Schema 3. Implementation of endPoint 4. Presence of handlers
- 46. Web Services Performance 46 Factors that affect Web Service Performance 1. Message Size 2. Complexity of Schema 3. Implementation of endPoint 4. Presence of handlers
- 47. Web Services Performance 47 Factors that affect Web Service Performance Message Size
- 48. Web Services Performance 48 Factors that affect Web Service Performance Message Size
- 49. Web Services Performance 49 Factors that affect Web Service Performance 1. Message Size 2. Complexity of Schema 3. Implementation of endPoint 4. Presence of handlers
- 50. Web Services Performance 50 Factors that affect Web Service Performance Complexity of Schema
- 51. Web Services Performance 51 Factors that affect Web Service Performance Complexity of Schema
- 52. Web Services Performance 52 Factors that affect Web Service Performance Complexity of Schema
- 53. Web Services Performance 53 Factors that affect Web Service Performance Complexity of Schema
- 54. Web Services Performance 54 Factors that affect Web Service Performance 1. Message Size 2. Complexity of Schema 3. Implementation of endPoint 4. Presence of handlers
- 55. Web Services Performance 55 Factors that affect Web Service Performance Implementation of endPoint
- 56. Web Services Performance 56 Factors that affect Web Service Performance 1. Message Size 2. Complexity of Schema 3. Implementation of endPoint 4. Presence of handlers
- 57. Web Services Performance 57 Factors that affect Web Service Performance Handler Mechanism
- 58. Web Services Performance 58 Factors that affect Web Service Performance Handler Mechanism
- 59. Web Services Performance 59 1. XML Performance 2. Validation 3. Resolving External Entities 4. Partial Processing of XML Documents 5. Selecting the Right API 6. JAX WS Implementation Stack 7. Web Services Benchmarking 8. Factors that affect Web Services Performance 9. Performance Best Practices
- 60. Web Services Performance 60 Performance Best Practices 1. Message Transmission Optimization Mechanism (MTOM) 2. Fast Infoset 3. Use of Providers
- 61. Web Services Performance 61 Performance Best Practices 1. Message Transmission Optimization Mechanism (MTOM) 2. Fast Infoset 3. Use of Providers
- 62. Web Services Performance 62 Performance Best Practices Without MTOM Base64 encoded
- 63. Web Services Performance 63 Performance Best Practices File Sent as Attachment MTOM
- 64. Web Services Performance 64 Performance Best Practices MTOM
- 65. Web Services Performance 65 Performance Best Practices MTOM
- 66. Web Services Performance 66 Performance Best Practices MTOM
- 67. Web Services Performance 67 Performance Best Practices 1. Message Transmission Optimization Mechanism (MTOM) 2. Use of Custom Providers 3. Fast Infoset
- 68. Web Services Performance 68 Performance Best Practices Custom Provider
- 69. Web Services Performance 69 Performance Best Practices Custom Provider JAX-WS is more efficient compared to custom providers
- 70. Web Services Performance 70 Performance Best Practices 1. Message Transmission Optimization Mechanism (MTOM) 2. Use of Providers 3. Fast Infoset
- 71. Web Services Performance 71 Performance Best Practices Fast Infoset
- 72. Web Services Performance 72 Performance Best Practices Fast Infoset
Editor's Notes
- Next we will talk about Web Services Performance
- Under this topic we will discuss XML Performance, Validation,Resolution of External Entities, Partial Processing of XML Documents,Selection of the right api,JAX WS Implementation Stack Web Services Benchmarking, Factors that affect Web Services Performance and Performance Best Practices
- First we will talk about XML Performance
- This slide describes APIs for XML processing in JAVA JAXP (Java API for XML Processing) JAXB (Java API for XML Binding) JAXP supports SAX DOM and StAX standards. JAXB allows developers to access and process XML documents as Java objects. The first step in the use of JAXB is to compile the XML schema representing the docu- ment to generate a set of Java classes. JAXB also provides a runtime that enables the easy conversion of XML documents to Java objects (unmarshalling) and Java objects to XML (marshalling)
- This slide describes the steps in xml processing lifecycle. Parse/Unmarshall. Scan the XML document processing elements and attributes and possibly build an in-memory tree in the case of a DOM parser or a Java object in JAXB. Parsing is a prerequisite for any processing of an XML document. Access. Extract the data from the elements and attributes of parts of the document into the application. For example, given an XML document for an invoice, the application might want to retrieve the prices for each item in the invoice. Modify. Change the textual content of elements or attributes and possibly also the structure of the document by inserting or deleting elements. This does not apply to SAX. As an example, an application might need to update the prices of some of the items in an invoice or insert or delete some items. Serialize/Marshall. Convert the in-memory representation to a textual form that is written to a disk file or forwarded to a network stream. SAX parser does not support this functionality
- This slide describes the steps in xml processing lifecycle. Parse/Unmarshall. Scan the XML document processing elements and attributes and possibly build an in-memory tree in the case of a DOM parser or a Java object in JAXB. Parsing is a prerequisite for any processing of an XML document. Access. Extract the data from the elements and attributes of parts of the document into the application. For example, given an XML document for an invoice, the application might want to retrieve the prices for each item in the invoice. Modify. Change the textual content of elements or attributes and possibly also the structure of the document by inserting or deleting elements. This does not apply to SAX. As an example, an application might need to update the prices of some of the items in an invoice or insert or delete some items. Serialize/Marshall. Convert the in-memory representation to a textual form that is written to a disk file or forwarded to a network stream. SAX parser does not support this functionality
- This slide describes the code to create a DOM parser
- This slide describes default factory implementation classes that can be customized. JAXP provides a pluggable architecture that allows users to plug-in different implementations. There are instances in which implementations from other ven- dors outperform the default implementation within JAXP. In such cases, it is a good practice to use the better performing implementation rather than the default one
- SAX and DOM Parser Creation is expensive and these parsers are not thread safe, so it is a good practice to create a pool of parser instances for reuse. For JAXB processing the context is first created followed by the Unmarshaller which is not thread safe. It is a good practice to create a pool of unmarshallers for reuse when processing a large number of small documents.
- DOM and JAXB create an in memory cache for acesss and require a higher memory usage than streaming parsers. In case memory is a constraint SAX and StAx parsers are appropriate chouce,
- DOM and JAXB create an in memory cache for acesss and require a higher memory usage than streaming parsers. In case memory is a constraint SAX and StAx parsers are appropriate chouce,
- The serializer classes, XMLStreamWriter (StAX), Transformer (DOM), and Marshaller (JAXB), are created through the use of factory as in the case of parsers or JAXBContext objects in the case of JAXB. When working with small documents creating a pool of writers or marshallers improves application performance
- Next we will talk about validation of XML
- Points to keep in mind when using validation of xml schema.
- Example of using validation to validate documents against a xsd in SAX
- Next we will talk about resolution of external entities
- Loading of external enttities over slow network slows the performance of XML schemas XML Catalogs provide a way for your application to use local copies of these artifacts without modifying the XML instance document by mapping external references to local resources. The application then uses a resolver that consults the cata-log to resolve the external references Example of using code to resolve external entities
- Example of using code to resolve external entities
- The catalog resolver uses one or more catalog entry files to resolve the references that it encounters. A catalog entry file is made up of a number of catalog entries. A sample catalog file is shown in this slide. Two methods can be used to specify how the CatalogResolver can find the catalog files to be used. Set the system property xml.catalog.files to a semicolon-separated list of catalog entry files (e.g., -Dxml.catalog.files=catalogs/ cat1.xml;catalogs/cat2.xml) or add the CatalogManager.properties file to the classpath The relative-catalogs attribute may seem a little counterintuitive; a value of true means that the paths are left unchanged and any relative path will be relative to where the JVM was started. A value of false on the other hand means that the files are relative to the location of the CatalogManager.properties file
- Next we will talk about partial processing of XML Documents
- The given code snippet shows how the Load and Save APIs can be used to load a selected node into the DOM tree. In this example, an invoice document containing several nodes, including a Summary node is parsed. The filter is set up to skip all nodes except the Summary node
- NOte the special casing code to accept only Summary element nodes
- Filter XML code continued
- The following code snippet shows how JAXB can be used along with a SAX parser to bind only a small portion of the document. In this example, we parse an invoice document and bind only the Summary element
- Code snippet continued
- Next we will talk about Selection of the right API
- Use streaming parsers for processing large documents or if only a small portion of the document is accessed. The default StAX parser typically outperforms the default SAX parser.
- The DOM and JAXB performance is significantly lower than that of SAX and StAX even when the entire document is scanned Use in-memory parsers, DOM or JAXB, if random access of elements is required. Creation of JAXB objects tends to be more expensive than creating the equivalent DOM tree , but itis cheaper to navigate the JAXB object once it has been built. Use JAXB if random access of multiple elements is involved.
- Figure in this slide shows the performance impact of serializing the in-memory docu- ment to an output stream. The set of bars on the left represents the cost of building the in-memory representation as well as traversing the entire document. The bars on the right include the additional expense of serialization of the document into an in-memory output stream. The JAXB serialization performs better than DOM seri- alization. In cases where the in-memory object is required to be converted back to XML, JAXB is a better choice JAXB marshalling performance is superior to DOM serialization
- Next we will talk about the JAX WS Implementation stack
- Figure in this slide shows the different layers within the JAX-WS runtime at the client and the server. In a typical SOAP request-response message exchange, the client invokes the service endpoint of the Web service deployed at the server and receives a response back from the server At the client side, the application delegates the responsibility of the Web service invocation to the JAX-WS implementation. JAX-WS runtime creates the SOAP envelope uses JAXB to marshall the Java objects to XML, and the appropriate payload is writ- ten to the network buffer to be sent to the server. The server first reads the payload from the networkstream, selects the right decoder—SOAP decoder in the case of SOAP messages— parses the payload, processes the headers as required, and passes the SOAP body toJAXB to unmarshall the XML to the appropriate Java objects, and the right method in the endpoint implemented by the application is invoked. The response from the server to the client traces a similar path through the stack but in the other direction
- Web Service Performance is contributed by :- Request Processing Cost of Web container Network Performance Cost of processing the message by Jax-WS Application Cost of processing the message If it is assumed that application cost is minimal then bulk of the cost is due to the data processing cost of the JAX-WS stack.
- Next we will talk about Web Service benchmarking
- We will discuss 3 aspects of Web Service benchmaks namely Mesage payload WebService Operation Type of Client Driver
- First we will talk about message payload
- Best practice regarding message payload size
- Next we will talk about Web Service Operation
- Best practice regarding web service operation for benchmarking
- Next we will talk about Client Driver
- This slide shows differences between thick client and thin client webservice benchmarks
- This slide shows webservice benchmark in thin client mode. In the thin client mode, a simple HTTP driver is used to deliver the SOAP message to the Web service endpoint as shown in this slide The HTTP driver is a simple client that posts the message to the server and receives the response. In its simplest form, the driver assumes that the Web service is fully functional, checking only the HTTP response code and discarding the return message.
- This slide shows webservice benchmark in thick client mode. Web service invocation from a thick client to a server traverses the JAX-WS stack on both the client and the server, and the overall response time for the invocation includes the processing time at the client and the server. In this case, both the client and the server should be considered to be part of the system under test (SUT)
- Next we will talk about factors that affect Web Service benchmarking
- Under this section we will talk about Message size, Complexity of schema, Implementation of endpoint and the presence of handlers
- Firs we will talk about Message size
- Slide shows variation of throughput in terms of transaction with varying message size.
- Slide shows variation of normalized throughput with message size. In this case maximum throughput is achieved for a message size of 250KB. (It is important to keep in mind that this number depends on the network bandwidth)
- Next we will talk about Complexity of schema
- Web service performance is greatly influenced by the choice of message schema. Figure in this sl shows the comparative performance of echoing an array of 100 elements comprised of a single schema type, and observing the effect of changing the schema type of this array
- Figure in slide shows the performance of three different schema.time, date, and dateTime. The use of dateTime is the most expensive, followed by date. The marshalling/unmarshalling cost and the varying size of the serialized XML message are the reasons why the performance differs among these three types.
- The last schema type that is discussed in this section is the any type. The mapping of any is dependent on the processContents attribute. An any element with processContents=”skip” allows the user to bind any well-formed XML to a DOM Element interface. Slide shows an example of a schema and the associated mapping
- Figure in slide compares the performance of sending and receiving a 100 kilobyte UBL invoice document as either a JAXB object mapped using a schema or a DOM Element mapped using any. In this example, the throughput for the test using any is about 35% of that using an object defined in the schema
- Next we will talk about Implementation of the endpoint of the webservice
- Figure in slide compares the performance between two similar Web services, one implemented with an EJB endpoint and the other with a Servlet endpoint. The performance of the EJB endpoint is roughly two-thirds that of the Servlet endpoint
- Next we will talk about the presence of handlers
- Handlers provide an easy mechanism to access and modify inbound and outbound messages. They are easy to develop since a basic handler needs to implement just three methods: handleMessage(), which is called for both inbound and outbound messages; handleFault(), to handle fault conditions; and close(), which is called at the end of the message invocation. The handlers can access the message via the MessageContext interface.
- The JAX-WS specification defines a specific protocol handler for the SOAP bind- ing, javax.xml.ws.handler.soap.SOAPHandler, which receives a SOAPMessage object. The SOAPMessage is based on DOM, which means that the entire message is loaded in memory as a DOM tree. In contrast, the JAX-WS RI without handlers works in a streaming fashion, which provides much better performance Logical handlers extend javax.xml.ws.handler.LogicalHandler and access the message payload through the LogicalMessage interface as either a Source or a JAXB object. In JAX-WS RI, the payload data is accessed as a DOMSource, which requires the creation of a DOM representation of the payload. This causes signifi- cant performance degradation as shown in this slide. Reading the payload as a JAXB object causes further degradation in performance due to the added expense of unmarshalling and marshalling of the object from a DOMSource
- Next we will talk about Performance Best practices for XML processing in webservices
- The 3 areas of discussion under performance best practices include Message Transmission Optimization Mechanism Fast Infoset Use of Providers
- Next we will talk about Message Transport Optimization Mechanism. MTOM provides an optimization for exchanging messages between SOAP nodes using an XOP-based selective encoding. This allows the binary blobs of type base 64Binary or hexBinary to be transmitted as MIME attachments in a way that is transparent to the application. Since the binary data is an attachment and not part of the XML payload, base64 encoding of the binary data is not required The binary attachment is packaged in a MIME multipart message. An <xop:include> element is used to mark where the binary data is. The actual binary data is kept in a different MIME part.
- This slide shows an example of the contents of a file encoded without the use of MTOM attribute.
- This slide shows the same data now sent as attachment For small messages, the setup cost associated with MTOM may be more than transmitting the data as encoded inline text. Experiments have shown that this limit is around 5–6 kilobytes
- This slide shows the encoding of data in MTOM enabled webservice inside a MIME envelope (Multipurpose Internet Mail Extensions )
- Figure in slide shows the data from a test case in which the server extracts just one element (located toward the beginning of the document) from an invoice. As expected, using the attachment mode for partial processing provides better performance compared to JAX-WS. The performance difference increases as the payload size increases, since JAX-WS has to parse and bind larger amounts of data to create the required JAXB object for the bigger payload
- Figure in slide shows the comparative performance of a client making a direct Web service invocation versus sending the document as an attachment where the entire document is traversed using a StAX parser. The tests were conducted for invoice documents of two different sizes, 5 kilobytes and 900 kilobytes. For small sized payloads, the performance between all three is comparable, whereas for large payloads, using attachments is a better performance option
- Next we will talk about Fast Infosets
- Figure in slide shows a sample Web service that processes the message payload as a source On arrival of a message, the invoke() method of the InvoiceProcessorService is called. Since we have specified the ServiceMode to be PAYLOAD, the SOAP Body is passed to the method (the entire SOAP message is delivered in the case of MES- SAGE). Once the payload is available as a Source, it can then be parsed using any XML parser
- Figure in slide compares JAX-WS performance to different types of providers: SourceSOAP is a Source based provider with SOAP binding and ServiceMode set to PAYLOAD, SourceHTTP is a Source based provider with ServiceMode set to PAYLOAD and BindingType set to HTTPBinding SOAPMessage is a SOAP Message based provider, Message is a Message based provider. The performance results were based on an echoMessage test in which the service receives an invoice document that is bound to a JAXB object and the same object is echoed back to client. The main reasons for poor performance of source based providers are the the inefficiencies involved in the interaction between the codec, the parser, and the binding layers.
- Next we will talk about Fast Infosets
- Fast Infoset uses tables and indexes to compress many of the strings present in the XML infoset. Recurring strings may be replaced with an index (an integer value) that points to a string in a table. A serializer adds the first occurrence of a common string to the string table, and then, on the next occurrence of that string, refers to it using an index into the table. This compression results in Fast Infoset documents being smaller in size compared to the equivalent XML documents There are limitations to how much performance improvement Fast Infoset can provide, since it improves the performance of only the parsing layer, which is just one part of the overall Web service processing. The performance improvements may be smaller for documents with limited repeating elements as well as for documents that have much higher binding cost compared to the parsing expense (e.g., documents based on complex nested schemas)
- Slide shows an example of enabling fastinfoset compression using the Accept header in soapui.