Friday, February 28, 2014

Considerations with event driven solutions in a Linked Data / OSLC world

I've often been asked about OSLC's plans to support some technology that allows for an event driven model.  Often what this request comes down to is that customers would like to have an open way to subscribe to certain events from a tool and then have that tool (or intermediary) notify them when their criteria has been met.  Once I drill down in the use case a bit further it is often the case that have some clear logic they want to run on the notification receiver side.

For example, let's look at the scenario between a bug tracking system a development team uses and a ticketing system the operations team uses to track customer reported problems.  We've already established how we leverage OSLC to easily relate the ticket from ops to dev.  Though the ops team has a process by which they modify the ticket's status to indicate a fix from development is ready.  The ops team has a number of tools, scripts and reports that run against the ticking system for these 'fix ready' tickets.

There are many ways this problem could be solved, let's take a look at some:

Event driven - this would require new software to be written on both the ticking and bug tracking tool end (perhaps with some eventing software) to make this work.

Polling or cross tool query - there really is no need to promote the state of the ticket to 'fix ready', the ticketing system could just look at (fetch directly) the status of the linked bug.  This would require processes to change on the ops side to not be driven based on that specific state of the ticket but the combined view.

    • A variant of this is to just have the ticketing system poll the bug tracking tool (either when ops person is viewing the ticket or an agent) and set the status of the ticket to 'fix ready'.
Manual - dev sends ops an email/IM/txt, ops loads dashboard with sees bugs from dev that have a fix ready, or NCIS-like where ops shows up to dev with giant slushy asking if and when their reported bug will get fixed.

I think we all have seen the manual way of working, which I don't think I need to highlight what is so not fantastic about this.  I touched briefly on the the impact of the two other automated ways to solved this.  Each requires change --  though in the case of polling, only the consumer needs to change (assuming linking is already there).  Here's a quick summary of considerations with each approach:
  • Event driven
    • Need to manage subscriptions
    • Need to process notifications (which could include processing subscription rules and handling authentication)
    • May require a 3rd party bus (message broker) tool.  This comes with its own costs to acquire and maintain
    • Administration to handle failed notifications (authentication, firewall, server down, etc)
    • Easy model for consumers to just subscribe
  • Polling / query
    • Responses could be cached, polling requests to origin could be intercepted by caching servers and therefore taking the load off the backend tool
    • Linked-to tools never needs to know about external apps
Some of these considerations are of course potentially offset if your organization already has an ESB deployed, so that cost may have already been sunk and the investment in administration expertise has been made.  One aspect of event driven solutions is often a problem of mismatch of models and conflicts of change.  For example, if the configuration (state model) of one of the tools changes it may make it so the ESB can't deliver and process the event to the desired end point.  Also if there is a desired to use this approach to synchronize data, in 1-to-1 or many-to-many, then conflicts will arise and the authority (or master) of the data is perhaps lost.

There are many other factors to consider.  It is often best to sit down and look at the topology of tools today, expected view into the future, and scenarios to see what is right for you.  I'm not saying one is better than the other and there is a clear answer for every integration question that will be asked.  I wanted to elaborate on some of the considerations when looking at each alternative.  Some day OSLC may define or endorse a RESTful event driven approach that meets the scenarios provided by the community.  After all that is what drives the work and those the work in the various groups agree with that, that is what get done.

Wednesday, August 21, 2013

Supporting Accept-Post in JAX-RS applications

Recently in the W3C Linked Data Platform working group we did a survey of the various discovery (or also referred to as affordances) there are for various methods or actions a client may want to introspect or learn from error responses.  One specific scenario is the case of which resource formats (content-types) are accepted by a server when a client wants to send the representation of a resource using POST with the intent of giving birth to a new resource.  The current approaches rely on trial-and-error or some out-of-band knowledge the client application has.  The trial-and-error approach relies on the client sending content of the content-type it believes the server accepts, if the server does accept it and successfully processes the request, it will send back a friendly 201 (maybe 202 or other 200-range) status code.  If the server doesn't like the content-type the client is giving it, it can kindly reply with a 415 (Unsupported Media Type).  Well the client knows what doesn't work but has to guess what might.  Let me introduce you to Accept-Post which is being proposed as a way for a server to tell a client what content-types it prefers.  Accept-Post is somewhat like the Accept header but more closely matches the newer (and less supported) Accept-Patch header.

