Blogging Roller

JIRA finally gets its own REST API

2012-03-01T09:20:30+00:00

JIRA's got a real REST API now:

REST easy with JIRA 5 | Atlassian Blogs: Now that JIRA 5 is out, let’s talk about one of my favorite features of this new release, JIRA’s new REST API. JIRA has supported remote APIs for many years with SOAP, XML-RPC, and JSON-RPC. However, telling developers that you support SOAP (and only SOAP) is like saying that you like writing applications with COBOL — it’s out of style. Today’s cool kids gravitate towards REST. It’s clean, simple, and highly portable across languages and frameworks.

And checkout the nice looking API docs, which look like they were generated by WADL-to-HTML.

An alternative to Atlassian's new API is the recently release Rational OSLC Adapter for JIRA, which allows you to do more sophisticated integrations with JIRA including delegated UIs for issue creation and selection.

WIP: Resource Preview

2011-06-03T09:00:35+00:00

This is the fourth in my series of Web Integration Patterns. Check out the intro at this URL http://rollerweblogger.org/roller/entry/web_integration_patterns

Synopsis

Enhance links shown in HTML pages so that users can hover, mouse-over, or use some other gesture, to view a preview of the resource at the other end of the link.

Motivations

Make it convenient for a user to get information about a link but without having to navigate to the link and without having to leave the current web page in the browser.
Make applications appear to be part of one integrated whole by enabling them to delegate to each other's user interfaces for preview display.

Complements

Links
Delegated Resource Creation & Selection
Common Navigation

This pattern allows users to view a preview of links that are displayed in a web page. This preview might be a simple tool-tip with plain-text, a more rich JavaScript-driven display with hyper-text and graphics, or it might be a thumbnail view of the page at the other end of the link.

Resource Preview works well for web applications that use the Links pattern for integration and use links to establish relationships between resources. If a user is looking at a Bug Report, for example, they might see a list of links to associated resources like attachments to the bug, test cases impacted by the bug, etc. The user can hover over links and see a preview with key information for each link, without leaving the current web page that they are on. Below are three different approaches to applying the Resource Preview pattern in web applications.

Approach #1: Preview Site offers previews to other applications

With this approach, there is a special preview site that crawls a set of web sites and creates Resource Previews of the web pages of those sites. Then, web sites that wish to display previews on links use some special JavaScript magic to display those previews. An example of this preview site approach is Snap.com’s Snap-Shots service. Anybody with a web site can sign up for the service, get some special HTML code that can be added to their site to display a graphical and thumbnail-style preview whenever a user hovers over a link.

Here’s an example of a Snap.com preview on the company’s blog:

The advantages of the preview site approach are participating sites don’t have to do anything except for adding a small bit of JavaScript code to enable previews. The disadvantage is that the automatically generated previews often can’t offer more than a page title, thumbnail image and perhaps a short excerpt from the page being previewed. Also, it’s interesting to note that there was a backlash against Snap-Shots and some people thought they were distracting and gimmicky. Regardless of that criticism, this approach to Resource Previews is not very interesting from a Web Integration Patterns point of view because the focus is making one site more useful and interactive, and not integrating with others.

Approach #2: Application creates and displays previews as needed

With this approach, an application that needs to provide preview creates the previews that it needs and take case of displaying them. The best known examples of this approach are probably the preview features built into Microsoft’s Bing and Google’s search engine. This approach is also not very interesting as a WIP because its all about making one site more useful, not integrating with others.

Here’s an example of a Resource Preview in Microsoft Bing:

Approach #3: Applications offer previews of their own resources

This approach is to enable web applications provide previews of their own resources and make them available via a simple protocol. The best example of this approach is OSLC UI Preview, which is part of the OSLC specifications. The OSLC specs are designed to enable integration between ALM tools, but can be applied to integrating web applications of almost any stripe. Applications that implement OSLC UI Preview provide a UI Preview for each resource, one that provides a summary of the resource and links to large and small previews of the resource.

Here’s an example of an OSLC UI Preview from FusionForge, an open source ALM suite:

Here’s an example of a Resource Preview from IBM Rational Team Concert, which also implements the OSLC UI Preview spec:

