[OSLC] Generating language bindings for the OSLC interfaces

Scott Rich srich at us.ibm.com
Wed Feb 3 14:50:23 EST 2010


In some places, we're trying out an approach like that described in this
article: "Schemaless Java-XML Data Binding with VTD-XML" (
http://onjava.com/pub/a/onjava/2007/09/07/schema-less-java-xml-data-binding-with-vtd-xml.html
 )  It uses a sparse Java binding using XPath expressions to access the
fields you care about in XML or RDF/XML.  It's optimal for read-only
scenarios, but it's got reasonable update capability, too.  If this is
interesting, we could share more of the details.

We're also using the Jena RDF model for more general handling of RDF data,
but without any additional generation or POJO capability.

Thanks,
Scott

---------------------------------------------------------------
Scott Rich
Distinguished Engineer
Jazz Server Development
(919) 254-1943 (tieline 444)
srich at us.ibm.com





From:       Martin Nally/Raleigh/IBM at IBMUS
To:         Paul McMahan/Raleigh/IBM at IBMUS
Cc:         community at open-services.net,
            community-bounces at open-services.net
Date:       02/03/2010 02:19 PM
Subject:    Re: [OSLC] Generating language bindings for the OSLC interfaces
Sent by:    community-bounces at open-services.net



I'm not a fan of approaches like JAXB. The basic assumption of JAXB and a
whole raft of similar technologies is that the set of properties of an
"entity" is fixed and so can be compiled into a Javabean/POJO with getter
and setter methods. This is a very seductive approach for Java programmers
(or users of other programming languages of that style), but it introduces
major problems. What happens if next week that entity has more properties?
It might even have fewer properties in the future - if the properties that
disappeared are ones that the logic of the application didn't happen to use
it shouldn't affect the application. Why might an entity have more or fewer
properties in the future? One scenario is version evolution - the entity
got richer over time. Another scenario is the dynamic addition of
properties that are specific to a usage. For example, for defects, the most
prominent use-case/application is change management, so the natural
starting point is to define a set of properties for that purpose. Later,
someone might come along with a planning application that needs to add some
more properties. An estimation application might need another set of
properties. An archival application might add an expiry date. The point is
that the set of properties of a defect might evolve not only through
increasing richness of a defect schema over time, but through the dynamic
addition of new applications without central schema control. So how should
a client be programmed to deal with this? If I were coding it, I would
explicitly avoid technologies like JAXB (and EMF and other equivalents)
which are unlikely to have the flexibility to deal with this kind of
dynamism. What would I do instead? I would probably use simple Java Maps
(or the equivalent in your chosen language). Out of curiosity, I might look
at some of the RDF libraries out there, but I'd tread very cautiously. Maps
are just name, value pairs, grouped into sets and RDF is basically the same
idea with a little bit more formal specification and a large dose of
pretentiousness. I would avoid XML Schema like the plague - it's much too
static.

Bottom line - I personally think JAXB, EMF and other such POJO-generators
are a poor technology choice for OSLC client and server implementations -
they are too static - and so I would not be in favor of promoting their
use. I understand not everyone is going to agree with my position on JAXB,
EMF etc. I would also avoid XML Schema. This also is unlikely to attract
consensus.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691


Inactive hide details for Paul McMahan---02/03/2010 01:11:22 PM---I've had
some success using JAXB to generate a java binding fPaul
McMahan---02/03/2010 01:11:22 PM---I've had some success using JAXB to
generate a java binding from an XML schema which describes vario
                                                                           
                                                                           
 From:           Paul McMahan/Raleigh/IBM at IBMUS                            
                                                                           
                                                                           
 To:             community at open-services.net                               
                                                                           
                                                                           
 Date:           02/03/2010 01:11 PM                                       
                                                                           
                                                                           
 Subject:        Re: [OSLC] Generating language bindings for the OSLC      
                 interfaces                                                
                                                                           
                                                                           
 Sent by:        community-bounces at open-services.net                       
                                                                           





I've had some success using JAXB to generate a java binding from an XML
schema which describes various OSLC resources and service description
documents.  The binding basically maps XML to/from POJO.  From what I
understand there are similar tools for other languages.  So I'm interested
in the idea of using tools to generate bindings for the resources and
service documents that flow across the standard GET/PUT/POST/DELETE calls.
I'm curious how this approach might work in terms of RDF schema since it
has advantages over XML schema, and whether its applicable for
representations other than XML.


