[MOBY-dev] Updates to MOBY Central and IMPORTANT NOTES forregistry hosts
Romina Royo
rroyo at lsi.upc.edu
Tue Feb 6 16:18:33 UTC 2007
Hello Mark,
I used gbrowse to call one of our services:
- first test we had .69 on the server side and as you said it worked ok
- second test we had 0.60 on the server side and it also worked ok.
I hope this is the test you were asking for :-)
Thanks!
Romina
Mark Wilkinson wrote:
> Hi Romina,
>
> I can confirm that calling services running S::L 0.69 from a client
> running S::L 0.55 is succesful. .69 to .69 is obviously OK also. What I
> have not yet successfully tested is calling a service from a .69 client to
> an earlier version on the server-side. The way to do that would be to use
> gbrowse_moby on the mobycentral machine, but I don't know what versions of
> Perl anyone else is running so I can't reliably do that experiment... can
> anyone try one of their Perl services from gbrowse-moby on a server with
> perl 0.60 or less?
>
> MOBY Central itself seems fine... and Java invocations of services seem
> fine also (largely because the Java libraries don't use the WSDL from MOBY
> Central to create their connections... there may be a lesson in there
> somewhere! Ugh... WSDL!!)
>
> M
>
>
>
>
> On Tue, 06 Feb 2007 07:38:59 -0800, Romina Royo <rroyo at lsi.upc.edu> wrote:
>
>
>> Hello again,
>>
>> Mark, I just called your service and it did work.
>>
>> Eddy, if those are some of the errors you fixed yesterday I might be
>> doing something wrong. Let me re-check everything and if the errors are
>> still there I'll send you more details about the code I'm using.
>>
>> Thank you very much!
>> Romina
>>
>>
>>
>> mark wilkinson wrote:
>>
>>> Hmmmm... Well that's a bit of a disaster!
>>>
>>> Could you check what happens when you call one of my services (eg
>>> MOBYSHoundGetGenbankff)? I wonder if SOAP::Lite versions don't talk to
>>> each other properly (which would be a nightmare, but given our
>>> experiences yesterday, not surprising!)
>>>
>>> M
>>>
>>>
>>> --
>>> Mark Wilkinson
>>> ...on the road!
>>>
>>>
>>> -----Original Message-----
>>> From: Romina Royo <rroyo at lsi.upc.edu>
>>> Date: Tue, 06 Feb 2007 15:25:15
>>> To:Core developer announcements <moby-dev at lists.open-bio.org>
>>> Cc:mobydev <moby-dev at biomoby.org>
>>> Subject: Re: [MOBY-dev] Updates to MOBY Central and IMPORTANT NOTES for
>>> registry hosts
>>>
>>> Hello,
>>>
>>> I updated the moby-live/Perl libraries from cvs and I installed
>>> SOAP::Lite 0.69.
>>>
>>> Here are some of the results I got:
>>>
>>> - When executing a synchronous Perl service (function execute in
>>> Client/Service.pm) I got this error:
>>>
>>> <SOAP-ENV:Fault><faultcode>SOAP-ENV:VersionMismatch</faultcode><faultstring>Wrong
>>> SOAP version specified. Supported versions:
>>> 1.1 (http://schemas.xmlsoap.org/soap/envelope/)
>>> 1.2 (http://www.w3.org/2001/06/soap-envelope)
>>> </faultstring></SOAP-ENV:Fault>
>>>
>>> mm.. I guess it is OK because the service provider might be using some
>>> other SOAP version?
>>>
>>> - When doing the same test on one of our services (SOAP::Lite 0.69
>>> installed on the service side). I got this error:
>>>
>>> <soap:Fault><faultcode>soap:Client</faultcode><faultstring>Application
>>> failed during request deserialization:
>>> xml declaration not at start of external entity at line 1, column 941,
>>> byte 941 at
>>> /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/XML/Parser.pm
>>> line 187
>>> </faultstring></soap:Fault>
>>>
>>> - When executing a Java service:
>>> <soapenv:Fault>
>>> <faultcode>soapenv:Client</faultcode>
>>> <faultstring>org.jboss.axis.AxisFault: Version Mismatch</faultstring>
>>> <detail/>
>>> </soapenv:Fault>
>>>
>>> and again, it might be ok?
>>>
>>> - When trying to retrieve the wsdl of a 'moby-async' service (function
>>> retrieveService) I got this error:
>>>
>>> Connection to MOBY Central at
>>> 'http://mobycentral.icapture.ubc.ca/MOBY/Central'
>>> died because:
>>> Can't use string ("<?xml version="1.0"?>
>>> <definiti") as a symbol ref while "strict refs" in use at
>>> /usr/lib/perl5
>>> /site_perl/5.8.5/MOBY/Central.pm line 3290, <IN> line 371.
>>>
>>> ERROR ERROR ERROR
>>>
>>> The function retrieveService does work when the service is not
>>> 'moby-async' though.
>>>
>>> - When executing an asynchronous service (function
>>> Async/Service/execute) everything seems ok.
>>>
>>> Has anyone had similar problems? Any ideas?
>>>
>>> Thank you!
>>> Romina
>>>
>>> Mark Wilkinson wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> First off, apologies to anyone who was trying to get through to MOBY
>>>> Central this afternoon - Eddie and I were making the changes necessary
>>>> to
>>>> get it ready for SOAP::Lite 0.69 and the changes that worked perfectly
>>>> on
>>>> the test server didn't work on the real MOBY Central... so it took a
>>>> couple of hours of troubleshooting before we had it back up again.
>>>>
>>>> The good news is that it seems to work correctly with both Perl and
>>>> Java
>>>> clients. What we don't know is if it is backwards compatible with
>>>> earlier
>>>> versions of the MOBY::Client::* libraries, in particular,
>>>> MOBY::Client::Service. I *think* it is, but we didn't have the
>>>> opportunity to test it. In any case, the API did not change, so if you
>>>> just cvs update your client libraries everything should come back to
>>>> life
>>>> if it isn't working.
>>>>
>>>> Upgrading to SOAP::Lite 0.69 was a nightmare! The new SOAP::Lite
>>>> behaves
>>>> subtly differently than the old one in several ways that we were not
>>>> expecting. Thankfully, Pieter and Eddie had done most of the
>>>> trouble-shoting already, but it still threw us for a loop in some
>>>> places
>>>> with incompatible SOAP version errors and a new auto-encoding of
>>>> strings
>>>> by SOAP::Lite that we used to do in-code by ourselves (resulting in
>>>> double-coded messages).
>>>>
>>>> Anyway, it's done now. Please scream loudly if it doesn't work for
>>>> you!!
>>>> I have backups of everything so if necessary we can roll-back quickly.
>>>>
>>>> All of this was done primarily to get us to be compatible with the new
>>>> Asynchronous services API that use the Manchester WSRF::Lite modules
>>>> which
>>>> depend on SOAP::Lite 0.69. Can I ask the good folks at INB to test the
>>>> code to see if it works for them v.v. Async services? The database can
>>>> now hold Category=moby-async (which reminds me, I need to update the
>>>> database templates in the CVS...), and Eddie assures me that the code
>>>> will
>>>> now provide correct WSDL for an Asych interface. The myGrid folks have
>>>> added moby-async as a valid service category into their ontology as
>>>> well,
>>>> so in principle... it should all work... (touch wood!)
>>>>
>>>> *********************
>>>> IMPORTANTLY this means that the new MOBY Central code will likely NOT
>>>> work
>>>> on versions of SOAP::Lite prior to 0.69!!! Keep this in mind if you
>>>> are
>>>> running your own registry...
>>>> *********************
>>>>
>>>> Tomorrow (if I have regained my sanity after todays hell ;-) ) I'll
>>>> try to
>>>> make the changes to gbrowse_moby such that it can also invoke
>>>> asynchronous
>>>> services. I think the Async modules also need to be added to the
>>>> MANIFEST
>>>> before they are installed by default, so I'll try to remember to do
>>>> that
>>>> as well.
>>>>
>>>> Otherwise there were just some small changes to the test suite to
>>>> better
>>>> clean-up the registry if something goes wrong during testing, and I
>>>> cleaned-up the test database so that it also doesn't cause the test
>>>> suite
>>>> to fail. I will restart the test registry using the new codebase first
>>>> thing in the morning so that the two are identical.
>>>>
>>>> We still haven't figured out why those namespace changes happened a
>>>> couple
>>>> of days ago. It coincided with the Gene Ontology curators making some
>>>> additions to the Namespace list, so I suspect that there is a bug in
>>>> the
>>>> interface I have given to them (which talks directly to the database
>>>> without using the MOBY API), but exactly WHY this happened is still a
>>>> mystery. I've alerted Midori to the problem and she's going to
>>>> hold-off
>>>> on making any more changes until we can figure out what is going wrong.
>>>>
>>>> That's all the news from MOBY Central!
>>>>
>>>> Let us know ASAP if you notice anything wrong. It's been a rough ride
>>>> today...
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>
>
>
>
More information about the MOBY-dev
mailing list