Skip to main content
Jazz Community SiteJazz Community SiteDownloadsDownloads

Jazz Foundation 3.0 M4 Milestone

February 19, 2010 | Learn about the project

This is not the most recent version. We recommend Jazz Foundation 3.0 M8
This is a pre-release milestone build. We recommend that you install any pre-release build as an additional instance, in a separate directory, and that you do not "Update" your existing installation to the pre-release build using the IBM Installation Manager.
Jazz Foundation 3.0 M4 News

Jazz Foundation 3.0 M4 News

Here are some of the more noteworthy things appearing in the Foundation 3.0 M4 milestone build (February 19, 2010) which is now available for download.

Foundation Services

Indexing decimal values from XML content into RDFs

The XML indexer is now able to extract decimal values into RDF literals of type xsd:decimal (e.g. "1.300"^^xsd:decimal). The list of data types supported by XML indexing rules now includes {string, int, boolean, date, uri, decimal}.

Example of an indexing rule in RDF/XML format for extracting a decimal price from XML:

<jfs:IndexSpecification xmlns:jfs="http://jazz.net/xmlns/foundation/1.0/"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     jfs:namespace="http://foo.bar"
     jfs:onlyForType="application/x-foobar+xml"
     rdf:about="">
   <jfs:index>
     <jfs:Property jfs:anchor="//price" jfs:object="." jfs:objectType="decimal" />
   </jfs:index>
</jfs:IndexSpecification>

RDF Turtle syntax now supported

The RDF Turtle format is now recognized by JFS for resources associated with either MIME type text/turtle or application/x-turtle. The Turtle syntax can also be used to define custom indexing rules for XML contents provided that the containing resource is associated with the MIME type application/com.ibm.team.foundation.indexer+turtle. Similar to other indexing rules in alternate RDF formats (RDF/XML, N-Triples), indexing rules expressed in Turtle can also be queried in SPARQL.

Example of an indexing rule in Turtle format for extracting both title and date from XML:

@prefix jfs: <http://jazz.net/xmlns/foundation/1.0/> .
<>   a   jfs:IndexSpecification ;
     jfs:index
         [ a jfs:Property ;
           jfs:anchor "//title"
         ] ;
     jfs:index
         [ a jfs:Property ;
           jfs:anchor "//date" ;
           jfs:object "." ;
           jfs:objectType "date"
         ] ;
     jfs:namespace "http://music.example.com/schema" ;
     jfs:onlyForType "application/x-com.ibm.examples.music+xml" .

Note: When using the Turtle syntax, the current base URI is implicitly denoting the frontside URL of the containing resource in storage.

Much improved scalability

The Foundation Indexing Service is now able to digest huge resources in a scalable fashion. The theoretical limit now matches the practical limitation of 1GB content in storage.

Additionally, there is no limit to the size of query/search results being paginated through any longer. Indeed, the implementation was reworked to avoid accumulating these in precious server memory.

And finally, the Query Service is performing much faster, especially on complex SPARQL queries involving the OPTIONAL graph pattern. Our measurements show a better than 10x improvement on complex queries like:

PREFIX wrapper: <http://jazz.net/xmlns/alm/rm/Reference/v0.1#>
PREFIX nav: <http://foo.bar/nav/>
PREFIX dc: <http://purl.org/dc/terms/>
PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/>
SELECT ?rsc ?created ?modified ?creator ?contextid ?tag 
       ?contrib ?name ?parent ?ref ?format ?formatPred
WHERE {
  ?rsc nav:parent <https://front.side/rdm/folders/folder1> .
  ?rsc dc:isPartOf <https://front.side/rdm/resources> .
  OPTIONAL { ?rsc nav:tag ?tag} .
  OPTIONAL { ?rsc wrapper:reference ?ref } .
  ?rsc dc:created ?created ; dc:modified ?modified ; dc:creator ?creator .
  ?rsc jfs:resourceContextId ?contextid ; dc:contributor ?contrib ; nav:parent ?parent .
  ?rsc ?formatPred ?format .
  FILTER ( ?formatPred = dc:format || ?formatPred = wrapper:contentType )
}

Accurate resource timestamps in indexing status

The status for the Foundation Indexing Service has been augmented to include an accurate timestamp in XSD format (UTCZ). Each indexer will provide an extra element in the status resource:

<jazz:lastProcessedXSD rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
   2009-12-07T10:32:04.035Z
</jazz:lastProcessedXSD>

The XSD timestamp provides millisecond precision (as opposed to HTTP time which is rounded to the second) and can be conveniently injected into a SPARQL query or a baseline creation request.

Foundation SDK

JFS Explorer