There are several advantages to this approach. Preview-providing applications have complete control over the content and appearance of previews for their resources. Preview-consuming applications don’t have to create and format them, they just display what comes back from the provider. No special preview site is needed to enable previews. Another advantage to this approach to Resource Previews is the OSLC UI Preview specification, which defines an open and standard way to provide and consume previews.

Wrapping up

I've explained what I call the Resource Pattern and three different ways that I've seen it used. Resource Preview is a good way to add value to the Links pattern and to make links even more useful. The best way to implement this pattern is to ask all web applications that want to integrate to offer Resource Previews via a standard protocol such as OSLC UI Preview, and to display them whenever a user hovers over a link.

OSLC Core v2 specification now FINAL

2011-06-01T14:38:13+00:00

I've been working on the OSLC Core specification for about 1.5 years now as workgroup lead, and OSLC fits squarely under the "open web technologies" and Web Integration Patterns topics of this blog, so I'm blogging this happy news.

Here's the announcement From the OSLC Core Workgroup mailing list:

From: Dave Johnson
To: oslc-core (a) open-services.net, community (a) open-services.net
Subject: OSLC Core v2 specification now FINAL

Today [1], I'm very happy to announce that the OSLC Core v2
specification is FINAL.

The OSLC Core v2 specification [2] defines a set of REST and Linked
Data-based patterns, resources and protocols for integration of application 
and product lifecycle resources (ALM and PLM). It's designed to be the
foundation for all other OSLC domain specifications and there are now
three final OSLC specifications that are based on the Core, those
being the OSLC Change Management (CM) [3], OSLC Quality Management
(QM) [4] and OSLC Requirements Management (RM) [5] specs.

I'd like to thank all of the members of the OSLC Core Workgroup and
community for their hard work, critical thinking and ability to work
together in such a productive and pleasant way. Also, special thanks
to those OSLC domain workgroups who rebased their work on the Core and
development teams that provided excellent feedback along the way.

Thanks,
- Dave

--
David M. Johnson
OSLC Core Workgroup Lead
IBM Rational Software

[1] Move to final was proposed last week, along with a small set of
changes which have since been applied to the specification. 
[2] OslcCoreSpecification
[3] CmSpecificationV2
[4] QmSpecificationV2
[5] RmSpecificationV2

I really do have another Web Integration Patterns post on the way shortly, so stay tuned.

re: RDF and OpenSocial

2010-12-03T08:22:48+00:00

This is the closest thing to a blog post that I've written lately, a post to the OpenSocial specification group on aligning OpenSocial with RDF and Linked Data:

This is a topic of interest to me, so I'll try to elaborate.
First, I want to point out that RDF is not a representation, it's a way to model data and it's multiple ways to represent that data (in XML, JSON, etc.). I think the real question is: how do we enable OpenSocial to hook into the RDF-based web of "Linked Data" that is rapidly growing up around scientific data, government open data and the academic world. I'm not going to go into the benefits of Linked Data in this post, but I will disclose that I work for a company that uses RDF as a common data model to enable loosely coupled integration across our web application products (see also Jazz Integration Architecture [1] and OSLC [2]). We'd like to be able to integrate with OpenSocial services in the same ways.

I'll explain the basics of RDF. RDF is way to model web data and ways to represent that data in XML, JSON, Turtle, etc. The RDF data model is simple, we have resources identified by URIs and property values associated with those resources. Resources can have types, each type is identified by a URI. Property types have URIs too. Once you have defined your data model in terms of RDF types and properties, you can represent resources and their properties using RDF representations. There's RDF/XML for XML, there's RDFa for embedding properties in HTML. There's are JSON representations too, but not a standard for JSON yet.

So, to bring OpenSocial in-line with the world of Linked Data, we would define each class of OpenSocial objects as an RDF type, with a URI. We would define each OpenSocial property as an RDF property, with a URI. In some cases, we'll want to use existing properties, like the Dublin Core title, name, etc., and in some cases we'll want to define entirely new types and properties.

As a starting point, I think we would do the following:

