More on Time!

Seems that dateTime is one of the most frustrating types in XML.  I just had a colleague ask how to convert a string to an XML dateTime type.  There are a rich range of functions to convert dateTimes to strings, but a paucity to do the reverse.  So I present here one approach to this.  I use XSLT variables to help in the parsing.  Here is the XSLT fragment that converts a US formatted date (MM/DD/YYYY) to an XML dateTime format (CCYY:MM:DDTHH:MM:SS).  Note that in an XML dateTime all fields are mandatory, the only optional pieces are the decimal part of the seconds (CCYY:MM:DDTHH:MM:SS.SS) and the timezone portion (CCYY:MM:DDTHH:MM:SSZ or CCYY:MM:DDTHH:MM:SS+02:00).
In the fragment below I take the input data from XPath expression /DateList/SingleDate/DateField.  This has the date in format MM/DD/YYYY.  I use this input to populate an element dateitem which is of dateTime type.
Lets go throught the XSLT a little at a time.

        <dateitem>
          <!-- Parse Date of format MM/DD/YYYY -->
<!-- I declare a variable TempInput to hold everything after the first '/' in the date (DD/YYYY). -->
          <xsl:variable name="TempInput">
            <xsl:value-of select='substring-after(/DateList/SingleDate/DateField,"/")'/>
          </xsl:variable>
<!--I set a variable Month to hold the month, generated by picking up everything before the first '/' in the date (MM). -->
          <xsl:variable name="Month">
            <xsl:value-of select='substring-before(/imp1:DateList/imp1:SingleDate/imp1:DateField, "/")'/>
          </xsl:variable>
<!--I define a variable Day to hold the day portion which I get by picking up everything before the '/' in my Temp variable (DD). -->
          <xsl:variable name="Day">
            <xsl:value-of select='substring-before($TempInput, "/")'/>
          </xsl:variable>
<!--I then pick up everything after the '/' in Temp variable (YYYY) and put it in a Year variable. -->
          <xsl:variable name="Year">
            <xsl:value-of select='substring-after($TempInput, "/")'/>
          </xsl:variable>
<!--Finally I construct an XML dateTime format by concating the Year, Month and Day variables in the correct XML format. -->
          <xsl:value-of select='concat($Year,"-",$Month,"-",$Day,"T00:00:00")'/>
        </top:dateitem>
Obviously the parsing could be made to handle time formats and timezones as well.
Hoping that this helps someone struggling with parsing text strings into dates.

I have created a simple ESB project that takes data from a file in US date format and loads it into two columns in a database table, one formatted as a string the other as a SQL Date.  When using the Database adapter the SQL Date format gets converted to an XML dateTime.  The project is available for download here.

Registering Interest

I have been involved in some interesting discussions recently on the use of a service registry.  Oracle SOA Suite ships with a limited use license for a service registry and there is the option to upgrade it to a full use license and so the question comes up, Antony why would we want to use a registry and can we use it for all our service lookups.
Lets start by looking at what a registry is.

Glorified Yellow Pages

Uncharitably a registry may be described as a glorified yellow pages.  It allows artifacts such as XML schema and service WSDLs to be stored in a searchable, categorized archive.  Artifacts are stored under different categories and may have keywords associated with them to assist in searching.  So at the end of the day the registry is just a repository of meta-data about artifacts.  In the same way a car is just a large amount of beaten metal with a power unit that drives wheels.  Calling it a repository of meta-data does not actually explain what it does or how it may be used.

Registry use Cases

Let me suggest a few registry use cases

• Design Time Service Discovery
  A registry can be used to catalogue existing services and associated artifacts.  This encourages re-use by making it easier to discover existing services.  The ability to promote items between registries also makes it possible to put in place a service approval process that vets new services before making them available to developers.  This again promotes re-use and generalisation of existing services.
  
• Run Time Service Discovery
  A registry can also be used at runtime to provide the physical endpoint for a service.  This makes it easy to change the physical provider of a particular service.  This also simplifies migration of services between development test and production environments as outlined in the next use case.
  
• Service Migration Mechanism
  The use of multiple registries provided a managed path for services to be promoted between environments, either from a development perspective or from a runtime perspective.

Design Time Considerations

Use of a registry at design time is generally a good idea but it does a require a certain amount of discipline in its use otherwise it becomes yet another dumping ground for all design decisions, good and bad!  However individual develpoment team can maintain their own local registry that has a well defined promotion process to a central registry, allowing teams to work on their development services which may later be migrated to a corporate registry.  In my experience most customers are not making use of a registry even in their design time environments and this is probably the best place to start using a registry.

Run Time Considerations

Using a registry in a runtime environment promises a greater degree of de-coupling.  However a similar amount of decoupling may be achieved through the use of an ESB alone.  If a registry is used to look up an ESB endpoint then there is a potential cost to be paid in terms of an additional lookup.  If an ESB endpoint is not looked up then there is the risk of coupling the data formats of unrelated services together, losing the use of an ESB to provide message transformation to/from canonical form.  Some informal tests I ran indicated that the additional overhead of a registry lookup does not add much to the service invocation, but in high volume environments it may be the straw that breaks the camels back.
A good policy may be to begin using a service registry in design time, later trying it out in non-high volume environments.  Using an ESB can make this migration to registry use easier, if less pure by having the ESB perform the registry lookup.

Using a Registry with Oracle BPEL PM

The current production release of Oracle BPEL PM has built in support for use of a registry.  Al that is required to make a service lookup occur through a registry is to perform the following.

1. In the BPEL Console, go to the "Manage BPEL Domain" and set the following properties
• uddiLocation - the inquiry address of the registry
• uddiUsername - if it is a secured registry set it to a username for performing lookups, if not set it to urn:unknown
• uddiPassword - if it is a secured registry set it to a password for performing lookups, if not set it to urn:unknown
2. In a BPEL process for each service endpoint (partner link) that you want to go through a UDDI lookup
• Add a property "registryServiceKey" to the partner link with the "Entity Key" value assigned in the UDDI repository

For more on potential performance impacts of registry lookup see Chintan Shahs blog entry. Note that I haven't seen such a bad degradation as he reports, but I could believe it for a complex WSDL and high system load, meaning unresponsive threading, particularly in a Windows environment.

An Example of Dynamic Lookup

To give a feel for dynamic lookup I have uploaded 3 JDeveloper Projects in the this file.

• JavaWS includes a simple Java web service (GreetingWS) that can be registered in a service registry.  When registering it in the registry you will need to note the service key and copy it into the partner link property in Dynamic BPEL.
  
• DynamicBPEL is a BPEL process that looks up the web service (GreetingWS) and invokes it in three different ways
1. Static, it uses the endpoint defined in a WSDL file
2. Dynamic, it sets the endpoint explicitly (passed in as a parameter to the process), showing how you can be very dynamic in the endpoint you invoke.
3. UDDI, it uses the UDDI repository to lookup the endpoint, showing how unintrusive it is on the rest of the process.
• TestDynamic is a BPEL process that you invoke to test the DynamicBPEL process.  It iterates over all three methods and calculates how long each method takes to complete the given number of iterations.  The first invocation is not counted to allow the system to "warm up" for each call.