Company founder Dennis Sosnoski has been writing articles about Java™ since 1999, published first by JavaWorld and then by several different zones within IBM® developerWorks®. He has also published several articles on InfoQ and other ezines. This page provides links to some of his recent sets of articles.
Securing data exchanges is hard in a world where both freelance hackers and government agencies are out to get you. Public key encryption is the basis for most forms of secure exchange, but it depends on trust - and those who are out to get your data are experts at abusing trust. Supposedly-secure connections can be downgraded to the point where they are easily broken, and even at full strength most forms of encryption are vulnerable to data capture and later decryption if your private keys are exposed.
But there are still ways to protect your secrets, especially if you have some control over both ends of the exchange. In this article you'll learn how you can secure application data exchanges in ways that block exposure both now and in the foreseeable future, and see examples of applying the security techniques in Java code. Along the way you'll also get some pointers on how you can protect your own online access.
Besides the original article (linked from the article title, above) you can also view the slides and hear the audio from Dennis's presentation with the same name to the Open Source Developers Conference in Auckland, New Zealand, 22 October 2013.
Java Web Services
The Java Web Services series covers the evolving state of web services support in Java for the IBM developerWorks Java and SOA and web services zones. The series was started in 2007, but has become a regular part of the developerWorks program since the beginning of 2009 to match the growing importance of SOA and web services. The main focus has been on comparing the open source Java web services stacks, most recently focusing on their support for WS-Security and related standards. Here's a list of the recent articles:
WS-SecurityPolicy lets you define security configurations as part of your Web Service Description Language (WSDL) service description. It's a powerful tool, but working with WS-SecurityPolicy documents can be painful. Assertions must be correctly structured to be effective, and version namespaces need to be consistent. In this article, you'll learn about common errors made in creating WS-SecurityPolicy documents, and you'll see how WS-Policy and WS-SecurityPolicy can be modeled in Java for verification and transformation.
Several years after the approval of Web Services Description Language (WSDL) 2.0 as a World Wide Web Consortium (W3C) standard, WSDL 1.1 is still the most widely used form of web service description. Despite its popularity, WSDL 1.1 has some issues, including a variety of schemas in use and variations in how web services stacks process WSDL documents. In this article you'll learn how WSDL 1.1 service descriptions are structured. You'll also see the basic structure of a Java tool for verifying WSDL documents and transforming them into a "best practices" form.
WS-Security and related standards provide a wide range of options for web service security. Of this wide range, web services stacks test only a limited number of security configurations, and even fewer configurations for interoperability, on their own. Find out what the industry has done to promote interoperability among web services stacks, and read a summary comparison of how the three main open source Java stacks handle security.
WS-Policy provides a general structure for configuring features and options that apply to a web service. You've seen it used for WS-Security configurations in this series, and perhaps elsewhere for other extension technologies such as WS-ReliableMessaging. In this article, you'll learn about the structure of WS-Policy documents and the ways you can attach policies to services in Web Service Description Language (WSDL), with security-configuration examples tried on Apache Axis2, Metro, and Apache CXF.
WS-Security symmetric encryption lets you secure message exchanges between client and server without requiring client certificates, simplifying your web service configuration while also providing performance benefits. You can use it directly or in the bootstrap for WS-SecureConversation exchanges. In this article, you'll learn how to configure and use symmetric encryption with the three main open source Java web services stacks: Axis2, Metro, and CXF. You'll also see how plain WS-Security symmetric encryption performance compares to WS-SecureConversation performance.
WS-SecureConversation lets you secure ongoing Web service message exchanges with less processing overhead than plain WS-Security. In this article, you'll learn how to configure and use WS-SecureConversation with the three main open source Java web services stacks: Apache Axis2, Metro, and Apache CXF. You'll also see how the three stacks compare on WS-SecureConversation performance.
WS-Security adds enterprise-level security features to SOAP message exchanges, but with a substantial performance cost. WS-Trust builds on WS-Security to provide a way of exchanging security tokens, and WS-SecureConversation builds on WS-Security and WS-Trust to improve performance for ongoing message exchanges. Dennis Sosnoski continues his Java Web Services series with an introduction to WS-Trust and WS-SecureConversation.
Apache CXF shares certain underlying components with both Apache Axis2 and Metro but combines the components within an entirely different architecture. Dennis Sosnoski continues his Java Web Services series by comparing how the CXF, Metro, and Axis2 stacks perform both with and without WS-Security.
The Apache CXF Web services stack supports WS-Security, including using WS-SecurityPolicy to configure the security handling. CXF is flexible in how you configure the deployment parameters used at run time to implement the security handling, supporting both static and dynamic configuration options for the client side. In this article, Java Web Services series author Dennis Sosnoski shows how to use CXF for both a simple UsernameToken WS-Security example and one using signing and encryption.
The Apache CXF Web services stack supports JAXB 2.x data binding (along with some alternative data bindings) and JAX-WS 2.x service configuration. Like the Metro JAXB/JAX-WS alternative discussed in earlier columns, CXF uses XML files to extend the JAX-WS configuration information. In this article, Java Web Services series author Dennis Sosnoski looks into the basics of working with CXF for client and server development.
The Metro Web services stack provides the same functionality as the Axis2 stack but, aside from the optional use of JAXB and JAX-WS in Axis2, uses completely different implementations of the technologies involved. In this article, Dennis Sosnoski continues his Java Web Services series with a performance comparison between the Metro and Axis2 stacks, both with and without WS-Security.
The Metro web services stack is based on the reference implementations of the JAXB 2.x and JAX-WS 2.x Java™ standards but also includes support for a full range of WS-* SOAP extension technologies. This article continues Dennis Sosnoski's Java Web Services series with coverage of WS-Security configuration and usage in Metro.
The Metro web service stack provides a comprehensive solution for accessing and implementing web services. It's based on the reference implementations of the JAXB 2.x and JAX-WS 2.x Java™ standards, with added components to support WS-* SOAP extension technologies and actual Web service deployment. This article continues Dennis Sosnoski's Java Web Services series with a look at the basic principles of Metro client and server development.
Apache Axis2 supports a range of data-binding technologies, including the official Java standard, JAXB 2.x. Axis2 also supports the Java standard for web service configuration, JAX-WS 2.x, as an alternative to its own custom configuration technique. Dennis Sosnoski continues his Java Web Services series by demonstrating how you can use each of these Java standards with Axis2 and discussing some of the limitations of Axis2's current support for them.
WS-Security for SOAP web services doesn't have to be an all-or-nothing proposition. By configuring WS-Security at the operation or message level, you can apply an appropriate degree of protection to every exchange, reducing or eliminating the WS-Security overhead for operations that don't need full protection. Dennis Sosnoski continues his Java Web Services series with a look at granular WS-Security in Web Services Description Language (WSDL) using Apache Axis2 and Rampart.
WS-Security offers powerful features for securing Web service applications, and for many applications these features are essential. But these features come at a high cost in terms of performance and message overhead. Dennis Sosnoski continues his Java Web Services series with a look at how using WS-Security or WS-SecureConversation affects Axis2 performance, and he discusses when the simpler (and better performing) alternative of HTTPS-secured connections is a more appropriate choice.
Get an introduction to the principles of public key cryptography, then see how WS-Security applies them for signing and encrypting SOAP messages using public-private key pairs in combination with secret keys. Dennis Sosnoski continues his Java Web Services series with a discussion of WS-Security and WS-SecurityPolicy signing and encryption features, along with example code using Axis2 and Rampart.
Learn how to add the Rampart security module to Apache Axis2 and start using WS-Security features in your web services. Dennis Sosnoski resumes his Java Web Services series with a look at WS-Security and WS-SecurityPolicy use in Axis2, starting with UsernameToken as a simple first step.
JiBX Data Binding
The JiBX 1.2 data binding tutorials published by IBM developerWorks give introductions to using the open source JiBX tool for schema-oriented XML data binding in Java.
XML schema definitions are the basis for many types of data exchanges, including most forms of Web services. But XML Schema is a complex standard, and most tools for creating and modifying schema definitions are not as powerful or easy to use as those for working with Java code. The new features of JiBX 1.2 that you'll learn about in this tutorial let you start from Java code and easily generate quality schema definitions to match your data structures. You can then use the schemas directly, whether you use JiBX data binding or not.
Code generation from XML schema definitions is widely used for all types of XML data exchange, including Web services. Most data-binding tools rigidly structure generated code based on the schema — even aspects of the schema that may be irrelevant to your application. In this tutorial, second in a two-part series, learn how JiBX 1.2 generates cleaner code by doing a better job of interpreting the schema and eliminating unnecessary class clutter. You'll also see how you can customize the generated code to suit your needs better, including customizations that easily eliminate unnecessary components of the schema.
XML Transport Performance
The XML Transport Performance articles quantified the processing and document size overhead added by using XML rather than binary formats, and also looked into alternative approaches to reduce the overhead of XML (including the XBIS binary representation of XML). These articles were published in 2004, and although the articles themselves are no longer online you can see the performance results at the XBIS website.