* In OpenSocial v2, we would define all OpenSocial objects and properties as RDF types in the OpenSocial Specs. This means simply assigning a URI to every class and every property we define, using standard properties where appropriate and defining new ones as needed. Object and property names would rename the same and we'd have what is essentially an RDF mapping built into the spec. Existing OpenSocial representation formats would stay the same, but we'd add some new RDF representations.

* We'd introduce an optional new OpenSocial spec that services MAY implement: the OpenSocial RDF Specification. The specification would simply require that a service provide RDF representations of it's resources via content-negotiation. The service could offer RDF/XML or HTML with RDFa, JSON/RDF or all of the above.

That's a starting point and I think we could come up with some other ideas if we thought more about use cases. Anybody else interested in aligning the worlds of OpenSocial and Linked Data?

Link: RDF and OpenSocial

[#JRA-19796] REST API for JIRA

2010-05-11T18:20:48+00:00

It's kind of surprising to me that JIRA does not have a "REST API." Looking on the bright side, this may be an opportunity for Open Services for Lifecycle Collaboration (OSLC) to show its value, so back in March I made a little pitch in the appropriate JIRA issue:

JIRA-19796 - REST API for JIRA

Dave Johnson added a comment - 10/Mar/10 9:24 AM - edited

You should consider making the JIRA REST API conformant with the Open Services for Lifecycle Collaboration (OSLC) interface for Change Management (OSLC-CM). This would allow JIRA to integrate with ALM tools from IBM, Oracle, Rally, SourceGear, etc. The Mylyn folks are already involved. Here's the link to the OSLC-CM home page: http://open-services.net/bin/view/Main/CmHome. OSLC-CM v1 is the current spec and work on v2 is underway. It's an open effort and we'd love JIRA and/or JIRA users to join in and help us define v2.

Talking OSLC at Innovate 2010

2010-04-28T07:57:21+00:00

I haven't mentioned it yet here on my blog, but I've been working as the spec lead for the Open Services for Lifecycle Collaboration (OSLC) since January of this year.

I hope to blog about OSLC more later, but now I'm writing to tell you about a talk that I'll be doing with Rational Chief Architect John Wiegand at Innovate 2010 The Rational Software Conference in Early June. Here are the details:

Session: ALM-2210B: Open Services (OSLC) and Jazz: Working Together

When: Mon, 7/Jun, 3:00 PM - 4:00 PM
Where: Dolphin - Northern Salon E4

Rational proposed the Open Services for Lifecycle Collaboration (OSLC) initiative at the Rational Software Conference in 2008 to make life better for software delivery teams by easing the way tools can be used in combination. Two years later, we are gratified to see an active and open community making this vision a reality. This presentation will explain the challenge of tool integration, how the OSLC community is addressing the challenge, and how Jazz builds atop OSLC to deliver an open lifecycle platform

For more information on OSLC, visit http://open-services.net

UPDATED: scheduled change - talk is now 3PM to 4PM.

Interested in attending Innovate 2010? You can register here.

Latest Links: OpenSocial and OSLC

2009-06-09T16:00:03+00:00

Stutzman on WUNC's the State of Things
Stutzman and others on the etiquette, the addiction and the future of Facebook
Is Twitter Really That Big?
40% of Twitter users haven't tweeted since 1st day, 25% not following anybody
YouTube - Towards Privacy-aware OpenSocial Applications
Talk by Kun Liu of IBM Research on privacy scoring and applications

Google I/O video - Atlassian and OpenSocial
using OpenSocial to connect enterprise apps and power developer dashboards.
Atlassian - OpenSocial Videos
Atlassian has gone ga ga for Gadgets

YouTube - What is New in Rational Team Concert 2.0 Web UI
from Dejan Glozic, Team Concert Web UI and Dashboards Lead
Mainsoft Document Collaboration for Rational Jazz
connects Rational Team Concert to your corporate collaboration infrastructure.

The Open Services for Lifecycle Collaboration (OSLC) initiative
creating open interfaces for software development services: requirements, change requests, user stores, test cases and more.
dW podcasts: Abrams, Zetie and Kerston on OSLC
Interview with some of the folks behind OSLC.