A new sample, JFS Explorer, has been added to the Server SDK. The JFS Explorer provides two functions. One is to explore the content of JFS storage. You can see all storage areas, all resources in a specified storage area, and can create, edit and delete a resource. You can also execute any SPARQL query.

You can refer to JFS Explorer as another sample to learn how to create an application using the Jazz Foundation SDK and Jazz Foundation Services. It's also pretty handy for debugging.

JFS Explorer

Stepped up to Apache HTTP Components 4.0

Apache HttpComponents Core (org.apache.http) and Apache HttpComponents Client (org.apache.http.client) has stepped up from the 4.0 beta 2 version to 4.0. This has required us to also update the bundle org.apache.james.mime4j from version 0.4 to 0.6. See work item 90323 for more details.

Added ROME

We've included version 0.9.0 of the ROME library for parsing and generating feeds. It's in the bundle com.sun.syndication. See work item 95613 for more details.

Application configuration

The JFS SDK application configuration properties have been refactored to use the com.ibm.team.jfs.app namespace. These properties are intended for application bootstrapping, including the discovery of application property files and other runtime dependencies.

  • com.ibm.team.jfs.app.conf: Specifies the root, common application configuration directory (e.g. /conf). If this is the only property set, this directory is assumed to contain context-specific subdirectories named after the application context (e.g. /conf/myapp1).
  • com.ibm.team.jfs.app.context.conf: Explicitly specifies the context-specific configuration directory (e.g. /conf/myapp1).
  • If neither of these properties are set, the SDK will use the JAZZ_HOME java property as the value of com.ibm.team.jfs.app.conf. In this scenario, both the /jazz context and SDK-based app contexts would share the same root configuration directory without additional configuration (default is /jazz/server/conf).

See the adoption work item 94131 for more details. Note that the properties which were deprecated in the 1.0.0.1 release have been removed for the 3.0 release.

OAuthHelper API changes

The com.ibm.team.jfs.app.oauth.OAuthHelper class has been simplified; several overloaded methods have been deprecated. See the adoption work item 101622 for more details.

Repository

Changes to AbstractService

AbstractService now includes a preferred method for composing Repository URIs that are to be returned to the calling client: getRequestRepositoryURL(). This method constructs the base URL using the hostname specified by the request.

The default behavior of getRepositoryURL() (deprecated as of 2.0.0.1) is now to also return the request hostname (configurable via system properties - "on" by default) - causing it to behave effectively the same as getRequestRepositoryURL(). This change supports the assertion that the requesting client's hostname is the right hostname to return to the client when constructing URIs that are returned to the source, and that the canonicalized hostname is not the best option in this case.

AbstractService also includes getLocalServerURL() which also returns the URL of the repository that this service is bound to. The distinction is that the hostname and port of the URI is that of the IP interface on which the request was received. Thus the URL can be used as a prefix in constructing a server URL that the server can use to refer back to itself, e.g. when making a local network call.

See work items 101047 and 88625 for additional information.

Model Evolution

The repository now supports the evolution of models. Components can modify their models in certain ways without requiring a full import/export migration and still maintain compatibility with older clients. The repotools addTables command has been enhanced to handle the database modifications for these models. See wiki topic https://jazz.net/wiki/bin/view/Main/ModelEvolution for a description of allowed model evolutions and the impact of supporting older clients.

Server Query Service

There is now a server-side query available to server component developers. It uses a simple iterator style interface for the results instead of the pagination style interface of the client-side query and the new service does not cache either the queries or their results thus avoiding the cache eviction issue. See work item 46491 for more details on the issues. The service is called IServerQueryService and supports an almost identical API to the IQueryService.

New AST Query API

There is now an API _keyExists(IString key) on all state extensions to determine whether item has a an extension of that type has an extension of that name. The string and medium string state extensions now support a _like and _ignoreCaseLike API that behave in the same way as the existing API. See work items 78904 and 94675.

JDBC Connection "Keep Alive"

The repository now has a configurable service that tickles database connections that have been setting idle for a period of time in order to avoid having idle connections closed by a server and then exceptions thrown when those connections are used. The two configurable properties are to turn on the service and to set the length of time to touch an idle connection. These can be set from the admin web UI. See work item 94097.

Token based licensing support

The floating license service now has support for token based licensing. The support includes an extensible mechanism which allows for multiple token service providers to be made available for use. Additionally, each license token service provider may provide an extensible UI widget to be used in the configuration of the service. A system administrator can configure the floating license server to use one of the available providers. The license token service provider is responsible for token checkin/checkout. Reporting has also been expanded to include token usage reporting as well.

Old news

Summaries for earlier Jazz Foundation 3.0 milestones: