By David Carr

Universally unique identifiers (UUIDs) are useful in various situations, especially in distributed computing, to identify information without central coordination. They have been standardized under RFC 4122, and can be accessed in Java using java.util.UUID.

Globally unique identifiers (GUIDs) are a subset of UUIDs. Microsoft uses them for identifying classes, interfaces, and other objects. In particular, I was interested in the objectGUID attribute for users in Active Directory, though the same technique should apply for all Microsoft GUIDs. Microsoft GUIDs are completely compatible with the UUID specification, with one exception: the binary encoding. In particular, RFC 4122 specifies that all segments must be encoded as big-endian, while Microsoft encodes the first 3 segments using the system’s native endianness (which for Windows is commonly little-endian).

If you’re getting access to the GUID as binary data (such as a byte array), you’ll need to do some processing before passing the data to the UUID class.  Balazs Zagyvai‘s adsync4j project provides a useful example of this (see gist below).  It also uses UnboundID LDAP SDK for Java, which I highly recommend if you’re accessing LDAP servers (including Active Directory) in Java.

Categories Software EngineeringTags , , , ,
By David Carr

When adopting a service-oriented architecture, one of the things we needed to do was define the data format each service endpoint takes as input and produces as output. In some cases, the input is simple and easily represented as URL segments or query parameters. In most cases, however, either the request body or response body needs to deal with a richer data object. For requests, this data needs to be parsed, validated, and coerced into a format that the application logic can use. For responses, we need to be able to generate the desired data format from the objects generated by the application logic.

Read on…

Categories Software EngineeringTags , , ,
By David Carr

When managing servers with Chef, sometimes it’s useful to trigger a run “right now.” One of our use cases was triggering a Chef deployment of an updated application as part of a continuous integration job, prior to running acceptance tests. One of the most common ways to trigger a run is `sudo chef-client`. You may also have stumbled upon the option of sending a USR1 signal to the chef daemon process (`sudo killall -USR1 chef-client`). Depending on your configuration, the `sudo killall -USR1 chef-client` approach may not trigger the run immediately, as it uses the configured “splay” to wait a random number of seconds before running. Both of these approaches require root privileges, which may be problematic in automation scenarios.

Read on…

Categories Deployment Automation