[MOBY-dev] java api

Tue Feb 15 17:37:21 UTC 2005

Hi all,

    I'm replying directly to you since the mailing list gets confused 
over my various e-mail addresses and bounces messages (I'm trying to fix 
this).  We should definitely open a dialog even before the May meeting 
because it seems that a lot of people are trying to acheive the same 
goals, and I think  most of the code to do these things are already in 
place.  For parsing and outputting data, org.biomoby.client.MobyRequest 
should be able to act as both the client and server code as MOBY 
messages are the same from a formatting point of view.  MobyRequest is 
nice and robust too, because it uses namespace-aware XPath to grab the 
relevant payload data.

In principle you should also not need to touch the XML directly, and we 
are almost to that stage.  Martin created the base type classes for when 
he started the registration side of things in Java:

org.biomoby.shared.MobyData 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyData.html>
org.biomoby.shared.MobyPrimaryDataSimple 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSimple.html>
org.biomoby.shared.MobyPrimaryDataSet 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyPrimaryDataSet.html>

I then extended these classes for actual instances of MOBY data (so they 
can conveniently be used for querying MOBY central and running services):

*org.biomoby.shared.MobyDataSetInstance*
org.biomoby.shared.MobyDataSimpleInstance 
<http://www.biomoby.org/moby-live/Java/docs/API/org/biomoby/shared/MobyDataSimpleInstance.html>*
**org.biomoby.shared.MobyDataFloat (arbitrary precision)*
*org.biomoby.shared.MobyDataInt (arbitrary precision)*
*org.biomoby.shared.MobyDataString

*And a convenience class for otherwise painful to parse data (ISO 8601):*

**org.biomoby.shared.MobyDataDateTime*

Since an object is always made up fundamentally of the base classes 
object, string, int and float, there should be no need to generate any 
more classes to hold the data.  The only thing that remains is defining 
the methods in MobyDataSimpleInstance to set the data members for 
composite objects (maybe addMember(MobyDataSimpleInstance)?) and perhaps 
do a run-time check against MOBY Central that the data type given in 
setDataType is fullfilled before to XML() is called.

I was thinking something like this (PDGJOB is probably the most complex 
objects registered right now):

MobyDataSimpleInstance mdsi = new MobyDataSimpleInstance(new MobyDataType("PDGJOB"), "random object name", "some object id");
mdsi.addMember(new MobyDataString("answerService", "put your favorite answer service name here"));
mdsi.addMember(new MobyDataString("authURI", "http://my.great.domain.org/"));

GregorianCalendar gc = new GregorianCalendar();
gc.add(Calendar.MINUTE, 10); // Time out in 10 minutes
mdsi.addMember(new MobyDataDateTime("timeout", gc);

mdsi.addMember(new MobyDataString("killcode", "12345");
mdsi.addMember(new MobyDataString("killService", "put your favorite kill service name here");

As  service provider, to get the MOBY enveloped required to send this 
back to a client we call:

Central worker = new CentralImpl ();
MobyRequest mr = new MobyRequest(worker);
String responseXML = mr.convertMOBYDataToMOBYRequest(mdsis);
/* proceed to send this response back through the SOAP call you've 
received to start this code execution*/

If we are the client and we were SENDING this data instead, we can 
simply use the MobyRequest built-in SOAP handling:

mr.setInput(mdsi);
Vector output = mr.invokeService();

My CDN$0.02 :-)

Paul

Benjamin Good wrote:

> Hi moby-dev,
>
> I think this from Simon sums up something that would be handy for 
> everyone in the jMoby group - both client and service providers -(that 
> hasn't written their own version already).
>
> The
>
>> basic goal was to create some basic classes to simplify access to the
>> MOBY payload of a webservice call so that we could concentrate on
>> getting the services up rather than parsing the MOBY XML and rewriting
>> the XML prior to returning the result.
>
>
> I don't really know the protocol here, but perhaps someone could post 
> an Interface that others could check out, comment on, and code to?  Or 
> perhaps some one already has a good solution?
>
> -Ben
>
>
> ------------------------------------------------------------------------
>
> Subject:
> MOBY Service code developments
> From:
> Mark Wilkinson <mwilkinson at mrl.ubc.ca>
> Date:
> Tue, 15 Feb 2005 07:01:50 -0800
>
> To:
> Ben Good <bgood at mrl.ubc.ca>, Eddie Kawas <ed.kawas at gmail.com>, mobydev 
> <moby-dev at biomoby.org>
>
>
> I think both Ben and Eddie are working on things like this as well.  Ben
> is at a course doing "wet" work (ugh!) this week, but Eddie should be
> on-line somewhere.
>
> Xref'ing with each other early on would probably be worthwhile - divide
> and conquer  :-)
> I found in Perl that the code used by services was often identical to
> that used by clients, so I ended up putting these kinds of routines into
> a "neutral" location (MOBY::CommonSubs).  It's probably worthwhile
> considering that rather than coding service/client specific modules...
> if you haven't already.
>
> M
>
>
> -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical 
> Genetics, UBC, Canada
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [moby] Re: [MOBY-dev] BioMOBY developers meeting pre-announcement
> From:
> ywong at infobiogen.fr
> Date:
> Tue, 15 Feb 2005 09:18:47 +0100 (CET)
>
> To:
> "Core developer announcements" <moby-dev at portal.open-bio.org>
>
>
> Hi,
>  I know that someone at mips (Octave Noubibou) is also working on that
> field, on my side, I have an API in Java (based on the Python API) that
> helps me to build moby webservices (with axis or j2ee)
>
>
>>> Hi Mark,
>>>
>>> I'll see how things are looking and get the documentation together. The
>>> basic goal was to create some basic classes to simplify access to the
>>> MOBY payload of a webservice call so that we could concentrate on
>>> getting the services up rather than parsing the MOBY XML and rewriting
>>> the XML prior to returning the result. We've been using Axis to handle
>>> the webservice part of the equation, we've created some core classes
>>> and have a simple test service prototype that we are gearing up to do
>>> something meaningful with. If you have people doing similar things it
>>> would be great to get an overview of what you are working on too so we
>>> can divide and conquer where possible.
>>>
>>> Simon.
>>>
>>>
>>> On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>
>>  
>>
>>>>> Hey Simon,
>>>>>
>>>>> Please post to the mailing list with your moby java activities 
>>>>> since I
>>>>> have several people doing similar things - no point in duplicating
>>>>> effort if we can split the work  :-)
>>>>> I'll be posting the URL for the registration page before weeks end -
>>>>> I'm just waiting for a quote on the room rate.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> M
>>>>
>>>   
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>>
>>> -- 
>>>
>>> Simon N. Twigger, Ph.D.
>>> Assistant Professor, Department of Physiology
>>> Medical College of Wisconsin
>>> 8701 Watertown Plank Road,
>>> Milwaukee, WI, USA
>>> tel: 414-456-8802
>>> fax: 414-456-6595
>>> AIM/iChat: simontatmcw
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>  
>>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>