[OSLC] Generating language bindings for the OSLC interfaces

Geoffrey M Clemm geoffrey.clemm at us.ibm.com
Wed Feb 3 22:55:29 EST 2010


Yes, the tool based language binding generators that I am aware of "hard 
wire" in the current semantics in the way that Martin describes, which is 
a primary reason why I don't consider the current tool-based language 
binding generators a good approach.  But a group of humans that understand 
both the extensibility capabilities of the language, and the extensibility 
mechanisms of the REST services, can define a language binding that 
cleanly provides both generic extensible methods (to handle future 
extensions), and type-checkable methods for the current semantics.  But it 
isn't easy, even for a smart group of humans (:-).

Cheers,
Geoff



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


Paul 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/f551b2b2/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20100203/f551b2b2/attachment-0010.gif>


More information about the Community mailing list