Ok, that is a enough about the motivation and usage.  I thought I'd share the few lines of Java code needed to support this in JAX-RS 2.0 based implementations.  Since I want the HTTP response header Accept-Post to be returned for a variety of use scenarios such as: when JAX-RS returns a 415, on OPTIONS and HEAD requests, and so on, I decided to always return the header.  To do this, I implemented the ContainerResponseFilter with a simple Class and filter() method as:


public class AcceptPostResponseFilter 
       implements ContainerResponseFilter {
   public void filter(ContainerRequestContext requestContext,
                      ContainerResponseContext responseContext) 
                      throws IOException {
         "text/turtle", "application/ld+json", "image/png");

That is about it, except of course you needs to register this filter with your JAX-RS Application, such as:
import java.util.HashSet;
import java.util.Set;

public class MyApplication extends Application {
   public Set<Class<?>> getClasses() {
      Set<Class<?>> classes = new HashSet<Class<?>>();
      return classes;

I've made this change for the in-progress LDP reference implementation occurring at Eclipse Lyo.

Similar approaches to other web server implementations or configurations make implementing Accept-Post quite trivial as well. Feel free to provide feedback on the IETF working draft for Accept-Post as well.

Tuesday, August 13, 2013

OSLC Resource Models - pictures are worth a thousand words

Pardon the metaphor but seems quite accurate here that in order to scale, OSLC working groups (WGs) operate as near-independent groups.  These WGs all produced their piece of the overall picture of resources, their properties and relationships to other types of resources.  The resource models (sometimes referred to as data models) were driven based on a key set of integration scenarios and defined following guidance produced by the Core WG.  The Core WG itself even has various models to support a number of cases such as: describing service providers, resource shapes, discussions, and other commonly used terms.  With all these pieces often laying around in separate specifications (Wiki pages, vocabulary documents, etc) it can be quite helpful to pull these all together...especially using visualization of the resource models.
This first figure is an example of a diagram from the perspective of an OSLC Change Management Change Request definition.

I'll go into a bit more detail about this model a bit later.

In an attempt to simply view these resource models, I started with some work that Scott Rich had done, along with some approaches I had experimented with using Rational Software Architect (RSA)

To keep things very simple, I'll highlight some guidelines on how to develop this model in a UML modeling tool:

  • This is just a picture (for now), semantics are not clearly defined and they are not those of OO design.
  • All properties are modeled as an  'Attribute', they are just visualized in the diagram as an association (since property values/objects in RDF are nothing special).
  • Each domain, which has its own vocabulary document, is a separate package.  Also give each domain/package its own color
  • No special profile is used (I attempted to use OWL profile from OMG).
  • Even though there isn't an example restriction on the resource types (range) of properties, an explicit expected Class is still set.  A diagram with everything pointing to rdf:Resource wouldn't be too interesting.  Note to self: create a stereotype/visualization to make this obvious.
Ideally (and I know my modeling geek friends are going to like this) we can transform to/from some other descriptive form (OSLC Resource Shapes + RDFSchema).

The current model has been shared in the Eclipse Lyo project and additional examples are highlighted over on the OSLC Core wiki page.  I tucked the RSA model file into an Eclipse project titled org.eclipse.lyo.model which you can find in expected git location.  For those that use some tool other than RSA, I have also provided the .uml file.  I'd be interested to hear if anyone has another tool (and/or approach) to modeling these.  I'll try to advance in my spare time, including improving the diagrams.

Friday, July 19, 2013

OSLC's motivation on the design of the LDP Container

It is often that when some concepts in specifications exist, it is hard to tie together the learning from past experiences and what had been considered prior.  Sometimes preserving this and providing the background is too much filler for some already long documents, so I will use this opportunity to pull together a series of activities.  Some of these activities can be found in OSLC 1.0 specs and elsewhere.

All these approaches were motivated with a set of requirements which are quite similar:

  • Common patterns for dealing with multi-valued properties
  • These multi-valued properties often become large
  • Easy way to get all the properties
  • Easy way to add new property values
Below are a sample of approaches

OSLC CM 1.0 - @collref

In CM 1.0, when these patterns first evolved and we were working on applying REST we came up with a concept of @collref which was an XML attribute that held the value of the URL of the collection where you could POST to add new members and GET on to get a list of all members.  This approach was developed based on some legacy XML and pragmatic need to solve a narrow problem.  It would for a good number of cases but was a bit special and non-standard.

OSLC CM 2.0 - multi-value props

In CM 2.0 and Core 2.0, we took a more RDF-view of REST and simply treated these as multi-valued properties or in RDF terminology they were same-subject and same-predicate triples.  They were just like any other property on a HTTP (OSLC) resource, using GET to fetch the representation of the state of the resource, POST to create it and PUT to update.  This approach worked well in that it didn't require any new invention but was limited by what existed, it would be good if we could layer on semantics without losing the simple usage of RDF to define the resources.

OSLC CM 3.0 - multi-value props + LDP Container

In drafts of CM 3.0 and Core 3.0, we look to build off a concept called Linked Data Platform Container defined by Linked Data Platform 1.0.  This isn't far from what we've done in 2.0 except it is based on a W3C specification and has some additional semantics, namely layering on the ldp:Container semantics.

Other motivation

Another key scenario motivating similar requires is dealing with things such as query results or filtering long lists of resources and where to POST to create new ones.  In Core 1.0 and 2.0, we used concepts such as query capability and creation factory to meet these needs.  As we see with ldp:Container, this provides that same function while we can annotation it to provide some of the additional needs for knowing what kinds of resources a server will accept in a container it hosts and things like Web UI dialogs that can be used to select and create resources.

Thursday, May 23, 2013

Applying LDP concepts to bug tracker

In this post I'll explore how some products that support bug tracking, such as Rational Team Concert, model their internal "Work Item" resource given W3C Linked Data Platform and OSLC concepts.  This will also highlight how various capabilities are needed to solve some key problems in a simple way.  I will be "paraphrasing" what the actual runtime resource will look like to help with human consumption of the examples (as the real-world ones can sometimes have additional concepts and capabilities that don't apply to the simple part of the model we are focused on here).

Let's take one of the most simple examples of what one might find, let's say a bug (aka "Defect") that has a few properties but no associated attachments or child bugs.

Representation of bug
@prefix dc:  <> .
@prefix ocm: <> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" .

Now we'll explore how add a couple screen shots to the bug. Using this information I have with this resource, I'm not sure how I do that (assuming I am a Linked Data client). I could just attempt to PUT replace the contents and add a ocm:attachment statement referring to the screenshot. Depending on the server, it may reject it for a couple of reasons, such as: it doesn't known anything about ocm:attachment, or it has restrictions on the object (where the attachment is physically stored), or simply PUT updates not allowed for ocm:attachment.
To help with this problem, we can associate an ldp:Container with this bug resource to assist with this. So we expand our example, with out modifying any of the original model, just adding a few more statements.
@prefix dc:  <> .
@prefix ldp: <> .
@prefix ocm: <> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" .

<attachments> a ldp:Container ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.

This tells my client now that we have an ldp:Container associated with the bug, since the ldp:membershipSubject connects this container to the bug. I can inspect also ldp:membershipPredicate to know for which same-subject and same-predicate pairing I can use this container to assist with managing and navigating them.
Now I have a URL where I can POST a screenshot to create an attachment and associate it with bug 13. Let's look at what the POST looks like:
Slug: screenshot1.png
Content-Type: image/png
Content-Length: 18124

[binary content]

Content-Length: 0
Now that the attachment has been created, we can fetch bug 13 again to see what we have.
@prefix dc:  <> .
@prefix ldp: <> .
@prefix ocm: <> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" ;
   ocm:attachment <attachments/3> .

<attachments> a ldp:Container ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.
We now see that there is an ocm:attachment statement associated with bug 13. This statement was added by the server when it processed the POST request to create a new resource (attachment) and then added it as a member of the attachments associated with the bug.
We can also see that this list can grow to be quite large. Experience has shown, that end users of bug trackers need to attach a number of documents, images, logs, etc. with bugs. This need also comes from a number of other capabilities such as having nested bugs or tasks. To illustrate, let's assume our bug tracking server has been upgrade or now exposes children resource within bug resources (or has had children added by other means). Let's take a look at bug 13 again:
@prefix dc:  <> .
@prefix ldp: <> .
@prefix ocm: <> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" ;
   ocm:attachment <attachments/3>, <attachments/14> .
   ocm:child <../47>, <../2> .

<attachments> a ldp:Container ;
   dc:title "Attachment container for bug 13" ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.

<children> a ldp:Container ;
   dc:title "Children for bug 13" ;
   ldp:membershipPredicate ocm:child ;
   ldp:membershipSubject <>.

As you can see, the bug model stays very simple with statements about bug 13 being made directly about it using simple RDF concepts where the statements are of the form [bug13, predicate, object|literal]. We can repeat this pattern and use it in many other forms, such as a container of all the bugs the serve knows about, which I plan to illustrate in other posts.
Disclaimer: some of the predicates used in these examples show they are in the OSLC-CM namespace but have not been approved by the WG. This was done just for simple illustration.

Thursday, May 9, 2013

Making progress towards an OSLC-CM 3.0

Been a while I have talked about a specific domain working group and what has been going on.  Though the work for a post-2.0 Change Management specification has been evolving for some time, it is coming along nicely.  I've been focusing much of my energy on getting the core-est part of Core (W3C Linked Data Platform and Core 3.0) rolling, while keeping an eye and hand involved with CM.

To summarize the OSLC-CM WG has looked at a number of prioritized scenarios:

We currently have draft specification text for most of the scenarios above.  We are planning to enter into convergence soon and start to do some implementation to validate the specifications.

Special thanks to Sam Padgett for leading the OSLC-CM efforts, planning meetings, keeping minutes, keeping track of issues and pushing forward with the draft specification.  Looking forward to getting some of these approaches implemented and specification wrapped up.

Thursday, April 11, 2013

Trip Report from EclipseCon 2013

I had a chance, along with Michael Fiedler,  to attend the US EclipseCon 2013 in Boston, MA in late March.   In addition to presenting a BOF and a session on OSLC, Linked Data and Lyo, we were able to attend several sessions, panel discussions and BOFs.   It was also a great chance to meet with members of the OSLC and Lyo communities to discuss the challenges of tool integration.

General Impressions from the Conference

It was cool to see and hear OSLC and Eclipse Lyo in a variety of sessions.  There were good active discussions with the Eclipse Mylyn team regarding their recent m4 proposal, including how OSLC and Lyo play a key part.  It was good to explore ways we could work together with Mylyn, Orion, Hudson and more.  We did do a lot of education and exploration with a number of attendees that had no or limited knowledge of what was going on within OSLC and Lyo.  Various panels, keynotes and sessions often called out the need for tool vendors to be able to collaborate on open interfaces....we asked them: "have you heard of OSLC?"  There were a number of people making the case for OSLC-based integrations very easy.
Here is a summary of the two sessions we presented at EclipseCon:

1) Lifecycle Tool Integrations: Linked Data, OSLC and Eclipse Lyo
Session type: Birds of a Feather

The participants ranged from experienced OSLC implementers interested in contributing to Eclipse Lyo to those new to OSLC looking for learning resources. 
The discussion covered the re-vamped tutorial on, using the Lyo OSLC4J Bugzilla adapter as a learning resource and some general OSLC and linked data integration philosophies.  Topics included:
  • a description of an OSLC4J implementation in progress which exposes EMF Models as OSLC resources - being considered for contribution to Lyo
  • the experiences of a developer who has implemented several OSLC integrations to enable tools to participate in an ALM system
  • The OSLC CM 1.0 integrations developed for the Mantis bug tracker and FusionForge
  • Status of Eclipse Lyo - what is new in 1.1 and what is coming
  • One OSLC implementer strongly recommended developing integrations using 2.0 of OSLC.  He also pointed out authentication is a primary painpoint for the work he has done.

2) Leveraging W3C Linked Data, OSLC, and Open Source for Loosely Coupled Application Integrations
Session type: ALM Connect track

This session was a 35 minute tour through tool integration, problems with previous approaches and new approaches using linked data and OSLC.
This was followed by an overview of open source projects relevant to this space (Jena, Wink, Clerezza, Lyo etc) and a brief demo of some potential integrations between Eclipse Orion and a Change Management tool (Bugzilla) and an Automation tool (Lyo automation reference implementation).   
There was very little time left for questions at the end, but there were some good ones which pushed the session into overtime: 
  • Interest in the concept of delegated UIs and the responsibilities of the tool hosting them - described the OSLC concepts in some detail
  • Interest in the concept of UI previews and compact representations.   How these resources can be used to link to full representations was described.
  • Some clarifying questions were raised by a few folks about the details of the Bugzilla integration demonstrated.   Explained it is the live Eclipse Bugzilla instance, but that it could have been any OSLC CM provider.
Special thanks to Michael Fiedler for both authoring some of this content of this blog post, as well as building the demo, presenting and too many things to list here.