Dave Johnson on open web technologies, social software and Java
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.
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.
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
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.
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 , I'm very happy to announce that the OSLC Core v2 specification is FINAL. The OSLC Core v2 specification  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) , OSLC Quality Management (QM)  and OSLC Requirements Management (RM)  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  Move to final was proposed last week, along with a small set of changes which have since been applied to the specification.  OslcCoreSpecification  CmSpecificationV2  QmSpecificationV2  RmSpecificationV2
I really do have another Web Integration Patterns post on the way shortly, so stay tuned.
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:
Link: RDF and OpenSocial
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  and OSLC ). 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?
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:
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.
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.