In Part 1 i have introduced the web services, and how to create, implement and publish WS then show the resulting WSDL.
After that in Part 2 i have implemented a Java Requester for the Web Service created in part 1.
In this part i will implement a multithreading version of the Endpoint Publisher to accept concurrent requests.
Multithreading the Endpoint Publisher
In the examples so far, the Endpoint publisher has been single-threaded and, therefore, capable of handling only one client request at a time: the published service completes the processing of one request before beginning the processing of another request. If the processing of the current request hangs, then no subsequent request can be processed unless and until the hung request is processed to completion.
In production mode, the Endpoint publisher would need to handle concurrent requests so that several pending requests could be processed at the same time. If the underlying computer system is, for example, a symmetric multiprocessor (SMP), then separate CPUs could process different requests concurrently.
On a single-CPU machine, the concurrency would occur through time sharing; that is, each request would get a share of the available CPU cycles so that several requests would be in some stage of processing at any given time. In Java, concurrency is achieved through multithreading. At issue, then, is how to make the Endpoint publisher multithreaded. The JWS framework supports Endpoint multithreading without forcing the programmer to work with difficult, error-prone constructs such as the synchronized block or the wait and notify method invocations.
An Endpoint object has an Executor property defined with the standard get/set methods. An Executor is an object that executes Runnable tasks; for example, standard Java Thread instances. (The Runnable interface declares only one method whose declaration is public void run().) An Executor object is a nice alternative to Thread instances, as the Executor provides high-level constructs for submitting and managing tasks that are to be executed concurrently.
The first step to making the Endpoint publisher multithreaded is thus to create an Executor class such as the following very basic one:
The class MyThreadPool creates a pool of 10 threads, using a fixed-size queue to store the threads that are created under the hood. If the pooled threads are all in use, then the next task in line must wait until one of the busy threads becomes available.
All of these management details are handled automatically. The MyThreadPool class overrides a few of the available methods to give the flavor.
A MyThreadPool object can be used to make a multithreaded Endpoint publisher. Here is the revised publisher, which now consists of several methods to divide the work:
Once the ThreadPoolWorker has been coded, all that remains is to set the Endpoint publisher's executor property to an instance of the worker class. The details of thread management do not intrude at all into the publisher.
The multithreaded Endpoint publisher is suited for lightweight production, but this publisher is not a service container in the true sense; that is, a software application that readily can deploy many web services at the same port.
A web container such as Tomcat, which is the reference implementation, is better suited to publish multiple web services.
References:
Java Web Services: Up and Running, 1st Edition
After that in Part 2 i have implemented a Java Requester for the Web Service created in part 1.
In this part i will implement a multithreading version of the Endpoint Publisher to accept concurrent requests.
Multithreading the Endpoint Publisher
In the examples so far, the Endpoint publisher has been single-threaded and, therefore, capable of handling only one client request at a time: the published service completes the processing of one request before beginning the processing of another request. If the processing of the current request hangs, then no subsequent request can be processed unless and until the hung request is processed to completion.
In production mode, the Endpoint publisher would need to handle concurrent requests so that several pending requests could be processed at the same time. If the underlying computer system is, for example, a symmetric multiprocessor (SMP), then separate CPUs could process different requests concurrently.
On a single-CPU machine, the concurrency would occur through time sharing; that is, each request would get a share of the available CPU cycles so that several requests would be in some stage of processing at any given time. In Java, concurrency is achieved through multithreading. At issue, then, is how to make the Endpoint publisher multithreaded. The JWS framework supports Endpoint multithreading without forcing the programmer to work with difficult, error-prone constructs such as the synchronized block or the wait and notify method invocations.
An Endpoint object has an Executor property defined with the standard get/set methods. An Executor is an object that executes Runnable tasks; for example, standard Java Thread instances. (The Runnable interface declares only one method whose declaration is public void run().) An Executor object is a nice alternative to Thread instances, as the Executor provides high-level constructs for submitting and managing tasks that are to be executed concurrently.
The first step to making the Endpoint publisher multithreaded is thus to create an Executor class such as the following very basic one:
The class MyThreadPool creates a pool of 10 threads, using a fixed-size queue to store the threads that are created under the hood. If the pooled threads are all in use, then the next task in line must wait until one of the busy threads becomes available.
All of these management details are handled automatically. The MyThreadPool class overrides a few of the available methods to give the flavor.
A MyThreadPool object can be used to make a multithreaded Endpoint publisher. Here is the revised publisher, which now consists of several methods to divide the work:
Once the ThreadPoolWorker has been coded, all that remains is to set the Endpoint publisher's executor property to an instance of the worker class. The details of thread management do not intrude at all into the publisher.
The multithreaded Endpoint publisher is suited for lightweight production, but this publisher is not a service container in the true sense; that is, a software application that readily can deploy many web services at the same port.
A web container such as Tomcat, which is the reference implementation, is better suited to publish multiple web services.
References:
Java Web Services: Up and Running, 1st Edition
No comments :
Post a Comment