The Service-Oriented Architecture (SOA) can integrate multiple legacy systems or new software products as a service through Internet connections to achieve mutual communication between services. Web Service technology is a basis for SOA implementation. It contains complex transaction processing between different business entities. XML processing, as the core component of Web Service technology, includes soap processing, XML binding, and XML parsing. For Web services that require better performance, it is important to understand the features of Web Services Description Language.
This article demonstrates how to use Java API for XML Web Services (JAX-WS) 2.0 to implement high-performance Web services and provides and Java API for XML-based RPC (JAX-RPC) 1.1 comparison of features and performance. The performance data in this article will help you design a high-performance web service.
Web Services stack OverviewSun's initial implementation of Web Services was called JAX-RPC 1.1 (JSR 101 ). This is a standard implementation, but the underlying implementation of the binding and resolution layers is private. In addition, JAX-RPC 1.1 does not fully contain schema specifications. Sun's latest version of the web service stack, JAX-WS 2.0 (JSR 224), is fully standard-based. Even the binding layer, jaxb (JSR 222, Java architecture for XML binding), parsing layer, Stax (JSR 173, streaming API for XML) both are based on standards and 100% support schema specifications.
Figure
1: Web Service Stack Figure 1 represents the JAX-RPC and JAX-WS implementations. The advantage of JAX-WS is that it reduces development tasks and has high performance. Because of jaxb and Stax performance improvement, the performance of the JAX-WS Stack also increases. For this reason, the JAX-WS stack is called an integrated stack (
Integrated Stack).
Web Services performanceUnderstanding the performance of web services is important because it allows developers to design and implement efficient enterprise-level Web Services for performance and scalability. You can measure the performance of web services in two ways, depending on your development model: end-to-end performance and Endpoint performance ).
End-to-end performanceIf a Web Service Development includes a client-side and a server-side stack, the measurement in the performance test includes two components. This requires a fat client that tests the Web Service stack of the client. Figure 2 illustrates the performance of the Peer end. Here, the client driver uses a fat client Web Service Stack to send and accept SOAP requests.
Figure
2: In terms of end-to-end performance, a client driver uses a fat client Web Service Stack to send and accept SOAP requests.
Endpoint PerformanceIn this case, the only concern is the endpoint, that is, the server performance. For such measurement, you can use a thin client driven by HTTP. Figure 3 illustrates the performance of the endpoint. Here, the client uses a thin HTTP driver to send and receive SOAP requests.
Figure
3:
In terms of endpoint performance,
The client uses a thin
HTTP
Driver for sending and receiving
Soap
Request
.This article focuses on the performance data for the end-to-end performance, but it only shows the performance of the end point.
The wstest BenchmarkThis article uses wstest benchmark to measure the performance of JAX-RPC and JAX-WS. Wstest is a small benchmark (https://wstest.dev.java.net/) developed by Sun to measure Java-based Web Service stacks. Wstest is designed to mimic the real-world web service processing. Typically, any web service application requires a container to run. Wstest can be deployed in glassfish or tomcat. this benchmark is highly configurable to meet the needs of the real-world imitation, such as many clients and test cases, percentage of Hybrid Web Service Processing (for example, the percentage of the time when a special use case is run), and so on.
Performance measurementsThis section discusses simple type performance, simple Array Performance, payload performance, and binding performance in Web Services. Simple types such as int, short, long, float, and others lay the foundation for implementing an effective web service. Any complex business structure will eventually involve the composition of individual basic types. This part compares the performance of various simple types and provides you with some information for choosing an appropriate service stack. Consider the following WSDL sample 1. Example of WSDL
WSDL sample 1
| <XSD: Element type = "XSD: int" name = "echoint"/> <XSD: Element type = "XSD: int" name = "echointresponse"/>... <message name = "echointsoapin"> <part name = "Params" element = "types: echoint "/> </message> <message name =" echointsoapout "> <part name =" result "element =" types: echointresponse "/> </message> |
WSDL sample 1 shows the back-and-forth echo of the integer type on the client and server. Code sample 1 shows the corresponding web service implementation code.
Code sample 1
| Public int echoint (INT Params) {return Params ;} |
Similarly, changing different basic types in WSDL produces the corresponding web service implementation code. Table 1 compares the basic types using Java technology and the corresponding XSD basic types defined in WSDL based on JAX-RPC1.1 and JAX-WS 2.0: Table 1
| XSD type |
JAX-RPC 1.1 |
JAX-WS 2.0 |
|
| XSD: Boolean |
Boolean |
Boolean |
| XSD: short |
Short |
Short |
| XSD: int |
Int |
Int |
| XSD: Long |
Long |
Long |
| XSD: integer |
Biginteger |
Biginteger |
| XSD: Float |
Float |
Float |
| XSD: double |
Double |
Double |
| XSD: decimal |
Bigdecimal |
Bigdecimal |
| XSD: Date |
Java. util. Calendar |
Javax. xml. datatype. xmlgregoriancalendar |
| XSD: Time |
Java. util. Calendar |
Javax. xml. datatype. xmlgregoriancalendar |
| XSD: datetime |
Java. util. Calendar |
Javax. xml. datatype. xmlgregoriancalendar |
|
The chart in figure 4 compares the performance of basic XSD types. The X axis indicates the basic types of XSD, such as Boolean, short, and so on. The Y axis indicates the throughput for processing transactions per second.
Figure
4: XSD basic type performance Note: When selecting Boolean, short, Int, long, integer; float, double, decimal or date, time, datetime type, the performance is almost the same. But scale/precision set-for example, for float, double, there is also a decimal number of digits after the decimal point that can affect serialization, deserialization, and the cost of a payload, all of these will have a direct impact on performance. Similarly, it is best to use the XSD: decimal/bigdecimal type to avoid the numeric value for completing all monetary calculations. (Also, it is best to use the XSD: decimal/bigdecimal type to avoid rounding off decimal values for all monetary calculations .) the chart in figure 4 implies that all basic types have the same performance when the binding layer is not emphasized.
(To be continued)
