Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Server-side Subjects Drop Java's GPA : Page 3

There's a lot to love in Java, but it can be far from a cakewalk. Find out why, in some scenarios, Java scores only a middling B-.


advertisement
Measuring Server Quality

Throughput: Server quality is also measured by how quickly the server can process a clump of requests. Throughput is different than scalability, which is the number of simultaneous requests a server can handle. Throughput measures how quickly the server processes individual requests.

Java does not currently have non-blocking I/O, which virtually guarantees Java server implementations bind one thread per client connection.  
My beef with Java as a platform for server development begins here. Java does not currently have non-blocking I/O, which virtually guarantees Java server implementations bind one thread per client connection. This fundamental design flaw limits throughput of Java InputStreams and OutputStreams, attenuating server throughput even before client data can be pulled from an InputStream or response data can be sent to an OutputStream.

Java server implementations built on J2SE, including J2EE implementations, either ignore the blocking I/O problem (sacrificing throughput and scalability in the offing) or write proprietary non-block libraries to replace the functionality of the java.io package.



For example, the WebLogic application server has shipped with a proprietary non-blocking I/O library since the earliest versions. Remote method invocation (RMI) developers are regularly reminded about the trade-off between scalability and throughput in RMI servers, which use the J2SE java.io package. A high volume of simultaneous requests will bring an RMI server to a halt, since one thread is required to handle each unique client request.

Java 2 Version 1.4 is set to include a non-blocking I/O package which should alleviate this scalability vs. throughput problem. But for projects that can't use that platform, early project analysis must determine whether Java's non-blocking I/O is a serious impediment to project success.

Security: The ability for a server to prevent access to unprivileged clients is de rigueur, as is the ability for the server to participate in constructing and communicating with clients across secured network connections. Higher-quality servers allow administrators to define client-access policy to a high level. For example, individual server-side resource access is provided to only a specific set of users.

J2SE and J2EE each have their own completely unrelated access and administration mechanisms. J2SE has a programmatic security API, based around individual methods securing themselves against unprivileged access by adding security guard blocks. On the other hand, the only portable security services mandated by the J2EE specification use deployment-time configuration files, which are convenient to use (much easier to implement and change than J2SE-based security) but provides a relatively coarse level of access control.

  These rules cannot be implemented using J2EE's defined security configuration files without torturous, invasive, up-front design.
Unfortunately for J2EE users, many real-world projects have relatively complex security business rules. These rules cannot be implemented using J2EE's defined security configuration files without torturous, invasive, up-front design. It would be great if J2EE provided a mechanism to use J2SE security to implement complex security rules, since J2SE's security API can handle arbitrarily complex security requirements. But J2EE provides no direction with regard to J2SE security integration.

Security is a lurking problem in J2EE-based servers. Developer culture tends to put off security implementation for a system until a relatively late development stage. I know from personal experience that ignoring the incompatibility between J2SE and J2EE security structures can be a project killer. After the J2EE (servlet and EJB) components are completed, it is devastating to realize your project's complex security requirements can't be implemented without very significant refactoring.

Sun has not provided concrete direction in the area of server manageability.  
Manageability: The Java architects have been woefully silent in this area. Only in late 1999 did a specification appear for an instrumentation and control standard—the Java Management Extension (JMX). This standard has not been added to J2EE, and the standard does not define a wire protocol. While JMX looks promising, there has been a lot of wheel reinvention by different developers building manageable Java server-side solutions. Sun has not provided concrete direction in the area of server manageability. Be prepared to spend some money for a third-party solution or dedicate significant resources to the management problem if you're using J2SE as your server's platform. On J2EE, many container implementations provide proprietary management APIs, but be aware these solutions are not portable.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap