rm craziness

I was trying to delete some files on Solaris using the rm command.
The file names were something like: "-HqFbc3YQ0wQYhH7u16veP7_BBC_6_090540.xml"
These files were generated by a program using random numbers.

Now no matter what I tried, rm always returned with an error for files starting with a - (minus sign)
I found the solution here.

Snippet:
To remove a file whose name begins with a dash ( - ) character, refer to the file with the following syntax:
rm ./-filename
Using the redundant ./ directory information prevents the dash from occurring at the beginning of the filename, and being interpreted as an option of the rm command.

What does a Digital certificate contain?

If you view a digital certificate using FireFox browser or decoding it using some tool such as OpenSSL/IKeyMan; then we can see the following parts/data:-
- Issued by {The CA name}
- Issued to/Subject {CN of the subject (typically the DNS of the server)}
- Valid From {date}
- Valid Till {date}
- Public Key {typically the 1024 bit public key of the subject}
- Public Key Algorithm {The encryption algorithm to be used with the key, e.g. RSA}
- Signature Algorithm {The algorithm used to generate the digital signature, e.g. MD5HashWithRSA, SHA1HashWithRSA}
- Signature {The digital signature}

The digital signature is created by hashing the public key of the subject using MD5 or SHA1 and then encrypting the hash using the private key of a CA.

An entity verifying this digital cert would:
- decrypt the hash using the public key of the CA
- create a new hash of the public key of the subject
- compare both the hash keys and verify if the subject can be trusted.

Formats for Digital certificates

I knew that all Digital certs confirm to the X.509 standard. But why were they so many extensions for certificate files? - e.g. DER, CER, .P7B, PFX etc. I found this link that contains good info about X.509 certs.
Basically a X.509 cert can be in many formats (depending on the encoding used to save the cert)

.CER - CER encoded certificate, sometimes sequence of certificates
.DER - DER encoded certificate
.PEM - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"
.P7B - See .p7c
.P7C - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
.PFX - See .p12
.P12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)

A .P7B file could be a container for more than one digital certificate.

Adding trusted root certificates in Websphere 6.1

We had deployed an application to WAS 6.1 ND. This application contained a JAX-WS 2.0 webservices client that used to call a third-party service using SSL. The digital certificate used by the third-party was self-signed and hence we needed to accept it as a trusted party in our Trust Store.

We imported the certs into a trust-store (JKS format) using the keytool command of the JDK and wrote the following code:

System.setProperty
("javax.net.ssl.trustStore", trustFilename );
System.setProperty
("javax.net.ssl.trustStorePassword", "changeit") ;
System.setProperty
("javax.net.ssl.keyStore", trustFilename );
System.setProperty
("javax.net.ssl.keyStorePassword", "changeit");

But unfortunately this was not working on WAS6.1. (This works fine on Tomcat).
In earlier versions of WAS, the iKeyman tool provided an interface to manipulate digital certs, keys, Trust stores and Key stores. But in WAS 6.1, all these tasks can be done from the web-based admin console.

So to add the certs to the Trust store, I went to "Security (on the left panel) --> SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates"
Add the new root digital certs that need to be trusted to this store. The JAX-WS client should now be able to connect to the HTTPS resource. Remove any system properties that have been set before.

A good article (for WAS 6.0) describing how SSL and Digital certs work in Websphere can be found here.

Hack to deploy JAX-WS 2.0 webservice on Websphere 6.1

Our team had developed a webservice using JAX-WS 2.0 and using the Reference implementation of Sun as the JAX-WS provider. The application was developed using Netbeans and the embedded Tomcat server.

But when the application was deployed on WAS 6.1, then it failed and resulted in ClassCast exceptions. The base installation of WAS 6.1 only supports JAX-RPC 1.1.
IBM did provide an option - installing the webservices feature pack for WAS 6.1
The installation was a bit of a pain, especially on a cluster. You essentially had to create new AppServer profiles, create a new cluster and move all applications to the new cluster. This would also required considerable downtime on a live production server.

I looked for an other option. I tried to understand what was happening under the hoods when Netbeans was creating a webservice. It was clear that the webservice created was using a Servlet provided by the RI of JAX-WS 2.0. Even all the annotations and JAXB libraries were included in the lib directory. Hence there was no dependancy on any server-specific library as such.

I realised that the ClassCast exceptions on WAS 6.1 were happening due to the ClassLoader heirarchy - which was set to 'Parent First'. I decided to try to change this configuration to 'Child First' - so that JAX-WS RI libraries are picked up from WEB-INF/lib first.

There were 2 changes that I made using the web admin console. Go to "Enterprise Applications --> {Application name} --> Class Loader" and changed the following items:
Select "Classes loaded with application class loader first" and "Single class loader for application". Save these changes to the master configuration and restart the AppServer.

This hack worked and we could deploy JAX-WS 2.0 webservices on WAS 6.1 :)

Tip: We ran into a few Linkage errors, which we could resolve by removing all duplicate jar files.
A linkage error would typically occur when a class tries to call another class loaded by a different class loader.

Is POX/HTTP same as REST?

There is a lot of confusion in the industry over REST webservices. A lot of applications offer POX/HTTP interfaces and call them REST webservices. But in theory, just having XML tunneled over HTTP does not satisfy all REST principles.

It's important to understand that REST is not a protocol. It is an architecture style that can be used to design systems. It brings in a noun-oriented approach to access resources (instead of a verbs).

The Apache CFX framework has new features (using the magic of annotations) that make it possible to have true REST style webservices.
More information on this can be found here and here.

Recently came across this article that states the REST principles that should be followed during design:

1. Give every resource an ID. Use URIs to identify everything that merits being identifiable, specifically, all of the "high-level" resources that your application provides, whether they represent individual items, collections of items, virtual and physical objects, or computation results. Examples:

http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/4554

2. Link things together. (Hypermedia as the engine of application state)

Example: Element in XML doc: product ref='http://example.com/products/4554'

We could use a simple 'id' attribute adhering to some application-specific naming scheme, too but only within the application’s context. The beauty of the link approach using URIs is that the links can point to resources that are provided by a different application, a different server, or even a different company on another continent because the naming scheme is a global standard, all of the resources that make up the Web can be linked to each other.

3. Use standard methods. For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE

e.g. GET - get order details/list all orders

PUT - update order

POST - add order

DELETE - delete order

4. Communicate statelessly - This is for scalability.

Message style and encoding in WSDL documents

The WS-I specs state the following 2 types of encoding to be complaint to the Basic profile:
- RPC/literal
- Wrapped document/literal

Found this cool article on developerworks that explain all the styles and encoding in detail.

WSDL cheat sheet

With the plethora of tools available today for webservices development, we sometimes forget the basic fundamental semantics of a WSDL document. Here is a quick reference of what a WSDL contains:
1. Types: These are the data type definitions - expressed as a schema of complex/simple types.
2. Message: A message consists of a logical order of one or more types.
3. Operation: Defines a operation that consists of a input and output message.
4. Porttype: A collection of operations.
5. Binding: Specifies the concrete protocol data format specifications (e.g. document-literal) for a portType.
6. Port: Specifies a network addresss for a binding, thus defining a single communication endpoint.
7. Service: collection of endpoints or ports

Thus a service is defined by one or more endpoints/ports. A port is combination of a binding with a network address. Each binding is a combination of a porttype and concrete data format specifications. Each porttype is a collection of operations that define messages that are exchanged.

More information can be found here.

Xerces and Xalan packages in JDK 1.5

Since JDK 1.5, Sun has decided to change the package names of the Xalan and Xerces to "com.sun.org.apache.xalan" and "com.sun.org.apache.xerces". Old package names (org.apache.xalan.xslt etc) are now not shipped with JDK1.5

I think this is a welcome move, bcoz this will enable end-users to use new versions of Xerces and Xalan easily without resorting to class-loader manipulation. Earlier this was done using the endorsing mechanism for JAR files.