Best wishes,
Paul McMahan
Rational Quality Management
pmcmahan at us.ibm.com




            Martin
            Nally/Raleigh/IBM
            @IBMUS                                                     To
            Sent by:                  Steve K Speicher/Raleigh/IBM at IBMUS
            community-bounces                                          cc
            @open-services.ne         community at open-services.net,
            t                         community-bounces at open-services.net
                                                                  Subject
                                      Re: [OSLC] Generating language
            02/03/2010 12:17          bindings for the OSLC interfaces
            PM









Has anyone outlined what those bindings would look like? Don't all the
languages already have API for GET/PUT/POST/DELETE? The goal of a
REST-based design would be that there is nothing beyond this except the
ability to understand the domain-specific resource formats. An RDF library
might be useful for this. What else would be useful?

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691


(Embedded image moved to file: pic10293.gif)Inactive hide details for Steve
K Speicher---02/03/2010 08:29:16 AM---Andy, For CM domain I see it playing
out as #1 as most ofSteve K Speicher---02/03/2010 08:29:16 AM---Andy, For
CM domain I see it playing out as #1 as most of the interfaces define

(Embedded      (Embedded image moved to file: pic30196.gif)
image moved to Steve K Speicher/Raleigh/IBM at IBMUS
file:
pic28856.gif)
From:

(Embedded      (Embedded image moved to file: pic10400.gif)
image moved to community at open-services.net
file:
pic20291.gif)
To:

(Embedded      (Embedded image moved to file: pic28662.gif)
image moved to 02/03/2010 08:29 AM
file:
pic19343.gif)
Date:

(Embedded      (Embedded image moved to file: pic04625.gif)
image moved to Re: [OSLC] Generating language bindings for the OSLC
file:          interfaces
pic14108.gif)
Subject:

(Embedded      (Embedded image moved to file: pic25262.gif)
image moved to community-bounces at open-services.net
file:
pic00816.gif)
Sent by:







Andy,

For CM domain I see it playing out as #1 as most of the interfaces define
deeper semantics on REST style hat can't be exposed easily in most commonly
available tools that I'm aware of. We see this now with Eclipse Mylyn and
their exposure of a consumer Java API. I see JavaScript bindings to be of
interest as well. I have not heard of any C#/C++ requests as of yet, though
PHP (as a service provider) I have. Now speaking for Rational products that
use the CM interfaces, we utilize common code (both Java and JS) which has
been manually developed.

Regards,
Steve Speicher | IBM Rational Software | (919) 254-0645


ajberner at us.ibm.com wrote on 02/03/2010 05:14:14 AM:

> To use the OSLC interfaces effectively, client programmers need an easy
way
> to get 3GL language bindings to program against the interface.  In
> practice, most ALM tools, which are the prime candidates to use the
> interfaces, would benefit from either a Java or C# binding.  I can
imagine
> two ways of getting these bindings:
>
> a) For each interface, someone in the community, or a group of members,
> produce the binding by hand and maintain it as the interface evolves
>
> b) Clients use a set of commonly available tools to generate bindings
>
> Can someone from each workgroup comment, please, on how this can be
> addressed for the interface under development?  Which language bindings
are
> of interest (testing my hypothesis that Java and C# will suffice for most
> of the community)?
>
> Andy Berner
> Lead Architect, ISV Technical Enablement and Strategy
> IBM Rational Business Development
> 972 561-6599
> ajberner at us.ibm.com
>
> Ready for IBM Rational software partner program -
> http://www.ibm.com/isv/rational/readyfor.html
>
>
> _______________________________________________
> Community mailing list
> Community at open-services.net
> http://open-services.net/mailman/listinfo/community_open-services.net.
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net.

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net.
[attachment "pic10293.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic28856.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic30196.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic20291.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic10400.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic19343.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic28662.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic14108.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic04625.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic00816.gif" deleted by Martin Nally/Raleigh/IBM] [attachment
"pic25262.gif" deleted by Martin Nally/Raleigh/IBM]
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net.

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/b54883d0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/b54883d0/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21063445.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/b54883d0/attachment-0001.gif>


More information about the Community mailing list