From senger at ebi.ac.uk Tue Aug 1 11:18:02 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 1 Aug 2006 16:18:02 +0100 (BST) Subject: [MOBY-dev] Announcement: Perl Moses released Message-ID: Dear Moby developers, especially if you are funs of $%@_ characters in your code. Talking about Perl, of course. Eddie and me, we created a project "Perl Moses" that does the same things for Perl developers as the MoSeS does for Java. Which means that it uses information stored in BioMoby registry (actually in the local cache) to generate Perl code that helps to implement BioMoby services (in Perl). Again the motto is: "Concentrate on the business logic and let Moses takes care about the XML and other horrible stuff." The code is released as an alpha version (numbered 0.8). As far as we know, it is working, but we desperately need your feedback. We will be fixing bugs as you find them. (Perhaps with some delay because in the next hour, I am heading to an airport flying to South America - not only for BOSC/ISMB but almost for two months. But the South America has an Internet connection, hasn't it? :-)) The best way is probably to browse its (almost finished) documentation at: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/PerlMoses.html. This is also the right place to thank Richard Bruskiewich and the whole Generation Challenge Programme and IRRI for supporting this project. Moses would not exist without GCP (wow, it sounds strange :-)). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Tue Aug 1 11:18:17 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 1 Aug 2006 17:18:17 +0200 Subject: [MOBY-dev] Moby services in Python Message-ID: Hi all, I was wondering if anybody is using Python to create Moby services. I am planning to make use of SOAPpy but I want to know if there is any limitation with this library that can make it not work with BioMOBY. Finally, is this the correct place to ask these kind of questions? Is there any other? Thanks. Javier. From gordonp at ucalgary.ca Tue Aug 1 11:54:44 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 01 Aug 2006 09:54:44 -0600 Subject: [MOBY-dev] Moby services in Python In-Reply-To: References: Message-ID: <44CF7944.3030606@ucalgary.ca> There is a Python tree within the MOBY CVS, but I believe the developers of the initial implementation are no longer actively working on it. It'd be a starting point for you though. I don't see offhand why there should be any technical limitation on interoperability... > Hi all, > > I was wondering if anybody is using Python to create Moby services. I > am planning to make use of SOAPpy but I want to know if there is any > limitation with this library that can make it not work with BioMOBY. > > Finally, is this the correct place to ask these kind of questions? Is > there any other? > > Thanks. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Tue Aug 1 12:39:25 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 01 Aug 2006 10:39:25 -0600 Subject: [MOBY-dev] Java Web Services: part 2 Message-ID: <44CF83BD.90103@ucalgary.ca> Hi all, I have just committed some new code for creating MOBY Java servlets. It's intended for Extremely Lazy Programmers (such as myself), requiring that you download just a particular WAR. No CVS, Axis, Ant, etc. required. Some of my coworkers who have never deployed an servlet, or knew anything about MOBY were able to have a registered, tested service within 30 minutes! Hopefully this will be of use to some of you too... http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html Regards, Paul From markw at illuminae.com Tue Aug 1 17:05:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 01 Aug 2006 14:05:02 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: Message-ID: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-08-01 at 17:18 +0200, Javier de la Torre wrote: > Finally, is this the correct place to ask these kind of questions? Is > there any other? Yes, this is the place to ask those kinds of questions :-) If you do use the Python files,could you please send a message to this list indicating the current state of those files. I don't think anyone really knows if they are functional or not...?? thanks! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From edward.kawas at gmail.com Tue Aug 1 18:20:28 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 1 Aug 2006 15:20:28 -0700 Subject: [MOBY-dev] RDF Agent Message-ID: <009701c6b5b8$b285f050$6700a8c0@notebook> Dear Service Providers, It brings us great pleasure to finally announce that the RDF agent will be placed on a cron job so that it can visit any and all of your registered services on mobycentral. For the next 2 months, the agent will be checking for invalid/dead services and only *reporting* them to the provider. No service will be removed by the agent at this time. However, changes in the service description that the agent encounters when comparing what it knows versus what you have in your document will be reflected in the registry. After the 2 month period, we will either enable the removal of 'dead' services or prolong the reporting of the dead services. Our decision will be based on your concerns and feedback and will be reported to this list. Our hopes are that service providers will use this time to generate RDF for their services and update the registration details for their services [http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSignatureForm]. Once your RDF has been generated, you can verify that the signatureURL has been set properly by looking for the URL in the RDF document. If you cannot find it, please contact us with the servicename/authority and we will look into the reasons why the URL failed to update. Please make sure to place the RDF document at the exact address that you specified when using the form. In addition to updating your services, please take the added step of testing the generated RDF [http://mobycentral.icapture.ubc.ca:8090/servlets/RDFAgent_test.html]. While testing, the agent will tell you whether your services are syntactically correct, and whether the agent can in fact read the remote RDF document. If the document can be read and services are found, the agent will describe your services. If you encounter any problems while generating the RDF, updating your services, or testing the agent, please post your concerns to the list so that we can solve your problems and that others can benefit from the solutions found. Thanks, Eddie From markw at illuminae.com Tue Aug 1 21:25:55 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 2 Aug 2006 01:25:55 +0000 GMT Subject: [MOBY-dev] Remora Message-ID: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> Hi Remora developers! I have a quick question for you - before I say this in my manuscript can you confirm that you are using SCUFL "under the hood" in Remora? I'm guessing, but I don't know... The next iteration of gbrowse-moby (available tomorrow!) generates a SCUFL document while you browse, and I want to say that this document can then be loaded to Taverna AND Remora... But I'm not certain of that. Are any of the other clients using XSCUFL? Cheers! M -- Mark Wilkinson ...on the road! From jatorre at gmail.com Wed Aug 2 06:00:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 12:00:07 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, Good to hear from you. I have downloaded and I am testing it, I dont know if I will finally make use of it. I am working on providing moby support to PyWrapper (the first TAPIR implementation, remember?). The final goal is to make easy for data providers in the GCP context (and GBIF) to make their data available as a retrieval service for moby users. I have another question. If I remember correctly it was not possible to describe moby data types with XML Schema so I suspect it is not possible to generate WSDL files for most of the services. But I see that in the Python library that there is a retrieveServiceWSDL method. What kinf of WSDL can you generate if the inputs are not fixed? You generate your WSDL for what you expect and then you dont validate the input requests and try to process them? Finally, is there a registry, or part of it, where I can play registering data types? It is easy to register things but difficult to delete them and I do not want to leave my testing in the real registry. Thanks in advance. Javier. On 8/1/06, Mark Wilkinson wrote: > On Tue, 2006-08-01 at 17:18 +0200, Javier de la Torre wrote: > > > Finally, is this the correct place to ask these kind of questions? Is > > there any other? > > Yes, this is the place to ask those kinds of questions :-) > > If you do use the Python files,could you please send a message to this > list indicating the current state of those files. I don't think anyone > really knows if they are functional or not...?? > > thanks! > > Mark > > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From raulfdez at lcc.uma.es Wed Aug 2 06:40:47 2006 From: raulfdez at lcc.uma.es (=?iso-8859-1?Q?Ra=FAl_Fern=E1ndez-Santa_Cruz?=) Date: Wed, 2 Aug 2006 12:40:47 +0200 Subject: [MOBY-dev] Remora In-Reply-To: <00bf01c6b618$08e3b950$346dd696@ac.uma.es> Message-ID: <000001c6b620$1d9d88f0$0bd6d696@hyperion> Hello Mark, In INB we use Taverna to execute the SCUFL workflows. In next versions, we want to be able to execute workflows without Taverna, but using the workflows creates by Taverna. For this reason, we will have to be able to parser SCUFL. Regards, Ra?l. ----- Original Message ----- From: "mark wilkinson" To: Sent: Wednesday, August 02, 2006 3:25 AM Subject: [MOBY-dev] Remora > Hi Remora developers! > > I have a quick question for you - before I say this in my manuscript can you confirm that you are using SCUFL "under the hood" in Remora? I'm guessing, but I don't know... > > The next iteration of gbrowse-moby (available tomorrow!) generates a SCUFL document while you browse, and I want to say that this document can then be loaded to Taverna AND Remora... But I'm not certain of that. > > Are any of the other clients using XSCUFL? > > Cheers! > > M > > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Wed Aug 2 10:38:19 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 08:38:19 -0600 Subject: [MOBY-dev] Remora In-Reply-To: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> Message-ID: <44D0B8DB.4030203@ucalgary.ca> Hi Mark, Seahawk (http://moby.ucalgary.ca/seahawk/) can export SCUFL "macros" of your browsing history, using the save icon on the toolbar. It's a little flaky when you get exceptions from services though. > Are any of the other clients using XSCUFL? > > Cheers! > > M > > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Wed Aug 2 11:09:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:09:53 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0B8DB.4030203@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> Message-ID: <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > Hi Mark, > > Seahawk (http://moby.ucalgary.ca/seahawk/) I think you should have called it "Kingfisher", to accommodate both the MOBY "fishy" theme and the Sun COE "birdie" theme :-) M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Aug 2 11:10:19 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:10:19 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0B8DB.4030203@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> Message-ID: <1154531419.25149.15.camel@bioinfo.icapture.ubc.ca> Or "Pelican"... On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > Hi Mark, > > Seahawk (http://moby.ucalgary.ca/seahawk/) can export SCUFL "macros" of > your browsing history, using the save icon on the toolbar. It's a > little flaky when you get exceptions from services though. > > Are any of the other clients using XSCUFL? > > > > Cheers! > > > > M > > > > > > -- > > Mark Wilkinson > > ...on the road! > > _______________________________________________ > > 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 -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Aug 2 11:19:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:19:32 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> Message-ID: <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-08-02 at 12:00 +0200, Javier de la Torre wrote: > I have another question. If I remember correctly it was not possible > to describe moby data types with XML Schema so I suspect it is not > possible to generate WSDL files for most of the services. But I see > that in the Python library that there is a retrieveServiceWSDL method. > What kinf of WSDL can you generate if the inputs are not fixed? The WSDL contains rudimentary XML-Schema fragments in the input and output: so basically all it is saying is that the input and output are going to be blocks of XML. The structure of that XML is opaque to the SOAP libraries, but "visible" to the MOBY libraries that can do ontology- lookups. Unfortunately, there is no pyMoSeS - the MoSeS and Perl MoSeS libraries written by Martin Senger and Eddie Kawas create Java/Perl objects that can create/interpret the XML blocks of MOBY Objects. > Finally, is there a registry, or part of it, where I can play > registering data types? I believe there is a test registry for public "play" at: http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl URI: http://bioinfo.icapture.ubc.ca/MOBY/Central We're in the process of moving that machine physically inside of our institutional firewall (and it isn't going well!) so the that server may be up/down at various times over the next week or so until we figure out why we can't "see" it once it is inside. Let me know if you have problems with it. > It is easy to register things but difficult to > delete them and I do not want to leave my testing in the real > registry. Thanks for being considerate :-) :-) Best wishes! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 2 11:51:10 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 09:51:10 -0600 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D0C9EE.60005@ucalgary.ca> I'm way ahead of you, at the bottom of the Seahawk help page is an extended passage from Moby Dick with an episode about a sea-hawk. :-) > On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > >> Hi Mark, >> >> Seahawk (http://moby.ucalgary.ca/seahawk/) >> > > > I think you should have called it "Kingfisher", to accommodate both the > MOBY "fishy" theme and the Sun COE "birdie" theme :-) > > M > > > From markw at illuminae.com Wed Aug 2 11:52:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:52:48 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0C9EE.60005@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> <44D0C9EE.60005@ucalgary.ca> Message-ID: <1154533968.25301.15.camel@bioinfo.icapture.ubc.ca> Doh! :-) M On Wed, 2006-08-02 at 09:51 -0600, Paul Gordon wrote: > I'm way ahead of you, at the bottom of the Seahawk help page is an > extended passage from Moby Dick with an episode about a sea-hawk. :-) > > On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > > > >> Hi Mark, > >> > >> Seahawk (http://moby.ucalgary.ca/seahawk/) > >> > > > > > > I think you should have called it "Kingfisher", to accommodate both the > > MOBY "fishy" theme and the Sun COE "birdie" theme :-) > > > > M > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Wed Aug 2 12:23:11 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 18:23:11 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi, > The WSDL contains rudimentary XML-Schema fragments in the input and > output: Ok, then is not ok for me, pity. > I believe there is a test registry for public "play" at: > > http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl Great! I will work there. Another question. Is it mandatory for a service to implement the multiple invocations funcionality? Thanks. Javier. From markw at illuminae.com Wed Aug 2 13:22:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 10:22:35 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> Message-ID: <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> > Is it mandatory for a service to implement the multiple invocations > funcionality? well.... It *may* be that the people working on the error-handling and error-codes have reserved an error code for providers who do not WANT to handle multiple invocations in a single message, but I don't think so... I think it is mandatory at the moment. M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 2 14:13:02 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 12:13:02 -0600 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D0EB2E.7010406@ucalgary.ca> I have always been a champion of the multiple invocations requirement, and still am, for several reasons: 0. First we must acknowledge that people will want to run a bunch of data against a service. I do already, and many Taverna workflows do to (implicit iterators). 1. Some services may use hardware accelerator, which can perform 100 jobs as quick as 1 if they are submitted together. 2. If you have a cluster running the service, it is much easier to schedule 100 jobs efficiently than to receive 100 individual requests over the course of a few seconds. i.e. division of labour is much easier when you know in advance how much there is to do! 3. If your server is running 1 CPU, you can decide to run the 100 jobs sequentially, at the pace you like (especially if you have many requests coming in from different users at the same time). If the 100 jobs are submitted separately, it is the client (e.g. Taverna) that decides how much breathing room you have. Encouraging multiple-invocations-in-one-envelope may reduce inadvertent denial-of-service attacks. 4. The network and computational overhead is much smaller for 1 large request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet invocation vs. 100, etc. 5. It's not hard to implement! All you really need to do is add a for loop to the service code... MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html) supports multiple invocations implicitly, I don't even really tell the developer about it: their processRequest() method gets called for each mobyData block. My CAD 0.02, Paul >> Is it mandatory for a service to implement the multiple invocations >> funcionality? >> > > > well.... It *may* be that the people working on the error-handling and > error-codes have reserved an error code for providers who do not WANT to > handle multiple invocations in a single message, but I don't think so... > > I think it is mandatory at the moment. > > M > > > > From jatorre at gmail.com Wed Aug 2 15:36:06 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 21:36:06 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <44D0EB2E.7010406@ucalgary.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> <44D0EB2E.7010406@ucalgary.ca> Message-ID: No, ok, fine... Is just that the software I am working on handle this thing in a different way... Our software is a retrieval service, it is actually a database wrapper. With the protocol it works if you want to retrieve several "objects", records, you do it by defining a query. Still I think it will be ok to transform this. But I am gonna have to implement some limitations on the number of invocations. If a user send my service 10.000 records I will not handle all of them because my service can easily die. In theory if all the requested objects are of the same type, what they must be because is one single service, I can transform it into a single SQL statement to retrieve all of them at once. If I have to lunch a different database query per object then I will be into troubles... Best regards, Javier. On 8/2/06, Paul Gordon wrote: > I have always been a champion of the multiple invocations requirement, > and still am, for several reasons: > > 0. First we must acknowledge that people will want to run a bunch of > data against a service. I do already, and many Taverna workflows do to > (implicit iterators). > > 1. Some services may use hardware accelerator, which can perform 100 > jobs as quick as 1 if they are submitted together. > > 2. If you have a cluster running the service, it is much easier to > schedule 100 jobs efficiently than to receive 100 individual requests > over the course of a few seconds. i.e. division of labour is much > easier when you know in advance how much there is to do! > > 3. If your server is running 1 CPU, you can decide to run the 100 jobs > sequentially, at the pace you like (especially if you have many requests > coming in from different users at the same time). If the 100 jobs are > submitted separately, it is the client (e.g. Taverna) that decides how > much breathing room you have. Encouraging > multiple-invocations-in-one-envelope may reduce inadvertent > denial-of-service attacks. > > 4. The network and computational overhead is much smaller for 1 large > request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet > invocation vs. 100, etc. > > 5. It's not hard to implement! All you really need to do is add a for > loop to the service code... MobyServlet > (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html) > supports multiple invocations implicitly, I don't even really tell the > developer about it: their processRequest() method gets called for each > mobyData block. > > My CAD 0.02, > > Paul > >> Is it mandatory for a service to implement the multiple invocations > >> funcionality? > >> > > > > > > well.... It *may* be that the people working on the error-handling and > > error-codes have reserved an error code for providers who do not WANT to > > handle multiple invocations in a single message, but I don't think so... > > > > I think it is mandatory at the moment. > > > > M > > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From jatorre at gmail.com Wed Aug 2 13:48:05 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 19:48:05 +0200 Subject: [MOBY-dev] License of Python libraries in the MOBY CVS Message-ID: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Hi, I am definitely going to use bioMoby-python. The part for interacting with moby-central works fine with me and I do not want to rewrite it myself. But, I would like to embed it into my software for distribution. I haven't seen a license together with the software, any idea on how is this software licensed? Would be ok to redistributed? With proper credits of course! Thanks. Javier. From markw at illuminae.com Wed Aug 2 16:05:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 13:05:22 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> <44D0EB2E.7010406@ucalgary.ca> Message-ID: On Wed, 02 Aug 2006 12:36:06 -0700, Javier de la Torre wrote: > In theory if all the requested objects are of the same type, what they > must be because is one single service, I can transform it into a > single SQL statement to retrieve all of them at once. This is pretty much what Paul was saying - the optimization of answerig the request can be controlled by the service provider if all requests come in a single message. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From markw at illuminae.com Wed Aug 2 17:45:14 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 14:45:14 -0700 Subject: [MOBY-dev] MOBY License In-Reply-To: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> References: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Message-ID: I have only added a license to "my own" branch of the codebase - the Perl folder. The Perl code is released under the Perl Artistic License. I suspect that you wont get any objection from any of the other developers if you want to redistribute, but it would probably be a good idea to come to a unanimous decision on the license for the entire CVS. Do any developers object to applying the PAL to *all* parts of the MOBY CVS? M On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre wrote: > Hi, > > I am definitely going to use bioMoby-python. The part for interacting > with moby-central works fine with me and I do not want to rewrite it > myself. > > But, I would like to embed it into my software for distribution. I > haven't seen a license together with the software, any idea on how is > this software licensed? > Would be ok to redistributed? With proper credits of course! > > Thanks. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From gordonp at ucalgary.ca Thu Aug 3 09:29:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 07:29:43 -0600 Subject: [MOBY-dev] MOBY License In-Reply-To: References: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Message-ID: <44D1FA47.9020009@ucalgary.ca> I think the Perl Artistic License is a fine one. I had actually assumed that it applied to the whole CVS already :-) > I have only added a license to "my own" branch of the codebase - the Perl > folder. The Perl code is released under the Perl Artistic License. > > I suspect that you wont get any objection from any of the other developers > if you want to redistribute, but it would probably be a good idea to come > to a unanimous decision on the license for the entire CVS. > > Do any developers object to applying the PAL to *all* parts of the MOBY > CVS? > > M > > > > > > On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre > wrote: > > >> Hi, >> >> I am definitely going to use bioMoby-python. The part for interacting >> with moby-central works fine with me and I do not want to rewrite it >> myself. >> >> But, I would like to embed it into my software for distribution. I >> haven't seen a license together with the software, any idea on how is >> this software licensed? >> Would be ok to redistributed? With proper credits of course! >> >> Thanks. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > > From Sebastien.Carrere at toulouse.inra.fr Thu Aug 3 12:12:24 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 03 Aug 2006 18:12:24 +0200 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <002701c6b685$137ecae0$756fa8c0@notebook> References: <002701c6b685$137ecae0$756fa8c0@notebook> Message-ID: <44D22068.1010802@toulouse.inra.fr> Hi Mark and Eddie, I flip this discussion onto the mailing list :-[ The lack of XSCUFL specifications is a real problem for us. The only one I have been able to find is a 2 years old one (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) Nevertheless, I can start to develop a Remora/XSCUFL adapter at this time, using the template sent by Eddie to deal with secondaryArticles. By this way, we could provide Remora user the possibility to download/upload their workflow in "current" XSCUFL format. Cordialement, Sebastien Ed Kawas a ?crit : > Hi, > > I represent secondarys like the following: > parameterValue > > Where 'parameterName' is the articlename for the secondary parameter and the > 'parameterValue' is the value. > > For example: > > some description > > > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > getUniprotIdentifierByGeneName > bioinfo.icapture.ubc.ca > human > > > > > This is how it is done in Taverna. > > Eddie > >> -----Original Message----- >> From: Mark Wilkinson [mailto:markw at illuminae.com] >> Sent: Wednesday, August 02, 2006 3:36 PM >> To: Sebastien Carrere >> Cc: GOUZY J?rome; Eddie Kawas >> Subject: Re: [moby] Re: [MOBY-dev] Remora >> >> Hi Sebastien, >> >> I've spoken with Eddie and he is able to represent >> SecondaryArticles in SCUFL, at least for Taverna. By the >> sounds of it, SCUFL is relatively undefined (I can't find any >> documentation for the language anywhere) and in Taverna >> apparently you are allowed to specify your own SCUFL tags, >> and declare how they should be parsed, so it's more or less >> wide-open to be extended. >> >> So... we represent Secondary parameters in SCUFL, and they >> can be interpreted by Taverna; however since there is no >> definition of the SCUFL language anywhere that we can find, >> we are certain that (at the >> moment) only Taverna can handle these new secondary parameter >> tags. My feeling is that, from the perspective of Taverna, >> all inputs are identical, so they haven't created different >> port types for secondaries vs. primaries as we require for MOBY. >> >> Eddie will tell you more - I have c.c.'d him this message. >> >> It's probably a good idea to flip this conversation onto the >> mailing list, but I don't want to send your message to the >> list without your permission :-) If you want to c.c. the >> list with your response that would be great! >> >> Cheers! >> >> Mark >> >> >> >> >> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >> >>> Bonjour Mark, >>> >>> Remora is not yet SCUFLized. >>> When we started our project, the problem with SCUFL is that >>> >> it did not >> >>> deal with SecondaryArticles ... >>> For us it was a critic. >>> >>> So, my question is : " is SCUFL deals with >>> >> moby:SecondaryArticles now ?". >> >>> If th answer is yes, I can write a parser SCUFL <-> >>> RemoraWorkflowsDescription. >>> If no, maybe I can also write it but with loss of information ... >>> >>> Sincerely, >>> >>> Sebastien. >>> >>> mark wilkinson a ?crit : >>> >>>> Hi Remora developers! >>>> >>>> I have a quick question for you - before I say this in my >>>> >> manuscript can you confirm that you are using SCUFL "under >> the hood" in Remora? I'm guessing, but I don't know... >> >>>> The next iteration of gbrowse-moby (available tomorrow!) >>>> >> generates a SCUFL document while you browse, and I want to >> say that this document can then be loaded to Taverna AND >> Remora... But I'm not certain of that. >> >>>> Are any of the other clients using XSCUFL? >>>> >>>> Cheers! >>>> >>>> M >>>> >>>> >>>> -- >>>> Mark Wilkinson >>>> ...on the road! >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics University of >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >> Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of >> a term to >> someone who is unfamiliar with its proper application, the >> use of language that doesn't help such a person learn how to >> apply the term is pointless. Thus, "happiness is a warm >> puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Thu Aug 3 12:28:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Aug 2006 09:28:58 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D22068.1010802@toulouse.inra.fr> References: <002701c6b685$137ecae0$756fa8c0@notebook> <44D22068.1010802@toulouse.inra.fr> Message-ID: <1154622538.15856.0.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: > http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) wow! I searched for ages and couldn't find that! Well... it's a start :-) M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Thu Aug 3 12:31:44 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Aug 2006 09:31:44 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D22068.1010802@toulouse.inra.fr> References: <002701c6b685$137ecae0$756fa8c0@notebook> <44D22068.1010802@toulouse.inra.fr> Message-ID: <1154622704.15856.2.camel@bioinfo.icapture.ubc.ca> "The language itself should be considered volatile, any users of it should join the taverna developers list and monitor it, we do not support this language for use outside of Taverna." LOL! Well, Tom, when you build something this useful, you can't expect people not to use it! M On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: > Hi Mark and Eddie, > > I flip this discussion onto the mailing list :-[ > > The lack of XSCUFL specifications is a real problem for us. > The only one I have been able to find is a 2 years old one > (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > Nevertheless, I can start to develop a Remora/XSCUFL adapter at this > time, using the template sent by Eddie to deal with secondaryArticles. > > By this way, we could provide Remora user the possibility to > download/upload their workflow in "current" XSCUFL format. > > Cordialement, > > Sebastien > > Ed Kawas a ?crit : > > Hi, > > > > I represent secondarys like the following: > > parameterValue > > > > Where 'parameterName' is the articlename for the secondary parameter and the > > 'parameterValue' is the value. > > > > For example: > > > > some description > > > > > > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > > > getUniprotIdentifierByGeneName > > bioinfo.icapture.ubc.ca > > human > > > > > > > > > > This is how it is done in Taverna. > > > > Eddie > > > >> -----Original Message----- > >> From: Mark Wilkinson [mailto:markw at illuminae.com] > >> Sent: Wednesday, August 02, 2006 3:36 PM > >> To: Sebastien Carrere > >> Cc: GOUZY J?rome; Eddie Kawas > >> Subject: Re: [moby] Re: [MOBY-dev] Remora > >> > >> Hi Sebastien, > >> > >> I've spoken with Eddie and he is able to represent > >> SecondaryArticles in SCUFL, at least for Taverna. By the > >> sounds of it, SCUFL is relatively undefined (I can't find any > >> documentation for the language anywhere) and in Taverna > >> apparently you are allowed to specify your own SCUFL tags, > >> and declare how they should be parsed, so it's more or less > >> wide-open to be extended. > >> > >> So... we represent Secondary parameters in SCUFL, and they > >> can be interpreted by Taverna; however since there is no > >> definition of the SCUFL language anywhere that we can find, > >> we are certain that (at the > >> moment) only Taverna can handle these new secondary parameter > >> tags. My feeling is that, from the perspective of Taverna, > >> all inputs are identical, so they haven't created different > >> port types for secondaries vs. primaries as we require for MOBY. > >> > >> Eddie will tell you more - I have c.c.'d him this message. > >> > >> It's probably a good idea to flip this conversation onto the > >> mailing list, but I don't want to send your message to the > >> list without your permission :-) If you want to c.c. the > >> list with your response that would be great! > >> > >> Cheers! > >> > >> Mark > >> > >> > >> > >> > >> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: > >> > >>> Bonjour Mark, > >>> > >>> Remora is not yet SCUFLized. > >>> When we started our project, the problem with SCUFL is that > >>> > >> it did not > >> > >>> deal with SecondaryArticles ... > >>> For us it was a critic. > >>> > >>> So, my question is : " is SCUFL deals with > >>> > >> moby:SecondaryArticles now ?". > >> > >>> If th answer is yes, I can write a parser SCUFL <-> > >>> RemoraWorkflowsDescription. > >>> If no, maybe I can also write it but with loss of information ... > >>> > >>> Sincerely, > >>> > >>> Sebastien. > >>> > >>> mark wilkinson a ?crit : > >>> > >>>> Hi Remora developers! > >>>> > >>>> I have a quick question for you - before I say this in my > >>>> > >> manuscript can you confirm that you are using SCUFL "under > >> the hood" in Remora? I'm guessing, but I don't know... > >> > >>>> The next iteration of gbrowse-moby (available tomorrow!) > >>>> > >> generates a SCUFL document while you browse, and I want to > >> say that this document can then be loaded to Taverna AND > >> Remora... But I'm not certain of that. > >> > >>>> Are any of the other clients using XSCUFL? > >>>> > >>>> Cheers! > >>>> > >>>> M > >>>> > >>>> > >>>> -- > >>>> Mark Wilkinson > >>>> ...on the road! > >>>> _______________________________________________ > >>>> MOBY-dev mailing list > >>>> MOBY-dev at lists.open-bio.org > >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >>>> > >>>> > >>>> > >> -- > >> Mark Wilkinson > >> Asst. Professor, Dept. of Medical Genetics University of > >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. > >> Paul's Hospital, Rm. 166, 1081 Burrard St. > >> Vancouver, BC, V6Z 1Y6 > >> tel: 604 682 2344 x62129 > >> fax: 604 806 9274 > >> > >> "Since the point of a definition is to explain the meaning of > >> a term to > >> someone who is unfamiliar with its proper application, the > >> use of language that doesn't help such a person learn how to > >> apply the term is pointless. Thus, "happiness is a warm > >> puppy" may be a lovely thought, > >> but it is a lousy definition." > >> > >> K?hler et al, 2006 > >> > >> > > > > > > > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Thu Aug 3 12:32:00 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 3 Aug 2006 13:32:00 -0300 Subject: [MOBY-dev] RDF Agent In-Reply-To: <009701c6b5b8$b285f050$6700a8c0@notebook> References: <009701c6b5b8$b285f050$6700a8c0@notebook> Message-ID: <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> I see there may be a small inconvenience. It may be solved using seveal scenarios, but I am not sure which way to go. The inconvenience I am talking about is for the Moses users/developers. In order to create a service implementation, the service must be registered. But when somebody registers a service, it does not exist yet, so its endpoint is a fake endpoint. And there will be always a time delay between registering the service and making it runnable. How would you suggest to solve this (if we want to solve it all, of course). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Thu Aug 3 14:30:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 12:30:43 -0600 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> Message-ID: <44D240D3.30408@ucalgary.ca> Perhaps to solve the issue, we should know why it needs to be registered before it's implemented? Martin Senger wrote: > I see there may be a small inconvenience. It may be solved using seveal > scenarios, but I am not sure which way to go. > > The inconvenience I am talking about is for the Moses users/developers. In > order to create a service implementation, the service must be registered. > But when somebody registers a service, it does not exist yet, so its > endpoint is a fake endpoint. And there will be always a time delay between > registering the service and making it runnable. > > How would you suggest to solve this (if we want to solve it all, of course). > > Martin > > From yan.wong at free.fr Thu Aug 3 14:14:05 2006 From: yan.wong at free.fr (Yan Wong) Date: Thu, 3 Aug 2006 20:14:05 +0200 Subject: [MOBY-dev] MOBY-dev Digest, Vol 44, Issue 3 In-Reply-To: References: Message-ID: <359AA0B6-BD85-4862-A859-B71CA1013EE8@free.fr> Hello everybody, I reply to the question about the licence of the bioMoby Python code: I didn't put any licence like GPL, LGPL or other BSD licences in it. At the time, I was SO busy with the technical and functionalities of the client interface that I totally forgot the licence... It is a mistake so please apologize. Can someone put the same licence as for the Perl interface? Thus it would clear my mistake. I am pretty busy at Accenture with SAP projects. However, if you still have question on how the Python interface work, I would be happy to answer questions (but don't expect quick answers). I wrote documentation for the code but you'll agree that it need to be rewritten and augmented. Cheers, Yan Wong Le 3 ao?t 06 ? 18:31, moby-dev-request at lists.open-bio.org a ?crit : > Send MOBY-dev mailing list submissions to > moby-dev at lists.open-bio.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.open-bio.org/mailman/listinfo/moby-dev > or, via email, send a message with subject or body 'help' to > moby-dev-request at lists.open-bio.org > > You can reach the person managing the list at > moby-dev-owner at lists.open-bio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MOBY-dev digest..." > > > Today's Topics: > > 1. Re: [moby] Moby services in Python (Javier de la Torre) > 2. License of Python libraries in the MOBY CVS (Javier de la Torre) > 3. Re: [moby] Moby services in Python (Mark Wilkinson) > 4. MOBY License (Mark Wilkinson) > 5. Re: MOBY License (Paul Gordon) > 6. Re: [moby] Re: Remora (Sebastien Carrere) > 7. Re: [moby] Re: Remora (Mark Wilkinson) > 8. Re: [moby] Re: Remora (Mark Wilkinson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Aug 2006 21:36:06 +0200 > From: "Javier de la Torre" > Subject: Re: [MOBY-dev] [moby] Moby services in Python > To: "Core developer announcements" > Cc: markw at illuminae.com > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > No, ok, fine... > > Is just that the software I am working on handle this thing in a > different way... > Our software is a retrieval service, it is actually a database > wrapper. With the protocol it works if you want to retrieve several > "objects", records, you do it by defining a query. > > Still I think it will be ok to transform this. But I am gonna have to > implement some limitations on the number of invocations. If a user > send my service 10.000 records I will not handle all of them because > my service can easily die. > > In theory if all the requested objects are of the same type, what they > must be because is one single service, I can transform it into a > single SQL statement to retrieve all of them at once. If I have to > lunch a different database query per object then I will be into > troubles... > > Best regards, > > Javier. > > > On 8/2/06, Paul Gordon wrote: >> I have always been a champion of the multiple invocations >> requirement, >> and still am, for several reasons: >> >> 0. First we must acknowledge that people will want to run a bunch of >> data against a service. I do already, and many Taverna workflows >> do to >> (implicit iterators). >> >> 1. Some services may use hardware accelerator, which can perform 100 >> jobs as quick as 1 if they are submitted together. >> >> 2. If you have a cluster running the service, it is much easier to >> schedule 100 jobs efficiently than to receive 100 individual requests >> over the course of a few seconds. i.e. division of labour is much >> easier when you know in advance how much there is to do! >> >> 3. If your server is running 1 CPU, you can decide to run the 100 >> jobs >> sequentially, at the pace you like (especially if you have many >> requests >> coming in from different users at the same time). If the 100 jobs >> are >> submitted separately, it is the client (e.g. Taverna) that decides >> how >> much breathing room you have. Encouraging >> multiple-invocations-in-one-envelope may reduce inadvertent >> denial-of-service attacks. >> >> 4. The network and computational overhead is much smaller for 1 large >> request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet >> invocation vs. 100, etc. >> >> 5. It's not hard to implement! All you really need to do is add a >> for >> loop to the service code... MobyServlet >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/ >> deployingServices.html) >> supports multiple invocations implicitly, I don't even really tell >> the >> developer about it: their processRequest() method gets called for >> each >> mobyData block. >> >> My CAD 0.02, >> >> Paul >>>> Is it mandatory for a service to implement the multiple invocations >>>> funcionality? >>>> >>> >>> >>> well.... It *may* be that the people working on the error- >>> handling and >>> error-codes have reserved an error code for providers who do not >>> WANT to >>> handle multiple invocations in a single message, but I don't >>> think so... >>> >>> I think it is mandatory at the moment. >>> >>> M >>> >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Aug 2006 19:48:05 +0200 > From: Javier de la Torre > Subject: [MOBY-dev] License of Python libraries in the MOBY CVS > To: Core developer announcements > Message-ID: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC at gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Hi, > > I am definitely going to use bioMoby-python. The part for interacting > with moby-central works fine with me and I do not want to rewrite it > myself. > > But, I would like to embed it into my software for distribution. I > haven't seen a license together with the software, any idea on how is > this software licensed? > Would be ok to redistributed? With proper credits of course! > > Thanks. > > Javier. > > > ------------------------------ > > Message: 3 > Date: Wed, 02 Aug 2006 13:05:22 -0700 > From: "Mark Wilkinson" > Subject: Re: [MOBY-dev] [moby] Moby services in Python > To: "Core developer announcements" > Message-ID: > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > On Wed, 02 Aug 2006 12:36:06 -0700, Javier de la Torre > > wrote: > > >> In theory if all the requested objects are of the same type, what >> they >> must be because is one single service, I can transform it into a >> single SQL statement to retrieve all of them at once. > > This is pretty much what Paul was saying - the optimization of > answerig > the request can be controlled by the service provider if all > requests come > in a single message. > > M > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > > > ------------------------------ > > Message: 4 > Date: Wed, 02 Aug 2006 14:45:14 -0700 > From: "Mark Wilkinson" > Subject: [MOBY-dev] MOBY License > To: "Core developer announcements" > Message-ID: > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > I have only added a license to "my own" branch of the codebase - > the Perl > folder. The Perl code is released under the Perl Artistic License. > > I suspect that you wont get any objection from any of the other > developers > if you want to redistribute, but it would probably be a good idea > to come > to a unanimous decision on the license for the entire CVS. > > Do any developers object to applying the PAL to *all* parts of the > MOBY > CVS? > > M > > > > > > On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre > > wrote: > >> Hi, >> >> I am definitely going to use bioMoby-python. The part for interacting >> with moby-central works fine with me and I do not want to rewrite it >> myself. >> >> But, I would like to embed it into my software for distribution. I >> haven't seen a license together with the software, any idea on how is >> this software licensed? >> Would be ok to redistributed? With proper credits of course! >> >> Thanks. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > > > ------------------------------ > > Message: 5 > Date: Thu, 03 Aug 2006 07:29:43 -0600 > From: Paul Gordon > Subject: Re: [MOBY-dev] MOBY License > To: Core developer announcements > Message-ID: <44D1FA47.9020009 at ucalgary.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I think the Perl Artistic License is a fine one. I had actually > assumed > that it applied to the whole CVS already :-) >> I have only added a license to "my own" branch of the codebase - >> the Perl >> folder. The Perl code is released under the Perl Artistic License. >> >> I suspect that you wont get any objection from any of the other >> developers >> if you want to redistribute, but it would probably be a good idea >> to come >> to a unanimous decision on the license for the entire CVS. >> >> Do any developers object to applying the PAL to *all* parts of the >> MOBY >> CVS? >> >> M >> >> >> >> >> >> On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre >> >> wrote: >> >> >>> Hi, >>> >>> I am definitely going to use bioMoby-python. The part for >>> interacting >>> with moby-central works fine with me and I do not want to rewrite it >>> myself. >>> >>> But, I would like to embed it into my software for distribution. I >>> haven't seen a license together with the software, any idea on >>> how is >>> this software licensed? >>> Would be ok to redistributed? With proper credits of course! >>> >>> Thanks. >>> >>> Javier. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> >> >> > > > > ------------------------------ > > Message: 6 > Date: Thu, 03 Aug 2006 18:12:24 +0200 > From: Sebastien Carrere > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: moby-dev at lists.open-bio.org > Cc: Ed Kawas , markw at illuminae.com > Message-ID: <44D22068.1010802 at toulouse.inra.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Mark and Eddie, > > I flip this discussion onto the mailing list :-[ > > The lack of XSCUFL specifications is a real problem for us. > The only one I have been able to find is a 2 years old one > (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > Nevertheless, I can start to develop a Remora/XSCUFL adapter at this > time, using the template sent by Eddie to deal with > secondaryArticles. > > By this way, we could provide Remora user the possibility to > download/upload their workflow in "current" XSCUFL format. > > Cordialement, > > Sebastien > > Ed Kawas a ?crit : >> Hi, >> >> I represent secondarys like the following: >> parameterValue >> >> Where 'parameterName' is the articlename for the secondary >> parameter and the >> 'parameterValue' is the value. >> >> For example: >> >> some description >> >> >> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/ >> mobycentral.pl >> >> getUniprotIdentifierByGeneName >> bioinfo.icapture.ubc.ca >> human >> >> >> >> >> This is how it is done in Taverna. >> >> Eddie >> >>> -----Original Message----- >>> From: Mark Wilkinson [mailto:markw at illuminae.com] >>> Sent: Wednesday, August 02, 2006 3:36 PM >>> To: Sebastien Carrere >>> Cc: GOUZY J?rome; Eddie Kawas >>> Subject: Re: [moby] Re: [MOBY-dev] Remora >>> >>> Hi Sebastien, >>> >>> I've spoken with Eddie and he is able to represent >>> SecondaryArticles in SCUFL, at least for Taverna. By the >>> sounds of it, SCUFL is relatively undefined (I can't find any >>> documentation for the language anywhere) and in Taverna >>> apparently you are allowed to specify your own SCUFL tags, >>> and declare how they should be parsed, so it's more or less >>> wide-open to be extended. >>> >>> So... we represent Secondary parameters in SCUFL, and they >>> can be interpreted by Taverna; however since there is no >>> definition of the SCUFL language anywhere that we can find, >>> we are certain that (at the >>> moment) only Taverna can handle these new secondary parameter >>> tags. My feeling is that, from the perspective of Taverna, >>> all inputs are identical, so they haven't created different >>> port types for secondaries vs. primaries as we require for MOBY. >>> >>> Eddie will tell you more - I have c.c.'d him this message. >>> >>> It's probably a good idea to flip this conversation onto the >>> mailing list, but I don't want to send your message to the >>> list without your permission :-) If you want to c.c. the >>> list with your response that would be great! >>> >>> Cheers! >>> >>> Mark >>> >>> >>> >>> >>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >>> >>>> Bonjour Mark, >>>> >>>> Remora is not yet SCUFLized. >>>> When we started our project, the problem with SCUFL is that >>>> >>> it did not >>> >>>> deal with SecondaryArticles ... >>>> For us it was a critic. >>>> >>>> So, my question is : " is SCUFL deals with >>>> >>> moby:SecondaryArticles now ?". >>> >>>> If th answer is yes, I can write a parser SCUFL <-> >>>> RemoraWorkflowsDescription. >>>> If no, maybe I can also write it but with loss of information ... >>>> >>>> Sincerely, >>>> >>>> Sebastien. >>>> >>>> mark wilkinson a ?crit : >>>> >>>>> Hi Remora developers! >>>>> >>>>> I have a quick question for you - before I say this in my >>>>> >>> manuscript can you confirm that you are using SCUFL "under >>> the hood" in Remora? I'm guessing, but I don't know... >>> >>>>> The next iteration of gbrowse-moby (available tomorrow!) >>>>> >>> generates a SCUFL document while you browse, and I want to >>> say that this document can then be loaded to Taverna AND >>> Remora... But I'm not certain of that. >>> >>>>> Are any of the other clients using XSCUFL? >>>>> >>>>> Cheers! >>>>> >>>>> M >>>>> >>>>> >>>>> -- >>>>> Mark Wilkinson >>>>> ...on the road! >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at lists.open-bio.org >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics University of >>> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >>> Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of >>> a term to >>> someone who is unfamiliar with its proper application, the >>> use of language that doesn't help such a person learn how to >>> apply the term is pointless. Thus, "happiness is a warm >>> puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> >> >> >> > > -- > __________________________________________________________ > > Sebastien CARRERE LIPM (INRA-CNRS) > B.P.52627 -- 31326 CASTANET TOLOSAN > tel:(33) 5-61-28-53-29 > fax:(33) 5-61-28-50-61 > > > > > ------------------------------ > > Message: 7 > Date: Thu, 03 Aug 2006 09:28:58 -0700 > From: Mark Wilkinson > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: Core developer announcements > Message-ID: <1154622538.15856.0.camel at bioinfo.icapture.ubc.ca> > Content-Type: text/plain; charset=utf-8 > > On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: >> http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > wow! I searched for ages and couldn't find that! > > Well... it's a start :-) > > M > > > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K? > hler et al, 2006 > > > > ------------------------------ > > Message: 8 > Date: Thu, 03 Aug 2006 09:31:44 -0700 > From: Mark Wilkinson > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: Core developer announcements > Message-ID: <1154622704.15856.2.camel at bioinfo.icapture.ubc.ca> > Content-Type: text/plain; charset=utf-8 > > "The language itself should be considered volatile, any users of it > should join the taverna developers list and monitor it, we do not > support this language for use outside of Taverna." > > LOL! Well, Tom, when you build something this useful, you can't > expect > people not to use it! > > M > > > > > On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: >> Hi Mark and Eddie, >> >> I flip this discussion onto the mailing list :-[ >> >> The lack of XSCUFL specifications is a real problem for us. >> The only one I have been able to find is a 2 years old one >> (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) >> >> Nevertheless, I can start to develop a Remora/XSCUFL adapter at this >> time, using the template sent by Eddie to deal with >> secondaryArticles. >> >> By this way, we could provide Remora user the possibility to >> download/upload their workflow in "current" XSCUFL format. >> >> Cordialement, >> >> Sebastien >> >> Ed Kawas a ?crit : >>> Hi, >>> >>> I represent secondarys like the following: >>> parameterValue >>> >>> Where 'parameterName' is the articlename for the secondary >>> parameter and the >>> 'parameterValue' is the value. >>> >>> For example: >>> >>> some description >>> >>> >>> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/ >>> mobycentral.pl >>> >>> getUniprotIdentifierByGeneName >>> bioinfo.icapture.ubc.ca >>> human >>> >>> >>> >>> >>> This is how it is done in Taverna. >>> >>> Eddie >>> >>>> -----Original Message----- >>>> From: Mark Wilkinson [mailto:markw at illuminae.com] >>>> Sent: Wednesday, August 02, 2006 3:36 PM >>>> To: Sebastien Carrere >>>> Cc: GOUZY J?rome; Eddie Kawas >>>> Subject: Re: [moby] Re: [MOBY-dev] Remora >>>> >>>> Hi Sebastien, >>>> >>>> I've spoken with Eddie and he is able to represent >>>> SecondaryArticles in SCUFL, at least for Taverna. By the >>>> sounds of it, SCUFL is relatively undefined (I can't find any >>>> documentation for the language anywhere) and in Taverna >>>> apparently you are allowed to specify your own SCUFL tags, >>>> and declare how they should be parsed, so it's more or less >>>> wide-open to be extended. >>>> >>>> So... we represent Secondary parameters in SCUFL, and they >>>> can be interpreted by Taverna; however since there is no >>>> definition of the SCUFL language anywhere that we can find, >>>> we are certain that (at the >>>> moment) only Taverna can handle these new secondary parameter >>>> tags. My feeling is that, from the perspective of Taverna, >>>> all inputs are identical, so they haven't created different >>>> port types for secondaries vs. primaries as we require for MOBY. >>>> >>>> Eddie will tell you more - I have c.c.'d him this message. >>>> >>>> It's probably a good idea to flip this conversation onto the >>>> mailing list, but I don't want to send your message to the >>>> list without your permission :-) If you want to c.c. the >>>> list with your response that would be great! >>>> >>>> Cheers! >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >>>> >>>>> Bonjour Mark, >>>>> >>>>> Remora is not yet SCUFLized. >>>>> When we started our project, the problem with SCUFL is that >>>>> >>>> it did not >>>> >>>>> deal with SecondaryArticles ... >>>>> For us it was a critic. >>>>> >>>>> So, my question is : " is SCUFL deals with >>>>> >>>> moby:SecondaryArticles now ?". >>>> >>>>> If th answer is yes, I can write a parser SCUFL <-> >>>>> RemoraWorkflowsDescription. >>>>> If no, maybe I can also write it but with loss of information ... >>>>> >>>>> Sincerely, >>>>> >>>>> Sebastien. >>>>> >>>>> mark wilkinson a ?crit : >>>>> >>>>>> Hi Remora developers! >>>>>> >>>>>> I have a quick question for you - before I say this in my >>>>>> >>>> manuscript can you confirm that you are using SCUFL "under >>>> the hood" in Remora? I'm guessing, but I don't know... >>>> >>>>>> The next iteration of gbrowse-moby (available tomorrow!) >>>>>> >>>> generates a SCUFL document while you browse, and I want to >>>> say that this document can then be loaded to Taverna AND >>>> Remora... But I'm not certain of that. >>>> >>>>>> Are any of the other clients using XSCUFL? >>>>>> >>>>>> Cheers! >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>> -- >>>>>> Mark Wilkinson >>>>>> ...on the road! >>>>>> _______________________________________________ >>>>>> MOBY-dev mailing list >>>>>> MOBY-dev at lists.open-bio.org >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>>>> >>>>>> >>>>>> >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor, Dept. of Medical Genetics University of >>>> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >>>> Paul's Hospital, Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "Since the point of a definition is to explain the meaning of >>>> a term to >>>> someone who is unfamiliar with its proper application, the >>>> use of language that doesn't help such a person learn how to >>>> apply the term is pointless. Thus, "happiness is a warm >>>> puppy" may be a lovely thought, >>>> but it is a lousy definition." >>>> >>>> K?hler et al, 2006 >>>> >>>> >>> >>> >>> >> > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K? > hler et al, 2006 > > > > ------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > End of MOBY-dev Digest, Vol 44, Issue 3 > *************************************** > From gordonp at ucalgary.ca Thu Aug 3 17:03:09 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 15:03:09 -0600 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> <44D240D3.30408@ucalgary.ca> <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> Message-ID: <44D2648D.7030300@ucalgary.ca> Perhaps then you can create that information locally first to avoid the chicken-egg issue? Registering is that last thing I do when I use MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html). In fact, MobyServlet will not let a service be registered unless it passes a live test... My CAD0.02 :-) >> Perhaps to solve the issue, we should know why it needs to be registered >> before it's implemented? >> > > > That' easy: because Moses is using information registered. > Martin > > > From martin.senger at gmail.com Thu Aug 3 14:58:41 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 3 Aug 2006 15:58:41 -0300 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <44D240D3.30408@ucalgary.ca> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> <44D240D3.30408@ucalgary.ca> Message-ID: <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> > Perhaps to solve the issue, we should know why it needs to be registered > before it's implemented? That' easy: because Moses is using information registered. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Aug 4 12:50:59 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Aug 2006 09:50:59 -0700 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community Message-ID: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Issue #1: ------------- Well, along with the rest of you, I got an inbox full of threatening emails from the agent yesterday. Ugh! Sorry about that! So, the first-try of the agent was possibly a bit of a disaster w.r.t. public relations, but we did learn from it, and we're re-coding it now to have a less annoying behaviour! History: The primary purpose of the agent is to enable a distributed and safe way to add/update/remove your services from the registry. At present, services registered without a SignatureURL can be removed by anyone, which is quite a dangerous situation. For this reason, we encourage people to now download their Service Signature RDF from the page that Eddie has set up at http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and save the output to whatever URL you enter in the Signature URL box. This will protect your service from deregistration by third-parties. If you need to deregister your service, simply remove its description from the RDF document, and the agent will remove it from the registry the next time it crawls. [[More about this in Issue #2 below...]] Another behaviour of the agent is its (configurable) ability to "cleanse" the registry of any service that do not have a SignatureURL. The assumption was that "dead" services would likely not have SignatureURLs, and that any service that was intended to be production- quality would have been registered with a SignatureURL so those without could/should be removed. This became a part of the draft policy statement for my instance of MOBY Central (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). I've had complaints about this policy from several of the key MOBY partners, and they have convinced me to loosen this policy to be less "tyrannical", and in the process we have come up with an alternative proposal that I wish to put forward to the community. My concern with the way people use the main public registry has been that people tend to leave their "trash" lying around in there for, in some cases, years! This clutters-up the search results of other people and is generally quite a nuisance. However, if we agree that services with a SignatureURL are "production quality" and that services without a SignatureURL are "test", then it is still possible to filter-out these "test" services at the client-level, while allowing them to persist in the registry for people to use and experiment with until they are ready to re-register them with a SignatureURL. i.e. the new policy proposal is that services without a SignatureURL can remain in the main public registry; however it is up to the client whether or not these services are displayed in the search results. Does this sound more reasonable to everyone? If so, I will update the policy statement, and we can make a note of this "convention" in the API documentation as well. =============== Issue #2: Immediate Deregistration/Updating The MOBY Central code does not allow you to deregister a service with a Signature URL, nor can you update it. This can be very annoying, I know!! It's not sufficient to just wait for the agent to visit during the night... there must be a better way! It is undocumented because we're still experimenting to see if there are any obvious down-sides, but MOBY Central is currently configured to trigger an Agent visit if you call the registerService method with your SignatureURL as the only parameter. This allows you to *immediately* deregister or update a service (based on a local edit of your Signature RDF document) rather than waiting for the next agent crawl. I invite all developers to try this and let us know if this seems like a sensible behaviour. There may be better ways to accomplish this, so if you have other ideas, or if you see any potential security-holes in this approach, please let us know. ============ Cheers all! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Aug 4 13:20:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 04 Aug 2006 11:20:28 -0600 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D381DC.6080405@ucalgary.ca> These both seem like great solutions to me, and exactly what I would have suggested :-) From gordonp at ucalgary.ca Fri Aug 4 13:20:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 04 Aug 2006 11:20:28 -0600 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D381DC.6080405@ucalgary.ca> These both seem like great solutions to me, and exactly what I would have suggested :-) From Pieter.Neerincx at wur.nl Sat Aug 5 11:13:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 12:13:03 -0300 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Dear all, Here is some feedback from the BioMOBY BOF at Fortaleza. Unfortunately Martin and I were the only Mobifiers present, but we had a good discussion and brainstorm session about these recent developments. We feel the RDF Agent is a good tool to protect services from deregistration by third parties. Furthermore if it is possible to call the Agent to pay a visit immediately it will be just as convenient for developers to use the old way of service registration as it is to use the new way with a SignatureURL. Mark wrote: "MOBY Central is currently configured to trigger an Agent visit if you call the registerService method with your SignatureURL as the only parameter. This allows you to *immediately* deregister or update a service". We were wondering though how this works if you have multiple services described in one RDF document. Can I make one call with only a SignatureURL and have all of them checked (updated/ deleted/appended)? We are glad that registering a service with a SignatureURL is optional for now. At least for the near furture, as this functionality is not yet "production ready" and only partially documented. Therefore it is currently quite difficult for people like us who are running additional registries to implement this way of service registration. Personally I'm looking forward to test this once I get back! And I'll try to contribute to the documentation where I can. (Unfortunately, the network at the conference is not very stable and way too slow for any serious networking.) We also feel the need to have some functionality for cleaning registries, but we think the RDF agent is not suitable for this task. Using a SignatureURL prevents third parties from deleting or altering service registrations, but there is no way the RDF agent can figure out whether a service is "up" and whether it is correctly registered. You can put an RDF document online and register a service that even never existed. Furthermore it is possible to make mistakes in the RDF document and list incorrect inputs and/or outputs. So with or without RDF document there is still no way a client can figure out if the information from a registry is up-to-date. Summarising, using SignatureURLs and the RDF Agent makes (de-) registration more secure, but it doesn't solve the issue of pollution of registries due to dead or mis-registered services. Registry pollution seriously hampers service discovery and spoils the fun. The recently discussed BioMOBY "ping" would be a good candidate to check whether a service is up. I think we already agreed that the ping request will be an empty request. Hence, a ping request has no query alias mobyData tag and there is an empty mobyContent tag: There was still some discussion though about what the ping response should look like. We suggest this will be the same as the input with the option to append serviceNotes. In the serviceNotes section we could optionally use exceptionCode 700 to signal everything is Ok, but just as with normal service invocation serviceNotes remain optional. So a minimal ping response would be something like this: With serviceNotes it would look like this: Some human readable information about this service... 700 Service is up The question that remains is who will use the ping? We think both a registry and the clients could take advantage of the ping. The registry could have a Ping Agent in addition to the RDF Agent to check whether services are up. And it would be fine if this Ping Agent removes dead services after a certain amount of unsuccessful attempts. Furthermore to get the most up-to-date information a client could use a ping to check whether services are up. Having an option to hide services which are down would make more sense to us compared to hiding services without a SignatureURL as a SignatureURL doesn't tell us anything about service availability nor about service quality. The SignatureURL only tells you something about registration security, which is probably not very useful for most clients. Would this make everybody happy? Cheers from Fortaleza, Martin and Pieter On 4-Aug-2006, at 1:50 PM, Mark Wilkinson wrote: > Issue #1: > ------------- > Well, along with the rest of you, I got an inbox full of threatening > emails from the agent yesterday. Ugh! Sorry about that! > > So, the first-try of the agent was possibly a bit of a disaster w.r.t. > public relations, but we did learn from it, and we're re-coding it now > to have a less annoying behaviour! > > History: The primary purpose of the agent is to enable a distributed > and safe way to add/update/remove your services from the registry. At > present, services registered without a SignatureURL can be removed by > anyone, which is quite a dangerous situation. For this reason, we > encourage people to now download their Service Signature RDF from the > page that Eddie has set up at > http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and > save the output to whatever URL you enter in the Signature URL box. > This will protect your service from deregistration by third- > parties. If > you need to deregister your service, simply remove its description > from > the RDF document, and the agent will remove it from the registry the > next time it crawls. [[More about this in Issue #2 below...]] > > Another behaviour of the agent is its (configurable) ability to > "cleanse" the registry of any service that do not have a SignatureURL. > The assumption was that "dead" services would likely not have > SignatureURLs, and that any service that was intended to be > production- > quality would have been registered with a SignatureURL so those > without > could/should be removed. This became a part of the draft policy > statement for my instance of MOBY Central > (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). > > I've had complaints about this policy from several of the key MOBY > partners, and they have convinced me to loosen this policy to be less > "tyrannical", and in the process we have come up with an alternative > proposal that I wish to put forward to the community. > > My concern with the way people use the main public registry has been > that people tend to leave their "trash" lying around in there for, in > some cases, years! This clutters-up the search results of other > people > and is generally quite a nuisance. However, if we agree that services > with a SignatureURL are "production quality" and that services > without a > SignatureURL are "test", then it is still possible to filter-out these > "test" services at the client-level, while allowing them to persist in > the registry for people to use and experiment with until they are > ready > to re-register them with a SignatureURL. > > i.e. the new policy proposal is that services without a > SignatureURL can > remain in the main public registry; however it is up to the client > whether or not these services are displayed in the search results. > > Does this sound more reasonable to everyone? > > If so, I will update the policy statement, and we can make a note of > this "convention" in the API documentation as well. > > =============== > > Issue #2: Immediate Deregistration/Updating > > The MOBY Central code does not allow you to deregister a service > with a > Signature URL, nor can you update it. This can be very annoying, I > know!! It's not sufficient to just wait for the agent to visit during > the night... there must be a better way! > > It is undocumented because we're still experimenting to see if > there are > any obvious down-sides, but MOBY Central is currently configured to > trigger an Agent visit if you call the registerService method with > your > SignatureURL as the only parameter. This allows you to *immediately* > deregister or update a service (based on a local edit of your > Signature > RDF document) rather than waiting for the next agent crawl. > > I invite all developers to try this and let us know if this seems > like a > sensible behaviour. There may be better ways to accomplish this, > so if > you have other ideas, or if you see any potential security-holes in > this > approach, please let us know. > > ============ > > Cheers all! > > Mark > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Sat Aug 5 13:16:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 14:16:37 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 2: BioMOBY meetings In-Reply-To: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Message-ID: <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> Hi All, (To prevent the previous mail from getting too looooong, you'll find a summary of other things we discussed in the next ones...) It's been a while since Mark organised the last meeting specific to BioMOBY in Vancouver. The mailinglist is a useful tool, but meeting "live" once in while is invaluable. Simply because we can work/ discuss/brainstorm much faster when we sit together as compared to sending dozens of e-mails. In addition to brainstorming and discussing we feel such meetings would also be a good place to make decisions about RFCs. When we plan a meeting we have a strict deadline that will pass by less easily without deciding what to implement. (What happened to the asynchronous services proposal??? More about that in the next mail...) In order to make decisions at such a meeting it is essential to prepare the topics well and that all or at least most of the "core developers" will join. The mailinglist would be fine for the foreplay or maybe a teleconference would be nice. So we hereby would like to propose that we try to have a real BioMOBY meeting once a year (again). BioMOBY alone might not be worth the effort to fly all over the world and most of us don't have unlimited budgets for traveling. Therefore we propose to have a meeting the day before or after some other big event. Who would be willing to join and what events would be good candidates? Any suggestions? ECCB perhaps? Cheers, Martin and Pieter From Pieter.Neerincx at wur.nl Sat Aug 5 15:21:32 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 16:21:32 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> Message-ID: <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> Hi all, The last e-mails about the asynchronous services proposal are more than 5 months old, so we were wondering what happened. We know it takes time to create a good proposal and just hope the people at INB in Spain have not given up on reaching consensus. We know there is a demand for asynchronous services. Both Martin and I have already implemented asynchronous services, because we needed something for the time being. If I remember correctly the INB in Spain also already has some asynchronous services and there might be more. Most likely whatever all of us implemented is "compatible" with the current BioMOBY API, but having many different ways to invoke asynchronous services doesn't make life easier for clients. Interoperability is Paramount! So let's get the asynchronous services proposal back on the agenda. Could someone from INB please give us a status update on their proposal? Thanks, Martin & Pieter From johan at ac.uma.es Sun Aug 6 06:38:02 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Sun, 06 Aug 2006 12:38:02 +0200 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> Message-ID: <44D5C68A.2020405@ac.uma.es> Hi! Yes, it is certainly on the agenda. Expect version 2 of the proposal tomorrow (Monday). Kind regards, Johan Karlsson Pieter Neerincx wrote: > Hi all, > > The last e-mails about the asynchronous services proposal are more > than 5 months old, so we were wondering what happened. We know it > takes time to create a good proposal and just hope the people at INB > in Spain have not given up on reaching consensus. We know there is a > demand for asynchronous services. Both Martin and I have already > implemented asynchronous services, because we needed something for > the time being. If I remember correctly the INB in Spain also already > has some asynchronous services and there might be more. Most likely > whatever all of us implemented is "compatible" with the current > BioMOBY API, but having many different ways to invoke asynchronous > services doesn't make life easier for clients. Interoperability is > Paramount! So let's get the asynchronous services proposal back on > the agenda. Could someone from INB please give us a status update on > their proposal? > > Thanks, > > Martin & Pieter > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Mon Aug 7 12:16:12 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 7 Aug 2006 13:16:12 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <44D5C68A.2020405@ac.uma.es> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> <44D5C68A.2020405@ac.uma.es> Message-ID: <4C141307-4323-4490-8A71-F0FBC715784E@wur.nl> That's good news! I'm looking forward to read it... Cheers, Pi On 6-Aug-2006, at 7:38 AM, Johan Karlsson wrote: > Hi! > > Yes, it is certainly on the agenda. Expect version 2 of the proposal > tomorrow (Monday). > > Kind regards, > Johan Karlsson > > Pieter Neerincx wrote: >> Hi all, >> >> The last e-mails about the asynchronous services proposal are more >> than 5 months old, so we were wondering what happened. We know it >> takes time to create a good proposal and just hope the people at INB >> in Spain have not given up on reaching consensus. We know there is a >> demand for asynchronous services. Both Martin and I have already >> implemented asynchronous services, because we needed something for >> the time being. If I remember correctly the INB in Spain also already >> has some asynchronous services and there might be more. Most likely >> whatever all of us implemented is "compatible" with the current >> BioMOBY API, but having many different ways to invoke asynchronous >> services doesn't make life easier for clients. Interoperability is >> Paramount! So let's get the asynchronous services proposal back on >> the agenda. Could someone from INB please give us a status update on >> their proposal? >> >> Thanks, >> >> Martin & Pieter >> _______________________________________________ >> 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 Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From johank at cs.umu.se Mon Aug 7 14:41:23 2006 From: johank at cs.umu.se (Johan Karlsson) Date: Mon, 07 Aug 2006 20:41:23 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 Message-ID: <1154976083.44d78953058fb@webmail.cs.umu.se> Hello, Attached to this email you can find an updated version (2.2) of the INB proposal for asynchronous services. We have added some things that were suggested during the discussions and changed some wordings to make it more clear what is intended. Please see summary in the end of this letter for the main changes. We are very grateful for earlier comments and suggestions and hope for more. If there is something we missed to update from the earlier discussion, please let us know. The great difference from the earlier public version is that we are now using an OASIS standard, the Web Services Resource Framework (WSRF), to communicate status and results. The main reason is that the polling approach that we are advocating requires that the web-service in question maintains some sort of state and WSRF is exactly intended to provide a standardised way to handle this. We realise that WSRF might be a new experience for many BioMOBY-developers and therefore we have developed some functions to simplify implementation of asynchronous services and clients (in Perl) and a prototype to illustrate their use. In fact, to write a basic asynchronous BioMOBY service with the library is not much different compared to how it is done for synchronous services (see HelloWorld.pm). More details about the modules and the prototype here: http://bioinfo.pcm.uam.es/prototype/ There you can also find an example of a WSDL (mentioned in the document but not included as appendix for reasons of readability). The parts relating to WSRF would have to be added to the WSDL that MobyCentral generates today. Let us restart the discussions and reach an agreement soon, asynchronous services/clients are definitely needed. Should we set as a goal to reach a decision on the RFC by the end of August? Suggestions/improvements and comments for both the proposal and the modules are greatly welcomed. Summary of major changes in the document: - WSRF to communicate state information instead of MobyStatus - It is possible to retrieve results or status for specific mobyData inputs ("jobs") - Better descriptions of job and batch-call - More descriptions of the error-cases - Updated information about how to describe async services in RDF (Mark, can you please double-check this, we need a Boolean value for this) - The category field from findService output will have four allowed values 'moby', 'moby-async', 'cgi' and 'soap'. - The SOAP method to start a call is now called servicename_submit (before servicename_async) Apologies for the long delay but there has been some fundamental changes that required some study and implementation. Warm greetings from Malaga, Johan Karlsson, GNV5 -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 -------------- next part -------------- A non-text attachment was scrubbed... Name: BioMOBY Asynchronous Service Call Proposal_v2.2.pdf Type: application/pdf Size: 212922 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060807/750159cd/attachment-0001.pdf From gordonp at ucalgary.ca Tue Aug 8 11:25:38 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 09:25:38 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Message-ID: <44D8ACF2.2000901@ucalgary.ca> Hi all, I think both RDF and ping are necessary: 1. The RDF is a contract of sorts. If you are not committed enough to keep the RDF available for download, your service should be deregistered. It also makes people aware that if they modify their service, they really should be updating the RDF (at least the service instance version number). There definitely needs to be a grace period though, as yousay, while the agent is in testing mode. 2. I think the ping should be mandatory, with a valid input test case. I think this is REALLY important: If we want users to really adopt MOBY, we MUST make it difficult to have dead services show up as service options in clients. There is NO good reason to allow lazy service provision. If our focus is on providers rather than users, to use an English idiom, we are putting the cart before the horse. If a service provider cannot easily provide a sample of valid input, they obviously have not even really tested their service! In MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html), you MUST provide one or more test "mobyData" blocks of the correct input type, and receive answers of the correct data type, THEN it register your service. I could very easily, and very happily, add the test data automatically to the registration data or RDF... Sorry for all of the capitalization, but I show no mercy to broken services! (Including some registered by people in my own lab :-)) The robustness of the individual services is (as Mark's has learned) interpreted as the robustness of the clients and the protocol itself, let's not give people any reason to doubt... Paul > Summarising, using SignatureURLs and the RDF Agent makes (de-) > registration more secure, but it doesn't solve the issue of pollution > of registries due to dead or mis-registered services. > > Registry pollution seriously hampers service discovery and spoils the > fun. The recently discussed BioMOBY "ping" would be a good candidate > to check whether a service is up. I think we already agreed that the > ping request will be an empty request. Hence, a ping request has no > query alias mobyData tag and there is an empty mobyContent tag: > > xmlns='http://www.biomoby.org/moby'> > > > > There was still some discussion though about what the ping response > should look like. We suggest this will be the same as the input with > the option to append serviceNotes. In the serviceNotes section we > could optionally use exceptionCode 700 to signal everything is Ok, > but just as with normal service invocation serviceNotes remain > optional. So a minimal ping response would be something like this: > > xmlns='http://www.biomoby.org/moby'> > > > > With serviceNotes it would look like this: > > xmlns='http://www.biomoby.org/moby'> > > > > Some human readable information about this service... > > > 700 > Service is up > > > > > > The question that remains is who will use the ping? We think both a > registry and the clients could take advantage of the ping. The > registry could have a Ping Agent in addition to the RDF Agent to > check whether services are up. And it would be fine if this Ping > Agent removes dead services after a certain amount of unsuccessful > attempts. Furthermore to get the most up-to-date information a client > could use a ping to check whether services are up. Having an option > to hide services which are down would make more sense to us compared > to hiding services without a SignatureURL as a SignatureURL doesn't > tell us anything about service availability nor about service > quality. The SignatureURL only tells you something about registration > security, which is probably not very useful for most clients. > > Would this make everybody happy? > > Cheers from Fortaleza, > > Martin and Pieter > > > On 4-Aug-2006, at 1:50 PM, Mark Wilkinson wrote: > > >> Issue #1: >> ------------- >> Well, along with the rest of you, I got an inbox full of threatening >> emails from the agent yesterday. Ugh! Sorry about that! >> >> So, the first-try of the agent was possibly a bit of a disaster w.r.t. >> public relations, but we did learn from it, and we're re-coding it now >> to have a less annoying behaviour! >> >> History: The primary purpose of the agent is to enable a distributed >> and safe way to add/update/remove your services from the registry. At >> present, services registered without a SignatureURL can be removed by >> anyone, which is quite a dangerous situation. For this reason, we >> encourage people to now download their Service Signature RDF from the >> page that Eddie has set up at >> http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and >> save the output to whatever URL you enter in the Signature URL box. >> This will protect your service from deregistration by third- >> parties. If >> you need to deregister your service, simply remove its description >> from >> the RDF document, and the agent will remove it from the registry the >> next time it crawls. [[More about this in Issue #2 below...]] >> >> Another behaviour of the agent is its (configurable) ability to >> "cleanse" the registry of any service that do not have a SignatureURL. >> The assumption was that "dead" services would likely not have >> SignatureURLs, and that any service that was intended to be >> production- >> quality would have been registered with a SignatureURL so those >> without >> could/should be removed. This became a part of the draft policy >> statement for my instance of MOBY Central >> (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). >> >> I've had complaints about this policy from several of the key MOBY >> partners, and they have convinced me to loosen this policy to be less >> "tyrannical", and in the process we have come up with an alternative >> proposal that I wish to put forward to the community. >> >> My concern with the way people use the main public registry has been >> that people tend to leave their "trash" lying around in there for, in >> some cases, years! This clutters-up the search results of other >> people >> and is generally quite a nuisance. However, if we agree that services >> with a SignatureURL are "production quality" and that services >> without a >> SignatureURL are "test", then it is still possible to filter-out these >> "test" services at the client-level, while allowing them to persist in >> the registry for people to use and experiment with until they are >> ready >> to re-register them with a SignatureURL. >> >> i.e. the new policy proposal is that services without a >> SignatureURL can >> remain in the main public registry; however it is up to the client >> whether or not these services are displayed in the search results. >> >> Does this sound more reasonable to everyone? >> >> If so, I will update the policy statement, and we can make a note of >> this "convention" in the API documentation as well. >> >> =============== >> >> Issue #2: Immediate Deregistration/Updating >> >> The MOBY Central code does not allow you to deregister a service >> with a >> Signature URL, nor can you update it. This can be very annoying, I >> know!! It's not sufficient to just wait for the agent to visit during >> the night... there must be a better way! >> >> It is undocumented because we're still experimenting to see if >> there are >> any obvious down-sides, but MOBY Central is currently configured to >> trigger an Agent visit if you call the registerService method with >> your >> SignatureURL as the only parameter. This allows you to *immediately* >> deregister or update a service (based on a local edit of your >> Signature >> RDF document) rather than waiting for the next agent crawl. >> >> I invite all developers to try this and let us know if this seems >> like a >> sensible behaviour. There may be better ways to accomplish this, >> so if >> you have other ideas, or if you see any potential security-holes in >> this >> approach, please let us know. >> >> ============ >> >> Cheers all! >> >> Mark >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a >> term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the >> term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 8 12:16:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 11:16:36 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8ACF2.2000901@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> Message-ID: <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> > 1. The RDF is a contract of sorts. If you are not committed enough to > keep the RDF available for download, your service should be > deregistered. Paul, you are not expressing yourself precisely. I agree that the RDF is a contract. But if I do not sign to such contract (by not providing an RDF signature URL) I should not be kick off (but my service should be considered "testing"). I was very happy that we (at least me and Mark) seemed to have consensus on this. Are you telling the same, or are you disagree (and opening this can of worms again)? > > 2. I think the ping should be mandatory, with a valid input test case. The valid input test cases are nice - and we can use them: we have all the machinery in place. Which is: an LSID resolution service to get test input data from a service provider, the predicate name for that, and MOBY_Environment project that can use this test data to check services (of course, you can use your own checking calls). But: it is beyond what a simple ping should do. Simple ping should not do that much and it will still be useful to get fast and cheap reply if a service (or at least its server) is up and running. So I am just for the ping described by Pieter. Nothing more. (And I have it implementd in Perl Moses already.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue Aug 8 13:00:31 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 11:00:31 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> Message-ID: <44D8C32F.6030106@ucalgary.ca> Sorry, I should have expressed this more clearly. I definitely agree with you that if you don't provide a signature URL, you shouldn't be deregistered. But, if you did provide one, you must maintain it. >> 1. The RDF is a contract of sorts. If you are not committed enough to >> keep the RDF available for download, your service should be >> deregistered. >> > > > Paul, you are not expressing yourself precisely. I agree that the RDF is a > contract. But if I do not sign to such contract (by not providing an RDF > signature URL) I should not be kick off (but my service should be considered > "testing"). I was very happy that we (at least me and Mark) seemed to have > consensus on this. Are you telling the same, or are you disagree (and > opening this can of worms again)? > This is where we disagree. As I said earlier, we have an opportunity to enforce robustness in the protocol, and I think we should take it. Obviously, the test case the service provider lists can be a fairly simple one, it is up to them. Which is more useful to the biologist, knowing a service is reachable (empty ping), or knowing it works (test case)? The appropriateness of an empty ping vs. a functional ping probably boils down to where we expect the "robustness score" to be store, by MOBY Centrals, or does each client instance store its own? >> 2. I think the ping should be mandatory, with a valid input test case. >> > > > The valid input test cases are nice - and we can use them: we have all the > machinery in place. Which is: an LSID resolution service to get test input > data from a service provider, the predicate name for that, and > MOBY_Environment project that can use this test data to check services (of > course, you can use your own checking calls). > But: it is beyond what a simple ping should do. Simple ping should not do > that much and it will still be useful to get fast and cheap reply if a > service (or at least its server) is up and running. > So I am just for the ping described by Pieter. Nothing more. (And I have > it implementd in Perl Moses already.) > > > Martin > > > From gordonp at ucalgary.ca Tue Aug 8 13:28:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 11:28:43 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C32F.6030106@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> Message-ID: <44D8C9CB.7010408@ucalgary.ca> Reading my own e-mail, I have an idea: make the empty-ping behaviour part of the MOBY API (which clients MAY call), AND require a valid test case in the RDF description (which MOBY Central WILL call to measure robustness). The best of both world, no? > Sorry, I should have expressed this more clearly. I definitely agree > with you that if you don't provide a signature URL, you shouldn't be > deregistered. But, if you did provide one, you must maintain it. > >>> 1. The RDF is a contract of sorts. If you are not committed enough to >>> keep the RDF available for download, your service should be >>> deregistered. >>> >>> >> Paul, you are not expressing yourself precisely. I agree that the RDF is a >> contract. But if I do not sign to such contract (by not providing an RDF >> signature URL) I should not be kick off (but my service should be considered >> "testing"). I was very happy that we (at least me and Mark) seemed to have >> consensus on this. Are you telling the same, or are you disagree (and >> opening this can of worms again)? >> >> > This is where we disagree. As I said earlier, we have an opportunity to > enforce robustness in the protocol, and I think we should take it. > Obviously, the test case the service provider lists can be a fairly > simple one, it is up to them. Which is more useful to the biologist, > knowing a service is reachable (empty ping), or knowing it works (test > case)? > > The appropriateness of an empty ping vs. a functional ping probably > boils down to where we expect the "robustness score" to be store, by > MOBY Centrals, or does each client instance store its own? > >>> 2. I think the ping should be mandatory, with a valid input test case. >>> >>> >> The valid input test cases are nice - and we can use them: we have all the >> machinery in place. Which is: an LSID resolution service to get test input >> data from a service provider, the predicate name for that, and >> MOBY_Environment project that can use this test data to check services (of >> course, you can use your own checking calls). >> But: it is beyond what a simple ping should do. Simple ping should not do >> that much and it will still be useful to get fast and cheap reply if a >> service (or at least its server) is up and running. >> So I am just for the ping described by Pieter. Nothing more. (And I have >> it implementd in Perl Moses already.) >> >> >> Martin >> >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 8 13:43:02 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 12:43:02 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C32F.6030106@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> Message-ID: <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> > I definitely agree > with you that if you don't provide a signature URL, you shouldn't be > deregistered. But, if you did provide one, you must maintain it. Clear! So is this done and agreed on with everybody? Could anybidy put it in the API documenattion please? This is where we disagree. As I said earlier, we have an opportunity to > enforce robustness in the protocol, and I think we should take it. Well, I am not saying not to take it. I am only advocating to have both, the simple ping and the testing ping. And I am implementing now the empty ping (defined as a request with no mobyData, returning the same back, possibly with some service notes added). The testing ping will have to wait when I have more time for implementing (or using) the LSID resolution service (or at least getting and reading the service RDF document where the input data could be). We (GCP) have may services and we are definitely in favor to have them robust. We think that the empty ping can discover maybe 90% of bad cases, so it means a vey good ROI. The remainig 10%, we will deal with it using test data within the MOBY_Enviroment project. For that (the tetsing ping) we do not need any changes in the MOBY API. So where is the problem? I see the problem is that most people is not saying if they agree with the API for the empty ping as suggested by me ad Pieter. If people say yes, we are done with the empty ping and can concentrate how to persuade people to have also testing ping. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue Aug 8 15:05:04 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 13:05:04 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> Message-ID: <44D8E060.2000205@ucalgary.ca> I think our string of e-mails this morning proves just how valuable a face to face meeting of MOBY developers can be, since we would have found out in 20 seconds that we both agreed with each other on both issues. :-) Is it just me, or is the lag time for mailing list getting verry looooooong...... up to a hour or more? >> I definitely agree >> with you that if you don't provide a signature URL, you shouldn't be >> deregistered. But, if you did provide one, you must maintain it. >> > > > Clear! So is this done and agreed on with everybody? Could anybidy put it in > the API documenattion please? > > > > > This is where we disagree. As I said earlier, we have an opportunity to > >> enforce robustness in the protocol, and I think we should take it. >> > > > Well, I am not saying not to take it. I am only advocating to have both, the > simple ping and the testing ping. And I am implementing now the empty ping > (defined as a request with no mobyData, returning the same back, possibly > with some service notes added). The testing ping will have to wait when I > have more time for implementing (or using) the LSID resolution service (or > at least getting and reading the service RDF document where the input data > could be). > > We (GCP) have may services and we are definitely in favor to have them > robust. We think that the empty ping can discover maybe 90% of bad cases, so > it means a vey good ROI. The remainig 10%, we will deal with it using test > data within the MOBY_Enviroment project. For that (the tetsing ping) we do > not need any changes in the MOBY API. > > So where is the problem? I see the problem is that most people is not saying > if they agree with the API for the empty ping as suggested by me ad Pieter. > If people say yes, we are done with the empty ping and can concentrate how > to persuade people to have also testing ping. > > Martin > > From martin.senger at gmail.com Tue Aug 8 15:47:19 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 14:47:19 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8E060.2000205@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> <44D8E060.2000205@ucalgary.ca> Message-ID: <4d93f07c0608081247h107acb5ej825a85a599b98ff1@mail.gmail.com> > I think our string of e-mails this morning proves just how valuable a > face to face meeting of MOBY developers can be Bingo!!! 100% truth. So what can we do about it? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Aug 8 16:14:56 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Aug 2006 13:14:56 -0700 Subject: [MOBY-dev] [moby] Re: {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8E060.2000205@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> <44D8E060.2000205@ucalgary.ca> Message-ID: <1155068097.5412.8.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-08-08 at 13:05 -0600, Paul Gordon wrote: > I think our string of e-mails this morning proves just how valuable a > face to face meeting of MOBY developers can be Indeed! The barriers from my side have been two-fold. First, the latest MOBY funding award did not include any money for conferences (though I did request it!). In the past I have supplemented the face to face meetings out of the Genome Canada funding so that it wouldn't be so expensive for people to attend. I may be able to find a way to fund the meetings, but I have to talk to the lead PI on the Platform award. Second, I have been trying to hire for the senior developer position for quite a while. I wanted to delay the meeting until this person was hired, since they are going to more or less take-over the majority of ,y own role in running the project day by day. The first two candidates have turned-down the position, sadly. I have now identified a potential candidate who I will be interviewing in a couple of weeks. Hopefully this will come to fruition! The lack of funding for travel is also a barrier for my own attendance at meetings. The previous award had sufficient money for travel, however the new award is intended to be "maintenance only", and travel was not considered necessary for maintenance. Anyway, I'll see if I can scrape-up some funding and/or get industrial sponsorship to help defray the costs of a face-to-face MOBY meeting sometime soon. I'm supposed to be helping Jason Stajich in planning the next BioHackathon, so we might be able to piggy-back on top of that meeting?!? M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From Pieter.Neerincx at wur.nl Thu Aug 10 13:52:13 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 10 Aug 2006 14:52:13 -0300 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C9CB.7010408@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <44D8C9CB.7010408@ucalgary.ca> Message-ID: <00F44F1E-CCB6-460C-98DB-2C972587C941@wur.nl> On 8-Aug-2006, at 2:28 PM, Paul Gordon wrote: > Reading my own e-mail, I have an idea: make the empty-ping behaviour > part of the MOBY API (which clients MAY call), AND require a valid > test > case in the RDF description (which MOBY Central WILL call to measure > robustness). The best of both world, no? Yes, that sounds good to me. I agree with Martin that a ping should be a quick method to check whether a service is up. I welcome the idea of forcing "production quality" services to implement example inputs and outputs to improve robustness, while making this optional for beta services. This should already be possible using LSID resolution, but I was wondering if there is anybody out there who actually implemented this and is using it. If so, is there some documentation on how to do this? Cheers, Pi Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From martin.senger at gmail.com Thu Aug 10 19:05:29 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 10 Aug 2006 18:05:29 -0500 Subject: [MOBY-dev] RDFs from dashboard In-Reply-To: <200608041128.20740.d.haase@gsf.de> References: <200608041128.20740.d.haase@gsf.de> Message-ID: <4d93f07c0608101605o238b900dl574f0cacdac46b4f@mail.gmail.com> Thanks to the Dirk message, I have fixed a bug in jMoby's CentralImpl.java, concerning storing locally an RDF document received from the service registration request. Now the stored file (if you register your service using Dashboard, the returned RDF file is stored automatically on a place you tell Dashboard) is a proper XML document. It would be nice if somebody with a public server can test it (public, because it must invite the RDF agent to check the document). Please "cvs update -dP", as usual. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Aug 11 20:05:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Aug 2006 17:05:58 -0700 Subject: [MOBY-dev] Gbrowse Moby support for Secondaries!!!! Message-ID: Hi all! For any of you who have been waiting in anticipation... Gbrowse Moby now supports Secondary parameters!! http://mobycentral.icapture.ubc.ca Eddie and I have been team coding for a couple of days and it looks like it all works correctly - including writing the value of the chosen parameter into the SCUFL document so that you can run your workflow in high-throughput Taverna with exactly the same settings as in Gbrowse Moby. Thanks to the reviewers of the Gbrowse Moby manuscript (a couple of you are on this list, I'm sure :-) ) for giving me the kick in the pants that I needed to finally get this done! Cheers all! Please contact us if you notice any bugs. Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From martin.senger at gmail.com Wed Aug 16 11:50:11 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 10:50:11 -0500 Subject: [MOBY-dev] MobyServlet.war should not be there Message-ID: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> Paul and all, I had big problems when teaching jMoby. Your file MobyServlet.war is 10 MB long and it causes real problems for people with a slower connection. I also think (even though I cannot be fully sure) that such files (war files) could be created from other pieces that are already part of jMoby CVS - and therefore they should not be in CVS at all. There should be an ant script that creates them if needed. Sorry, Paul, but I have to remove the file. I understand that this is not an ideal step - because now your documentation is out of sync - but I simply did not have other options. Please, please, do not put it back - but make an ant task to create it (for example). Thank you and I apologize for this rather drastic move. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Aug 16 16:06:29 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 16 Aug 2006 14:06:29 -0600 Subject: [MOBY-dev] MobyServlet.war should not be there In-Reply-To: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> Message-ID: <44E37AC5.8080105@ucalgary.ca> Hi Martin, Sorry for the inconvenience. Unfortunately you cannot create it with Ant. It includes a few files not yet in the repository, and anyway would absolutely require the user to have a "virgin" JRE (i.e. with no extra libraries installed, otherwise I can't guarantee the WAR is self-contained). I can, however, repoint the docs to my own Web site to download it. I will do this today. It would be nice to have somewhere in CVS where large binaries can be plopped for the public to download...should we create one at the top level of moby-live somewhere? > Paul and all, > I had big problems when teaching jMoby. Your file MobyServlet.war is 10 > MB long and it causes real problems for people with a slower connection. > I also think (even though I cannot be fully sure) that such files (war > files) could be created from other pieces that are already part of jMoby CVS > - and therefore they should not be in CVS at all. There should be an ant > script that creates them if needed. > Sorry, Paul, but I have to remove the file. I understand that this is not > an ideal step - because now your documentation is out of sync - but I simply > did not have other options. Please, please, do not put it back - but make an > ant task to create it (for example). > > Thank you and I apologize for this rather drastic move. > Martin > > From martin.senger at gmail.com Wed Aug 16 16:35:09 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 15:35:09 -0500 Subject: [MOBY-dev] MobyServlet.war should not be there In-Reply-To: <44E37AC5.8080105@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> Message-ID: <4d93f07c0608161335h4249942fk152ccdd2025ed71@mail.gmail.com> > I can, however, > repoint the docs to my own Web site to download it. I will do this today. Thanks. It would be nice to have somewhere in CVS where large binaries can be > plopped for the public to download... We have it (we use it for third-party jar files). Module name is jars-archive. Feel free to use also for other files. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Aug 16 16:43:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 16 Aug 2006 13:43:04 -0700 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <44E37AC5.8080105@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> Message-ID: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> I don't think that putting it at the top level of moby-live will necessarily help the situation - many (most?) people simply check-out moby-live, rather than moby-live/Perl or moby-live/Java, so they will still get this large file when they do a checkout. If you send me the URL and a description I can add it to the "Tools" page on biomoby.org. I wonder if it is time to re-think the link structure of the website again to make these kinds of resources more prominent? M On Wed, 2006-08-16 at 14:06 -0600, Paul Gordon wrote: > Hi Martin, > > Sorry for the inconvenience. > > Unfortunately you cannot create it with Ant. It includes a few files > not yet in the repository, and anyway would absolutely require the user > to have a "virgin" JRE (i.e. with no extra libraries installed, > otherwise I can't guarantee the WAR is self-contained). I can, however, > repoint the docs to my own Web site to download it. I will do this today. > > It would be nice to have somewhere in CVS where large binaries can be > plopped for the public to download...should we create one at the top > level of moby-live somewhere? > > Paul and all, > > I had big problems when teaching jMoby. Your file MobyServlet.war is 10 > > MB long and it causes real problems for people with a slower connection. > > I also think (even though I cannot be fully sure) that such files (war > > files) could be created from other pieces that are already part of jMoby CVS > > - and therefore they should not be in CVS at all. There should be an ant > > script that creates them if needed. > > Sorry, Paul, but I have to remove the file. I understand that this is not > > an ideal step - because now your documentation is out of sync - but I simply > > did not have other options. Please, please, do not put it back - but make an > > ant task to create it (for example). > > > > Thank you and I apologize for this rather drastic move. > > Martin > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 16 17:02:03 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 16 Aug 2006 15:02:03 -0600 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <44E387CB.2080905@ucalgary.ca> I think I like Mark's approach better than the jars-archive approach, because the major point of the WAR is that you don't need to bother with CVS, Ant, etc. It's for Extremely Lazy Programmers. With regards to the links in general, I agree with Mark that they might need to be made more prominent. While the Web site is a major improvement esthetically over the old one, the useful links where a naive user might actually find something of interest are buried at least 3 links deep. The question is, who has permission and time to update this :-) > I don't think that putting it at the top level of moby-live will > necessarily help the situation - many (most?) people simply check-out > moby-live, rather than moby-live/Perl or moby-live/Java, so they will > still get this large file when they do a checkout. > > If you send me the URL and a description I can add it to the "Tools" > page on biomoby.org. I wonder if it is time to re-think the link > structure of the website again to make these kinds of resources more > prominent? > > M > > > > > On Wed, 2006-08-16 at 14:06 -0600, Paul Gordon wrote: > >> Hi Martin, >> >> Sorry for the inconvenience. >> >> Unfortunately you cannot create it with Ant. It includes a few files >> not yet in the repository, and anyway would absolutely require the user >> to have a "virgin" JRE (i.e. with no extra libraries installed, >> otherwise I can't guarantee the WAR is self-contained). I can, however, >> repoint the docs to my own Web site to download it. I will do this today. >> >> It would be nice to have somewhere in CVS where large binaries can be >> plopped for the public to download...should we create one at the top >> level of moby-live somewhere? >> >>> Paul and all, >>> I had big problems when teaching jMoby. Your file MobyServlet.war is 10 >>> MB long and it causes real problems for people with a slower connection. >>> I also think (even though I cannot be fully sure) that such files (war >>> files) could be created from other pieces that are already part of jMoby CVS >>> - and therefore they should not be in CVS at all. There should be an ant >>> script that creates them if needed. >>> Sorry, Paul, but I have to remove the file. I understand that this is not >>> an ideal step - because now your documentation is out of sync - but I simply >>> did not have other options. Please, please, do not put it back - but make an >>> ant task to create it (for example). >>> >>> Thank you and I apologize for this rather drastic move. >>> Martin >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From martin.senger at gmail.com Wed Aug 16 17:04:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 16:04:06 -0500 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0608161404u5ed9226co9fa67c84d904d918@mail.gmail.com> > I don't think that putting it at the top level of moby-live will > necessarily help the situation No, it would not. But I was not talking about the moby-live level. The jars-archive is on the same level with moby-live - so people taking moby-live are not getting jars-archive (as they are not getting Accessories and s-moby). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Aug 16 17:19:45 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 16:19:45 -0500 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <44E387CB.2080905@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> <44E387CB.2080905@ucalgary.ca> Message-ID: <4d93f07c0608161419h4899f2fm4925daaf0cd5ee54@mail.gmail.com> > I think I like Mark's approach better than the jars-archive approach, > because the major point of the WAR is that you don't need to bother with > CVS, Ant, etc. Do whatever you think better - but you did not understand me: my approach is the same as Mark's - the files from jars-archive are stored and updated by CVS, but users can take them by pure HTTP, as from the Mark's link. The same way as it is done for the third-party libraries in the jMoby - see the ant file and you will see the URL I was talking about. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Fri Aug 18 06:04:03 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Fri, 18 Aug 2006 12:04:03 +0200 Subject: [MOBY-dev] moby service templates Message-ID: Hi all, I am working on something like a MobyServiceTemplate. The idea is to store there templates for other programs to use them to deploy real biomoby services. In my case most of the services I will create are exactly the same, lot of differet databases with the same kind of data, but different data. Therefore their services look the same except that they have different data behind. While creating this serviceTemplates definition I have identified that this are the fields that will NOT be common: -service namespace (one would be "MNCNdatabase" and other could be "IPGRIdatabase") -authURI -contactEmail -description: it will be almost the same but just with some little differences. Apart of this, all the rest can be common: service name, category, type, input/output/secondary objects. Am I missing something? Is there anybody who has something similar? My templates definition file (with one service example and with some things that only apply to my project) can be found at: http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml Thanks in advance. Javier. From markw at illuminae.com Fri Aug 18 12:04:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 18 Aug 2006 09:04:50 -0700 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: References: Message-ID: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit of the service architecture is now auto-generated by their code, so it really just comes down to the service provider writing the business logic. I suppose if the business logic can, in your case, be even further templated then the bar for service provision gets even lower! Must run! M On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: > Hi all, > > I am working on something like a MobyServiceTemplate. The idea is to > store there templates for other programs to use them to deploy real > biomoby services. > In my case most of the services I will create are exactly the same, > lot of differet databases with the same kind of data, but different > data. Therefore their services look the same except that they have > different data behind. > > While creating this serviceTemplates definition I have identified that > this are the fields that will NOT be common: > > -service namespace (one would be "MNCNdatabase" and other could be > "IPGRIdatabase") > -authURI > -contactEmail > -description: it will be almost the same but just with some little differences. > > Apart of this, all the rest can be common: service name, category, > type, input/output/secondary objects. > > Am I missing something? > Is there anybody who has something similar? My templates definition > file (with one service example and with some things that only apply to > my project) can be found at: > > http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml > > Thanks in advance. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Fri Aug 18 12:17:49 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Fri, 18 Aug 2006 18:17:49 +0200 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: Right right, I am basing much of my work on Martin previous work. But what I am doing is adapting a wrapper software (PyWrapper) that is used to connect database to GBIF (do you remember?). The users of this software map their database to a common ontology and then the wrapper can generate "community/standard" XML schemas. The user maps his database visually (through a config tool) and then the work is done. The idea is to provide BioMOBY support there, so automatically when the user maps his database to this common ontology he will become a BioMOBY provider for a certain services. This mapping file is what indicates what "concepts" in out ontology are needed to generate a certain BioMOBY service (defined in the template). So, no programming at all, the database owner maps his database to the ontology and the software takes care of, by looking at the mapping file (curated by a MOBY expert), register and become available as a MOBY service. I think it should work (apart of the multiple invocation who is giving me some headache). The only issue I have is in finding good examples of where is this useful at all (but I suppose this is not my bussiness :D) Javier. On 8/18/06, Mark Wilkinson wrote: > Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit > of the service architecture is now auto-generated by their code, so it > really just comes down to the service provider writing the business > logic. I suppose if the business logic can, in your case, be even > further templated then the bar for service provision gets even lower! > > Must run! > > M > > > On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: > > Hi all, > > > > I am working on something like a MobyServiceTemplate. The idea is to > > store there templates for other programs to use them to deploy real > > biomoby services. > > In my case most of the services I will create are exactly the same, > > lot of differet databases with the same kind of data, but different > > data. Therefore their services look the same except that they have > > different data behind. > > > > While creating this serviceTemplates definition I have identified that > > this are the fields that will NOT be common: > > > > -service namespace (one would be "MNCNdatabase" and other could be > > "IPGRIdatabase") > > -authURI > > -contactEmail > > -description: it will be almost the same but just with some little differences. > > > > Apart of this, all the rest can be common: service name, category, > > type, input/output/secondary objects. > > > > Am I missing something? > > Is there anybody who has something similar? My templates definition > > file (with one service example and with some things that only apply to > > my project) can be found at: > > > > http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml > > > > Thanks in advance. > > > > Javier. > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Sun Aug 20 11:24:55 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Sun, 20 Aug 2006 09:24:55 -0600 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: <44E87EC7.2010105@ucalgary.ca> Hello Javier, You may alternatively want to take a quick look at MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html). You could subclass the MobyServlet with your schema mapping functions, and all the user would need to do is modify the web.xml file. The web.xml file for MobyServlet already contains the "template" that you are looking for... Regards, Paul > Right right, > > I am basing much of my work on Martin previous work. > But what I am doing is adapting a wrapper software (PyWrapper) that is > used to connect database to GBIF (do you remember?). The users of this > software map their database to a common ontology and then the wrapper > can generate "community/standard" XML schemas. The user maps his > database visually (through a config tool) and then the work is done. > The idea is to provide BioMOBY support there, so automatically when > the user maps his database to this common ontology he will become a > BioMOBY provider for a certain services. This mapping file is what > indicates what "concepts" in out ontology are needed to generate a > certain BioMOBY service (defined in the template). > > So, no programming at all, the database owner maps his database to the > ontology and the software takes care of, by looking at the mapping > file (curated by a MOBY expert), register and become available as a > MOBY service. > > I think it should work (apart of the multiple invocation who is giving > me some headache). > The only issue I have is in finding good examples of where is this > useful at all (but I suppose this is not my bussiness :D) > > Javier. > > On 8/18/06, Mark Wilkinson wrote: > >> Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit >> of the service architecture is now auto-generated by their code, so it >> really just comes down to the service provider writing the business >> logic. I suppose if the business logic can, in your case, be even >> further templated then the bar for service provision gets even lower! >> >> Must run! >> >> M >> >> >> On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: >> >>> Hi all, >>> >>> I am working on something like a MobyServiceTemplate. The idea is to >>> store there templates for other programs to use them to deploy real >>> biomoby services. >>> In my case most of the services I will create are exactly the same, >>> lot of differet databases with the same kind of data, but different >>> data. Therefore their services look the same except that they have >>> different data behind. >>> >>> While creating this serviceTemplates definition I have identified that >>> this are the fields that will NOT be common: >>> >>> -service namespace (one would be "MNCNdatabase" and other could be >>> "IPGRIdatabase") >>> -authURI >>> -contactEmail >>> -description: it will be almost the same but just with some little differences. >>> >>> Apart of this, all the rest can be common: service name, category, >>> type, input/output/secondary objects. >>> >>> Am I missing something? >>> Is there anybody who has something similar? My templates definition >>> file (with one service example and with some things that only apply to >>> my project) can be found at: >>> >>> http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml >>> >>> Thanks in advance. >>> >>> Javier. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> K?hler et al, 2006 >> >> _______________________________________________ >> 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 > From martin.senger at gmail.com Mon Aug 21 08:11:03 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 21 Aug 2006 07:11:03 -0500 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0608210511q12c97563u250dea616a690be9@mail.gmail.com> Hi, Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit > of the service architecture is now auto-generated by their code, so it > really just comes down to the service provider writing the business > logic. I suppose if the business logic can, in your case, be even > further templated then the bar for service provision gets even lower! I fully agree with Mark. Here are perhaps more details about what I did with BioCASE (I guess for Tapir it will be similar, even perhaps the same) : You already know the source - but perhaps for the other: http://moby.generationcp.org/bb_services/docs/index.html. The MoSeS can generate an implementtaion class for a service - such class is the same for all services (except the service name). Everything that varies is in the "properties". So the "properties" are similar to the Javier's templates. With Milko (IPGRI), last year, we tried to find a way to define templates - but then we gave it up because of the possible complexity of mapping (just see into an example Javier gave us and you will see a huge number of places to be changed for any new template, for any new BioMoby data type). That's why we decided to go the "properties" way - where we defined a java beanshell script to convert things between biocase and biomoby. It would be nice to find a common way how to make this B(iomoby)B(iocase) wedding. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Tue Aug 22 07:34:41 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Aug 2006 13:34:41 +0200 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: References: Message-ID: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> Hi All, Today I was adding some CrossReference Information Blocks (CRIBs). According to the API documentation the xrefType attribute for an Xref is "a term from the Cross-Reference-Type Ontology indicating the semantic type of this cross-reference". However the documentation doesn't provide a link to this Cross-Reference-Type Ontology. I tried to Google it, but wasn't successful. Where should I look to figure out which xrefTypes are available? It's not part of MOBY Central is it? Cheers, Pi From d.haase at gsf.de Tue Aug 22 08:08:19 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 22 Aug 2006 14:08:19 +0200 Subject: [MOBY-dev] Agent does not change Registry Message-ID: <200608221408.19544.d.haase@gsf.de> Hi there! It seems that the proposed way to change services which are registered with signatureURL does not work. I changed the RDF description of a service, called the agent with the 'registerService' call with only the signature field present and got back the message "The RDFagent call was successful." However, when I looked up the service details with the service encyclopedia or dashboard (after a 'Reload' of course...) the modifications were not displayed. I also checked the modified RDF with the test page. Here I could see the changes, but still no effect on Moby Central. Jost, a service developer from RZPD currently has the same problem. Are we missing something or does the agent just does not work as intended? Best, dirk From edward.kawas at gmail.com Tue Aug 22 09:07:31 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 06:07:31 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608221408.19544.d.haase@gsf.de> Message-ID: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Hi Dirk, Did you by chance modify the timestamp of your LSID in your RDF? The agent only modifies the service if the LSID has changed. Note that this may change in the future. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, August 22, 2006 5:08 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Agent does not change Registry > > Hi there! > > It seems that the proposed way to change services which are > registered with signatureURL does not work. I changed the RDF > description of a service, called the agent with the > 'registerService' call with only the signature field present > and got back the message "The RDFagent call was successful." > However, when I looked up the service details with the > service encyclopedia or dashboard (after a 'Reload' of > course...) the modifications were not displayed. > > I also checked the modified RDF with the test page. Here I > could see the changes, but still no effect on Moby Central. > > Jost, a service developer from RZPD currently has the same > problem. Are we missing something or does the agent just does > not work as intended? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Aug 22 09:30:32 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 22 Aug 2006 15:30:32 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <200608221530.33170.d.haase@gsf.de> On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > Hi Dirk, > > Did you by chance modify the timestamp of your LSID in your RDF? The agent > only modifies the service if the LSID has changed. Ahh, interesting! It did work when I changed the LSID (the timestamp within the LSID, to be precise...). Thanks, dirk From martin.senger at gmail.com Tue Aug 22 09:24:03 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 08:24:03 -0500 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <200608221408.19544.d.haase@gsf.de> <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> > The agent only > modifies the service if the LSID has changed. No! Eddie, haven't you consider our (me, you, Mark) recent email exchange? The service provider will *not* change the LSID. Note that this may change in the future. The future is now. Or was yesterday already. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Tue Aug 22 09:40:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 06:40:34 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> Message-ID: <002801c6c5f0$8cc12950$6400a8c0@notebook> Hi Martin, I am going to change it (probably should have chosen my words better). Before I make those changes, I am going to tie up some loose ends. Sorry for the miscommunication! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 6:24 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > > The agent only > > modifies the service if the LSID has changed. > > > No! Eddie, haven't you consider our (me, you, Mark) recent > email exchange? > The service provider will *not* change the LSID. > > > Note that this may change in the future. > > > The future is now. Or was yesterday already. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue Aug 22 09:58:21 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 22 Aug 2006 07:58:21 -0600 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> References: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> Message-ID: <44EB0D7D.6090800@ucalgary.ca> We never got around to making a proper ontology for it. Right now it's just a string, as far as I know. > Hi All, > > Today I was adding some CrossReference Information Blocks (CRIBs). > According to the API documentation the xrefType attribute for an Xref > is "a term from the Cross-Reference-Type Ontology indicating the > semantic type of this cross-reference". However the documentation > doesn't provide a link to this Cross-Reference-Type Ontology. I tried > to Google it, but wasn't successful. Where should I look to figure > out which xrefTypes are available? It's not part of MOBY Central is it? > > Cheers, > > Pi > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 22 10:09:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 11:09:06 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002801c6c5f0$8cc12950$6400a8c0@notebook> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> Message-ID: <4d93f07c0608220709p2713e216mcd8cb6a662afd7f@mail.gmail.com> Hi Eddie, I am going to change it Thanks! That's a good news. So have you decided to have two version of the RDF documents? The read-only (given from RESOURCES and containing the current LSIDs) and the kind-of-template (given after a service registration, and not containing any LSID)? I think it was roughly what we discussed with Mark recently. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Aug 22 10:34:03 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 22 Aug 2006 14:34:03 +0000 GMT Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002801c6c5f0$8cc12950$6400a8c0@notebook> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> Message-ID: <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> Speaking of LSID's, there's one small and rare loophole in the current plan for LSID's of service instances. Background: the RDF describing a service instance is "owned" by the service provider. It is planned that the address of this RDF document is going to be provided as the LSID resolution address when Moby Central is acting as an LSID authority server. At the moment, this RDF document includes a reference to the Service Instance LSID itself - hence the problem described below (you cannot change the signature without changing the LSID). After discussions with Martin and Eddie we have agreed that the "owner" of an LSID is the LSID authority (moby central) and so the control of LSID versioning should be in moby central rather than the service provider. The new behavior will be that moby central will update both the service registration and the LSID version when the agent visits a service provider and discovers a modified signature RDF. The "gotcha" in this scenario is when moby central is acting as the authority server for an LSID representing a service whose signature has JUST been modified (before the agent visits again). The metadata resolved will not be the same as the last resolution of that LSID. We can either shrug our shoulders and not care about this rare case, or we can slow things down a bit and have mobycentral (when acting as an authority server) resolve an LSID first on its own to be sure its registration is up to date before passing the WSDL of the LSID resolver. How important is this loophole to those who are building tools that rely on LSID resolution? M -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 22 Aug 2006 06:40:34 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] Agent does not change Registry Hi Martin, I am going to change it (probably should have chosen my words better). Before I make those changes, I am going to tie up some loose ends. Sorry for the miscommunication! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 6:24 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > > The agent only > > modifies the service if the LSID has changed. > > > No! Eddie, haven't you consider our (me, you, Mark) recent > email exchange? > The service provider will *not* change the LSID. > > > Note that this may change in the future. > > > The future is now. Or was yesterday already. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > 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 From edward.kawas at gmail.com Tue Aug 22 10:39:29 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 07:39:29 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220709p2713e216mcd8cb6a662afd7f@mail.gmail.com> Message-ID: <003501c6c5f8$c74dbe00$6400a8c0@notebook> Currently when someone registers a service, the RDF is actually taken from a source outside of RESOURCES, so LSIDs will be easy to remove. So what we discussed earlier w.r.t. LSIDs will be changed. I will also take into account all of the previous comments posted to the list (so that people don't get annoyed with the agent). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:09 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Eddie, > > I am going to change it > > > > Thanks! That's a good news. So have you decided to have two > version of the RDF documents? The read-only (given from > RESOURCES and containing the current LSIDs) and the > kind-of-template (given after a service registration, and not > containing any LSID)? I think it was roughly what we > discussed with Mark recently. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From martin.senger at gmail.com Tue Aug 22 10:57:44 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 11:57:44 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> Message-ID: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> Mark, I think that you are describing a "race condition" situation - happening when an operation is not an atomic operation. I think that this loophole is not important assuming that: * after an agent visits the modified RDF, everything become again in sync, and * the database stay in a consistent state. Just my 2c's, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Tue Aug 22 11:02:24 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 08:02:24 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> Message-ID: <003c01c6c5fb$facb04b0$6400a8c0@notebook> Hi Martin, I don't think you understand what Mark is trying to say. Imagine the following scenario: 1. Service provider registers a service gets an RDF document back. 2. Service provider updates RDF and waits for agent to check his document 3. In the meantime, someone queries mobycentral for his service and gets some information back, while someone queries the LSID resolver and gets other information. The 2 pieces of information are out of synch. Did I understand you correctly Mark? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:58 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Mark, > I think that you are describing a "race condition" > situation - happening when an operation is not an atomic > operation. I think that this loophole is not important assuming that: > * after an agent visits the modified RDF, everything > become again in sync, and > * the database stay in a consistent state. > > Just my 2c's, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Aug 22 11:31:28 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 22 Aug 2006 15:31:28 +0000 GMT Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003c01c6c5fb$facb04b0$6400a8c0@notebook> References: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> <003c01c6c5fb$facb04b0$6400a8c0@notebook> Message-ID: <997236587-1156260715-cardhu_blackberry.rim.net-3242-@engine10-cell01> I think you are both right :-) So long as it isn't absolutely critical that the two are in sync 100% of the time, then we'll just ignore the race condition. We can tighten this later if necessary. Cheers all! I'm on holiday in 5 hours! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 22 Aug 2006 08:02:24 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] Agent does not change Registry Hi Martin, I don't think you understand what Mark is trying to say. Imagine the following scenario: 1. Service provider registers a service gets an RDF document back. 2. Service provider updates RDF and waits for agent to check his document 3. In the meantime, someone queries mobycentral for his service and gets some information back, while someone queries the LSID resolver and gets other information. The 2 pieces of information are out of synch. Did I understand you correctly Mark? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:58 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Mark, > I think that you are describing a "race condition" > situation - happening when an operation is not an atomic > operation. I think that this loophole is not important assuming that: > * after an agent visits the modified RDF, everything > become again in sync, and > * the database stay in a consistent state. > > Just my 2c's, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > 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 From Pieter.Neerincx at wur.nl Tue Aug 22 11:58:40 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Aug 2006 17:58:40 +0200 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: <44EB0D7D.6090800@ucalgary.ca> References: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> <44EB0D7D.6090800@ucalgary.ca> Message-ID: Hi Paul, Thanks for the explanation. Then I'll just put something sensible string there for the time being. I'll add a note to the docs that the Cross-Reference-Type Ontology is a vaportology for now... Cheers, Pi On 22-Aug-2006, at 3:58 PM, Paul Gordon wrote: > We never got around to making a proper ontology for it. Right now > it's > just a string, as far as I know. >> Hi All, >> >> Today I was adding some CrossReference Information Blocks (CRIBs). >> According to the API documentation the xrefType attribute for an Xref >> is "a term from the Cross-Reference-Type Ontology indicating the >> semantic type of this cross-reference". However the documentation >> doesn't provide a link to this Cross-Reference-Type Ontology. I tried >> to Google it, but wasn't successful. Where should I look to figure >> out which xrefTypes are available? It's not part of MOBY Central >> is it? >> >> Cheers, >> >> Pi >> >> >> _______________________________________________ >> 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 Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From martin.senger at gmail.com Tue Aug 22 13:17:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 14:17:38 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003c01c6c5fb$facb04b0$6400a8c0@notebook> References: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> <003c01c6c5fb$facb04b0$6400a8c0@notebook> Message-ID: <4d93f07c0608221017l49a12af3gaf7fcf382eb3b6c0@mail.gmail.com> > I don't think you understand what Mark is trying to say. Imagine the > following > scenario: > 1. Service provider registers a service gets an RDF document back. > 2. Service provider updates RDF and waits for agent to check his > document > 3. In the meantime, someone queries mobycentral for his service > and gets > some information back, while someone queries the LSID resolver and gets > other > information. > > The 2 pieces of information are out of synch. Yes, that's what I understood. And it is okay. Because the registration and the agent visit are separate events, they are not treated together as an atomic event. So this happens. If I register something I expect to get back the same information I put there by registration. Which I do. If a service provider changes something but the change was not yet recognized by a registry (meaning "agent has not been traveling") I cannot see it. It seems correct to me. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Wed Aug 23 09:13:01 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 23 Aug 2006 15:13:01 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <200608231513.02249.d.haase@gsf.de> On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > Did you by chance modify the timestamp of your LSID in your RDF? The agent > only modifies the service if the LSID has changed. Unfortunately, this (again) leads to the impossibility to deregister a service: if you delete an RDF, you cannot change the LSID, if you provide a changed LSID, you cannot delete the RDF. I also tried an RDF with modified LSID but no operation specified, but no success: the service remains listed (with old LSID...). Does this mean de-registration still only via the Eddie-Agent? Best, dirk From edward.kawas at gmail.com Wed Aug 23 09:54:24 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 23 Aug 2006 06:54:24 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608231513.02249.d.haase@gsf.de> Message-ID: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> Hi Dirk, To remove a service, call the agent via registerService using only the signatureURL. If the URL exists, then any services the agent finds will be updated/removed/added. If the url doesn't exist, then the agent will remove any services that it once knew about at that URL. I am not sure if what I just said addresses your concerns. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, August 23, 2006 6:13 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > > Did you by chance modify the timestamp of your LSID in your > RDF? The > > agent only modifies the service if the LSID has changed. > > Unfortunately, this (again) leads to the impossibility to deregister a > service: if you delete an RDF, you cannot change the LSID, if > you provide a changed LSID, you cannot delete the RDF. I also > tried an RDF with modified LSID but no operation specified, > but no success: the service remains listed (with old LSID...). > > Does this mean de-registration still only via the Eddie-Agent? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Wed Aug 23 10:19:03 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 23 Aug 2006 16:19:03 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> References: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> Message-ID: <200608231619.03563.d.haase@gsf.de> On Wednesday 23 August 2006 15:54, Edward Kawas wrote: > Hi Dirk, > > To remove a service, call the agent via registerService using only the > signatureURL. If the URL exists, then any services the agent finds will be > updated/removed/added. If the url doesn't exist, then the agent will remove > any services that it once knew about at that URL. That's how I understood the mechanism and what the docs say... > I am not sure if what I just said addresses your concerns. In principle yes, but what I wanted to say is that the removal part of it does not work. An example is the mips service getTmhmmPrediction which is registered with the signature URL http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf This URL currently does not exist. I successfully called the agent, but the service is not deleted. Same situation for the gabi.rzpd.de service checkGabiPDBySequence. Best, dirk From edward.kawas at gmail.com Wed Aug 23 10:26:27 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 23 Aug 2006 07:26:27 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608231619.03563.d.haase@gsf.de> Message-ID: <003901c6c6c0$1f8be480$6700a8c0@notebook> Hi Dirk, The agent was misconfigured (I had it so that the agent would not remove anything from the registry). You can try again and I am sure it will work. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, August 23, 2006 7:19 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 15:54, Edward Kawas wrote: > > Hi Dirk, > > > > To remove a service, call the agent via registerService > using only the > > signatureURL. If the URL exists, then any services the agent finds > > will be updated/removed/added. If the url doesn't exist, then the > > agent will remove any services that it once knew about at that URL. > > That's how I understood the mechanism and what the docs say... > > > I am not sure if what I just said addresses your concerns. > > In principle yes, but what I wanted to say is that the > removal part of it does not work. An example is the mips > service getTmhmmPrediction which is registered with the > signature URL > http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf > This URL currently does not exist. I successfully called the > agent, but the service is not deleted. Same situation for the > gabi.rzpd.de service checkGabiPDBySequence. > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Fri Aug 25 03:54:03 2006 From: d.haase at gsf.de (Dirk Haase) Date: Fri, 25 Aug 2006 09:54:03 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003901c6c6c0$1f8be480$6700a8c0@notebook> References: <003901c6c6c0$1f8be480$6700a8c0@notebook> Message-ID: <200608250954.03591.d.haase@gsf.de> On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > Hi Dirk, > > The agent was misconfigured (I had it so that the agent would not remove > anything from the registry). You can try again and I am sure it will work. Yes, great, now it works, thank you. BUT: in turn, changes within the RDF are not written to the database anymore either with or without LSID modification. Of course I can now change everything by de-register, change RDF, re-register. But this involves the danger of modifying the service but not the LSID - which I think is against the LSID specification, right? Best, dirk From Pieter.Neerincx at wur.nl Fri Aug 25 07:12:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 13:12:58 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 In-Reply-To: <1154976083.44d78953058fb@webmail.cs.umu.se> References: <1154976083.44d78953058fb@webmail.cs.umu.se> Message-ID: Hi Johan et al., Thank you very much for the updated proposal! It took me a few days to read the proposal and all the referenced standards, so I can imagine it took you quite some time to put this together. I think the big picture looks good, but I do have a few small comments / questions. I'll send them one comment / e-mail in order prevent mixed up discussions and lengthy e-mails... Thanks, Pi On 7-Aug-2006, at 8:41 PM, Johan Karlsson wrote: > Hello, > > Attached to this email you can find an updated version (2.2) of the > INB proposal > for asynchronous services. > > We have added some things that were suggested during the > discussions and changed > some wordings to make it more clear what is intended. Please see > summary in the > end of this letter for the main changes. We are very grateful for > earlier > comments and suggestions and hope for more. If there is something > we missed to > update from the earlier discussion, please let us know. > > The great difference from the earlier public version is that we are > now using an > OASIS standard, the Web Services Resource Framework (WSRF), to > communicate > status and results. The main reason is that the polling approach > that we are > advocating requires that the web-service in question maintains some > sort of > state and WSRF is exactly intended to provide a standardised way to > handle > this. > > We realise that WSRF might be a new experience for many BioMOBY- > developers and > therefore we have developed some functions to simplify > implementation of > asynchronous services and clients (in Perl) and a prototype to > illustrate their > use. In fact, to write a basic asynchronous BioMOBY service with > the library is > not much different compared to how it is done for synchronous > services (see > HelloWorld.pm). > > More details about the modules and the prototype here: > > http://bioinfo.pcm.uam.es/prototype/ > > There you can also find an example of a WSDL (mentioned in the > document but not > included as appendix for reasons of readability). The parts > relating to WSRF > would have to be added to the WSDL that MobyCentral generates today. > > Let us restart the discussions and reach an agreement soon, > asynchronous > services/clients are definitely needed. Should we set as a goal to > reach a > decision on the RFC by the end of August? > > Suggestions/improvements and comments for both the proposal and the > modules are > greatly welcomed. > > Summary of major changes in the document: > > - WSRF to communicate state information instead of MobyStatus > - It is possible to retrieve results or status for specific > mobyData inputs > ("jobs") > - Better descriptions of job and batch-call > - More descriptions of the error-cases > - Updated information about how to describe async services in RDF > (Mark, can you please double-check this, we need a Boolean > value for this) > - The category field from findService output will have four > allowed values > 'moby', 'moby-async', 'cgi' and 'soap'. > - The SOAP method to start a call is now called > servicename_submit (before > servicename_async) > > Apologies for the long delay but there has been some fundamental > changes that > required some study and implementation. > > Warm greetings from Malaga, > Johan Karlsson, GNV5 > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Aug 25 07:45:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 13:45:39 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <1154976083.44d78953058fb@webmail.cs.umu.se> References: <1154976083.44d78953058fb@webmail.cs.umu.se> Message-ID: <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> Hi all, The proposal contains some example XML for GetReourceProperty and GetMultipleResourceProperties requests. On page 12 there are the requests to poll for service execution status and on page 13/14 for service results. If I understood correctly these requests for resource properties MUST contain a tag in the SOAP header according to the WSRF standard. So I think the XML should look like this: SOAP XML requests to poll for service execution status: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . status_queryId00 Or for retrieving multiple resource properties in one go: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetMultipleResourceProperties/GetMultipleResourcePropertiesRequest . . . status_queryId00 status_queryId01 . . . Similarly http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse and http://docs.oasis-open.org/wsrf/rpw-2/ GetMultipleResourceProperties/GetMultipleResourcePropertiesResponse MUST be added to the responses for the requests. Furthermore the same tags should be added to requests and responses to retrieve the results. Or did I get these standards documents wrong? The BioMOBY Async proposal was very readable, but I have to admit the WSRF, WS Addressing and LSAE docs drove me nuts sometimes... Cheers, Pi From Pieter.Neerincx at wur.nl Fri Aug 25 08:08:06 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 14:08:06 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - xmlns:rpimpl ? Message-ID: <3A58B4C7-BCE8-4EB9-95F4-4135833F8DD6@wur.nl> Hi all, The BioMOBY Async services proposal introduces the tag as a wsa:ReferenceParameter. In all the examples this tag is put in the "rpimpl" namespace, but I was wondering: shouldn't this be in our own "moby" namespace. According to the "Web Services Resource Framework (WSRF) ? Primer v1.2" document rpimpl = Schema definition for implementation- dependent WS-Addressing reference parameters. Please note that this document is a "committee draft" and it's not a "standard" yet. I can not find any references to the rpimpl namespace in any of the documents describing the latest WS-A core, WS-A SOAP binding, WS- Resource and WS-ResourceProperties standards. As far as I can tell we can simply use . Cheers, Pi From Pieter.Neerincx at wur.nl Fri Aug 25 08:27:38 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 14:27:38 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? Message-ID: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> Hi all, The WS-Addressing 1.0 SOAP Binding specifies that reference parameters that are used in a SOAP Header MUST have the wsa:IsReferenceParameter parameter with the value true. This is currently missing from the BioMOBY Async services proposal. Hence, if we use our "ticket" as a reference parameter in a and this ticket is used to poll for service status the tag should look like this: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . status_queryId00 wsa:IsReferenceParameter attribute also needs to be added to the XML for other requests to get resource properties and to the XML for the destroy request. Cheers, Pi From johan at ac.uma.es Fri Aug 25 10:31:59 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 25 Aug 2006 16:31:59 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> Message-ID: <44EF09DF.6020808@ac.uma.es> Hi Pieter (and thanks for the comments)! Pieter Neerincx wrote: > Hi all, > > The proposal contains some example XML for GetReourceProperty and > GetMultipleResourceProperties requests. On page 12 there are the > requests to poll for service execution status and on page 13/14 for > service results. If I understood correctly these requests for > resource properties MUST contain a tag in the SOAP > header according to the WSRF standard. So I think the XML should look > like this: > > SOAP XML requests to poll for service execution status: > > > > . . . > http://myserver.com/MyService > ID > http://docs.oasis-open.org/wsrf/rpw-2/ > GetResourceProperty/GetResourcePropertyRequest > . . . > > > status_queryId00 > > > I think you are completely right about the missing wsa:Action, we must have missed to put it in the document... it does appear messages the prototype sends but with a slightly different URL: http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties/GetResourcePropertyResponse However, I think this comes from the WSRF::Lite version we use. We will check and let you know more. > Or did I get these standards documents wrong? The BioMOBY Async > proposal was very readable, but I have to admit the WSRF, WS > Addressing and LSAE docs drove me nuts sometimes... > I totally agree, the WRSF and WS-adressing documents are not light reading... :-) Kind regards, Johan From edward.kawas at gmail.com Fri Aug 25 11:00:58 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 25 Aug 2006 08:00:58 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608250954.03591.d.haase@gsf.de> Message-ID: <005301c6c857$466b39a0$6400a8c0@notebook> Hi Dirk, Changes that are found should be reflected in the registry if there are updates. Can you pass along the url that isn't working for you so I can try it? As for LSIDs, don't worry too much about them right now. The agent now should not be worrying about LSIDs. The registry is the only one that should be updating the LSID and now the agent takes that into account. I know that I said that LSIDs were important a few messages back, but now I retract those comments! Give it a try again and then let me know what happens. If the agent fails to update your services please just send me the URL and I will try to see what is happening. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Friday, August 25, 2006 12:54 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > Hi Dirk, > > > > The agent was misconfigured (I had it so that the agent would not > > remove anything from the registry). You can try again and I > am sure it will work. > > Yes, great, now it works, thank you. BUT: in turn, changes > within the RDF are not written to the database anymore either > with or without LSID modification. > > Of course I can now change everything by de-register, change > RDF, re-register. > But this involves the danger of modifying the service but not > the LSID - which I think is against the LSID specification, right? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Fri Aug 25 12:44:42 2006 From: d.haase at gsf.de (Haase, Dirk) Date: Fri, 25 Aug 2006 18:44:42 +0200 Subject: [MOBY-dev] Agent does not change Registry References: <005301c6c857$466b39a0$6400a8c0@notebook> Message-ID: <1D78CE9FD586024AB0E0102F6F9A7CF86A0892@sw-rz010.gsf.de> Hi Eddie, it is still the same service which I'm playing around with: getTmhmmPrediction with the URL http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf. I changed the contact email, called the agent but could not see it in the registry (I used dashboard as browser and did reload before I checked...). Currently this RDF and registry are in sync, because I had totally un-registered it and the re-submitted the rdf, so there is not much to see now... Unfortunately I'm already out of office, so I can't do anything about it now. Nice Weekend, dirk -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Edward Kawas Sent: Fri 8/25/2006 5:00 PM To: 'Core developer announcements' Subject: Re: [MOBY-dev] Agent does not change Registry Hi Dirk, Changes that are found should be reflected in the registry if there are updates. Can you pass along the url that isn't working for you so I can try it? As for LSIDs, don't worry too much about them right now. The agent now should not be worrying about LSIDs. The registry is the only one that should be updating the LSID and now the agent takes that into account. I know that I said that LSIDs were important a few messages back, but now I retract those comments! Give it a try again and then let me know what happens. If the agent fails to update your services please just send me the URL and I will try to see what is happening. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Friday, August 25, 2006 12:54 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > Hi Dirk, > > > > The agent was misconfigured (I had it so that the agent would not > > remove anything from the registry). You can try again and I > am sure it will work. > > Yes, great, now it works, thank you. BUT: in turn, changes > within the RDF are not written to the database anymore either > with or without LSID modification. > > Of course I can now change everything by de-register, change > RDF, re-register. > But this involves the danger of modifying the service but not > the LSID - which I think is against the LSID specification, right? > > Best, > dirk > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3962 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060825/9180e928/attachment.bin From edward.kawas at gmail.com Fri Aug 25 13:26:21 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 25 Aug 2006 10:26:21 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <1D78CE9FD586024AB0E0102F6F9A7CF86A0892@sw-rz010.gsf.de> Message-ID: <006001c6c86b$9615e130$6400a8c0@notebook> Hi Dirk, Another tool you can use to visualize the service is the lsid resolver: http://mobycentral.icapture.ubc.ca/LSID_resolver.html. This always returns the latest metadata. Maybe on Monday, you could add a space to the description or something like that and then call the agent and tell me if things went smoothly. I don't see why it isnt working for you other than the fact that there just might be a problem with the RDF. Anyways, I am going to check the logs and if I see something weird I will let you know. Thanks for your patience! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Haase, Dirk > Sent: Friday, August 25, 2006 9:45 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Eddie, > > it is still the same service which I'm playing around with: > getTmhmmPrediction with the URL > http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf. > I changed the contact email, called the agent but could not > see it in the registry (I used dashboard as browser and did > reload before I checked...). > > Currently this RDF and registry are in sync, because I had > totally un-registered it and the re-submitted the rdf, so > there is not much to see now... > Unfortunately I'm already out of office, so I can't do > anything about it now. > > Nice Weekend, > dirk > > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org on behalf of Edward Kawas > Sent: Fri 8/25/2006 5:00 PM > To: 'Core developer announcements' > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Dirk, > > Changes that are found should be reflected in the registry if > there are updates. > Can you pass along the url that isn't working for you so I can try it? > > As for LSIDs, don't worry too much about them right now. The > agent now should not be worrying about LSIDs. The registry is > the only one that should be updating the LSID and now the > agent takes that into account. I know that I said that LSIDs > were important a few messages back, but now I retract those comments! > > Give it a try again and then let me know what happens. If the > agent fails to update your services please just send me the > URL and I will try to see what is happening. > > Thanks, > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Friday, August 25, 2006 12:54 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] Agent does not change Registry > > > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > > Hi Dirk, > > > > > > The agent was misconfigured (I had it so that the agent would not > > > remove anything from the registry). You can try again and I > > am sure it will work. > > > > Yes, great, now it works, thank you. BUT: in turn, changes > within the > > RDF are not written to the database anymore either with or without > > LSID modification. > > > > Of course I can now change everything by de-register, change RDF, > > re-register. > > But this involves the danger of modifying the service but > not the LSID > > - which I think is against the LSID specification, right? > > > > Best, > > dirk > > _______________________________________________ > > 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 > > From martin.senger at gmail.com Fri Aug 25 19:21:15 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 25 Aug 2006 20:21:15 -0300 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44EF09DF.6020808@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> Message-ID: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Sorry, I was not able to read the new proposal when it came. I am still not able to read it in all details (I am traveling and will be actually completely off-line next two weeks) - but I think that the proposal is fine and I would for with it. Thanks for creating it. Just two comments: I agree that storing the fact that a service is able to be called asynchronously should be part of the service registration process. That would simplify everything. But I do not fully understand why it cannot be done only by registering a service with a new category (moby-async, as suggested). Why do we need a new boolean parameter for it? Why do we need 'hasCallingDetail" - here again a new category should be enough. What am I missing? The second comment is more or less political (and I do not mean it as an argument against your proposal, I like your proposal): So far, the BioMoby did not use anything from the web services protocol. Well, the registry generated WSDL but this WSDL was not that useful. Which lead me recently to the idea that the new BioMoby (sometimes called Moby2) may abandon the SOAP completely, and to stick with the REST architecture. Mainly because of better future collaboration with the S-Moby (the semantic guys in Sante Fe will never accept SOAP - my personal feeling). So now going actually closer to the web services standards may again put us further from them. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sat Aug 26 08:44:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 26 Aug 2006 05:44:36 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 In-Reply-To: <44EF09DF.6020808@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> Message-ID: >> > I totally agree, the WRSF and WS-adressing documents are not light > reading... :-) Yeah, I thought they lacked examples... Unfortunately, it doesn't look like there has been much up-take of this "standard" by many people so far, so there's a dearth of resources out there on the Web to look at or copy. I prefer to see the final product and dissect it rather than attempt to build the final product from the documentation... but that's the geneticist in me ;-) ;-) I'm glad this is moving forward, though! Hopefully this can get adopted quickly and we can push MOBY 1.0 out the door! M From markw at illuminae.com Sat Aug 26 09:12:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 26 Aug 2006 06:12:09 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: v.v. the political statement: I strongly agree with Martin, in part, and somewhat agree with him in another part :-) My personal opinion on the Pseudo-Web Services approach that MOBY uses is that it has been more of a barrier than a benefit. I don't think this is a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the WS architecture itself is not quite as useful as it was marketed to be in past years. In this regard, moving toward a REST-style architecture for "MOBY 2" is something I am strongly in favour of because it seems like the right thing to do, especially in the emergent Semantic Web world; the fact that it also moves us closer to the S-MOBY architecture is just icing :-) however, v.v. the asynchronous services proposal, I think we have to lie in the bed we have made at least for the time being. Fixing one of the most troublesome aspects of the current MOBY protocol in the short term for the wider community, while having the core developers explore what MOBY 2.0 "looks like", seems to me like a good idea, and especially if the proponents of the asynch proposal are building/have built the tooling for us already. So, given that MOBY is already married to SOAP, it doesn't concern me too much if we add another SOAPy component to it. It's a shame that the WSRF framework itself isn't more widely used, but if it does what we need it to do we might as well take advantage of it. Just my opinion... but I'm on holiday, so I'm only using a small part of my brain to think about it :-) Mark On Fri, 25 Aug 2006 16:21:15 -0700, Martin Senger wrote: > Sorry, I was not able to read the new proposal when it came. I am still > not > able to read it in all details (I am traveling and will be actually > completely off-line next two weeks) - but I think that the proposal is > fine > and I would for with it. Thanks for creating it. > > Just two comments: > > I agree that storing the fact that a service is able to be called > asynchronously should be part of the service registration process. That > would simplify everything. But I do not fully understand why it cannot be > done only by registering a service with a new category (moby-async, as > suggested). Why do we need a new boolean parameter for it? Why do we need > 'hasCallingDetail" - here again a new category should be enough. What am > I > missing? > > The second comment is more or less political (and I do not mean it as an > argument against your proposal, I like your proposal): > > So far, the BioMoby did not use anything from the web services protocol. > Well, the registry generated WSDL but this WSDL was not that useful. > Which > lead me recently to the idea that the new BioMoby (sometimes called > Moby2) > may abandon the SOAP completely, and to stick with the REST architecture. > Mainly because of better future collaboration with the S-Moby (the > semantic > guys in Sante Fe will never accept SOAP - my personal feeling). So now > going > actually closer to the web services standards may again put us further > from > them. > > Cheers, > Martin > From tmo at ebi.ac.uk Sat Aug 26 12:12:25 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Sat, 26 Aug 2006 17:12:25 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: <44F072E9.5050206@ebi.ac.uk> Mark Wilkinson wrote: > v.v. the political statement: I strongly agree with Martin, in part, and > somewhat agree with him in another part :-) > > My personal opinion on the Pseudo-Web Services approach that MOBY uses is > that it has been more of a barrier than a benefit. I don't think this is > a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the > WS architecture itself is not quite as useful as it was marketed to be in > past years. In this regard, moving toward a REST-style architecture for > "MOBY 2" is something I am strongly in favour of because it seems like the > right thing to do, especially in the emergent Semantic Web world; the fact > that it also moves us closer to the S-MOBY architecture is just icing :-) One thing to consider here is that you're potentially missing out on the additional capabilities you can inherit from a web service platform. I tend to agree with both you and Martin on this (Martin has sat next to me in an office for some years and so should know my generally low opinion of the current state of the web service world!). Where WS can really come into their own is their ability to add aspects such as security and robust message transport without any additional effort from the MOBY community. It might be worth taking a look at the work we've been doing with OMII-UK (the umbrella organization in the UK which has in the last year absorbed both myGrid and OGSA-DAI). They (we?) have a container configuration with support for WS-Security (certificate based authentication) and will support its use in escience projects. Use of WS 'standards' incurs a cost, both in initial development time and in runtime complexity. It potentially reaps a benefit if you go on to make use of the full suite (or a substantial subset) of additional capabilities such as security, WSRF style session management, full message description and the like. Before dropping WS invocation support entirely you need to consider the potential future requirements that it might fill more easily than a home grown implementation. There is of course always the political aspect - we've already had people say "we can't use taverna as, although it works and does what we want, it isn't a 'standard'". Sad but true. This isn't an exclusive choice of course, you could (and maybe should) have a simple REST-like invocation interface alongside a more complex and potentially extensible SOAP based one. Just my thoughts, Tom From d.haase at gsf.de Mon Aug 28 05:24:48 2006 From: d.haase at gsf.de (Dirk Haase) Date: Mon, 28 Aug 2006 11:24:48 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <006001c6c86b$9615e130$6400a8c0@notebook> References: <006001c6c86b$9615e130$6400a8c0@notebook> Message-ID: <200608281124.48555.d.haase@gsf.de> On Friday 25 August 2006 19:26, Edward Kawas wrote: > Maybe on Monday, you could add a space to the description or something like > that and then call the agent and tell me if things went smoothly. I don't > see why it isnt working for you other than the fact that there just might > be a problem with the RDF. Anyways, I am going to check the logs and if I > see something weird I will let you know. OK, I tried some modifications this morning and everything went well. I think, on Friday, I was bluffed by the dashboard which does an auto-reload after the agent call, but obviously first checks the LSID version and gets the service details from MOBY Central only if that had changed (which actually does make sense...). This still does not explain why certain changes were not displayed despite a LSID version update, but important is only that it does work now... > Thanks for your patience! Thanks for yours ;-) dirk From johan at ac.uma.es Mon Aug 28 07:06:18 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 28 Aug 2006 13:06:18 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? In-Reply-To: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> References: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> Message-ID: <44F2CE2A.3080806@ac.uma.es> Pieter, You are right, in fact, the prototype also contains this "isReferenceParameter" attribute. It seems that we missed to include this in the examples of the proposal. Kind regards, Johan Pieter Neerincx wrote: > Hi all, > > The WS-Addressing 1.0 SOAP Binding specifies that reference > parameters that are used in a SOAP Header MUST have the > wsa:IsReferenceParameter parameter with the value true. This is > currently missing from the BioMOBY Async services proposal. > > Hence, if we use our "ticket" as a > reference parameter in a and this ticket is > used to poll for service status the tag > should look like this: > > > > . . . > http://myserver.com/MyService > ID moby:ServiceInvocationId> > http://docs.oasis-open.org/wsrf/rpw-2/ > GetResourceProperty/GetResourcePropertyRequest > . . . > > > status_queryId00 > > > > wsa:IsReferenceParameter attribute also needs to be added to the XML > for other requests to get resource properties and to the XML for the > destroy request. > > Cheers, > > Pi > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From Pieter.Neerincx at wur.nl Mon Aug 28 07:43:34 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 13:43:34 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? In-Reply-To: <44F2CE2A.3080806@ac.uma.es> References: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> <44F2CE2A.3080806@ac.uma.es> Message-ID: <772951DD-0BA8-406B-A7F5-3BE85C3D9724@wur.nl> Hi Johan, On 28-Aug-2006, at 1:06 PM, Johan Karlsson wrote: > Pieter, > > You are right, in fact, the prototype also contains this > "isReferenceParameter" attribute. Ok, I have to admit I didn't run the prototype yet. I Just tried to understand the proposal from the docs :). Cheers, Pi > > It seems that we missed to include this in the examples of the > proposal. > > Kind regards, > Johan > > Pieter Neerincx wrote: >> Hi all, >> >> The WS-Addressing 1.0 SOAP Binding specifies that reference >> parameters that are used in a SOAP Header MUST have the >> wsa:IsReferenceParameter parameter with the value true. This is >> currently missing from the BioMOBY Async services proposal. >> >> Hence, if we use our "ticket" as a >> reference parameter in a and this ticket is >> used to poll for service status the tag >> should look like this: >> >> >> >> . . . >> http://myserver.com/MyService >> ID> moby:ServiceInvocationId> >> http://docs.oasis-open.org/wsrf/rpw-2/ >> GetResourceProperty/GetResourcePropertyRequest >> . . . >> >> >> status_queryId00 >> >> >> >> wsa:IsReferenceParameter attribute also needs to be added to the XML >> for other requests to get resource properties and to the XML for the >> destroy request. >> >> Cheers, >> >> Pi >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Mon Aug 28 08:47:29 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 14:47:29 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - Politics In-Reply-To: <44F072E9.5050206@ebi.ac.uk> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> Message-ID: <4BA2F610-2BBB-47A2-BC75-50AE2FE7A21E@wur.nl> Hi, I'm lost; I honestly don't know who to agree with on this one. What impact exactly do the political statements below have on the BioMOBY Async Services proposal? Is WSRF bad? If so, do we have an alternative that actually works today (Ok, maybe tomorrow, but at least soon). If we can polish the proposal a little and make it forward compatible with BioMOBY 2.0 that would be great, but unless we see a proposal for that popping up in the next week, I suggest we save the politics for a discussion about BioMOBY 2.0 during a future meeting and start using standardised asynchronous services a.s.a.p. The thing I like most about BioMOBY is that it actually works for me today even though the API hasn't reached a 1.0 status yet :). Just my ? 0,02 Pi On 26-Aug-2006, at 6:12 PM, Tom Oinn wrote: > Mark Wilkinson wrote: >> v.v. the political statement: I strongly agree with Martin, in >> part, and >> somewhat agree with him in another part :-) >> >> My personal opinion on the Pseudo-Web Services approach that MOBY >> uses is >> that it has been more of a barrier than a benefit. I don't think >> this is >> a consequence of MOBY not using all of SOAP/WSDL, I feel it is >> because the >> WS architecture itself is not quite as useful as it was marketed >> to be in >> past years. In this regard, moving toward a REST-style >> architecture for >> "MOBY 2" is something I am strongly in favour of because it seems >> like the >> right thing to do, especially in the emergent Semantic Web world; >> the fact >> that it also moves us closer to the S-MOBY architecture is just >> icing :-) > > One thing to consider here is that you're potentially missing out > on the > additional capabilities you can inherit from a web service platform. I > tend to agree with both you and Martin on this (Martin has sat next to > me in an office for some years and so should know my generally low > opinion of the current state of the web service world!). > > Where WS can really come into their own is their ability to add > aspects > such as security and robust message transport without any additional > effort from the MOBY community. It might be worth taking a look at the > work we've been doing with OMII-UK (the umbrella organization in > the UK > which has in the last year absorbed both myGrid and OGSA-DAI). They > (we?) have a container configuration with support for WS-Security > (certificate based authentication) and will support its use in > escience > projects. > > Use of WS 'standards' incurs a cost, both in initial development time > and in runtime complexity. It potentially reaps a benefit if you go on > to make use of the full suite (or a substantial subset) of additional > capabilities such as security, WSRF style session management, full > message description and the like. Before dropping WS invocation > support > entirely you need to consider the potential future requirements > that it > might fill more easily than a home grown implementation. There is of > course always the political aspect - we've already had people say "we > can't use taverna as, although it works and does what we want, it > isn't > a 'standard'". Sad but true. > > This isn't an exclusive choice of course, you could (and maybe should) > have a simple REST-like invocation interface alongside a more complex > and potentially extensible SOAP based one. > > Just my thoughts, > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Mon Aug 28 09:28:39 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 28 Aug 2006 06:28:39 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608281124.48555.d.haase@gsf.de> Message-ID: <001701c6caa5$e08eb020$6400a8c0@notebook> Hi Dirk, I am glad to hear that its working! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Monday, August 28, 2006 2:25 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Friday 25 August 2006 19:26, Edward Kawas wrote: > > Maybe on Monday, you could add a space to the description > or something > > like that and then call the agent and tell me if things > went smoothly. > > I don't see why it isnt working for you other than the fact > that there > > just might be a problem with the RDF. Anyways, I am going > to check the > > logs and if I see something weird I will let you know. > > OK, I tried some modifications this morning and everything > went well. I think, on Friday, I was bluffed by the dashboard > which does an auto-reload after the agent call, but obviously > first checks the LSID version and gets the service details > from MOBY Central only if that had changed (which actually > does make sense...). This still does not explain why certain > changes were not displayed despite a LSID version update, but > important is only that it does work now... > > > Thanks for your patience! > > Thanks for yours ;-) > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Mon Aug 28 10:00:55 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 16:00:55 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - The location of queryIDs Message-ID: Hi all, I really like the GetResourceProperty, GetMultipleResourceProperties and the Destroy methods/services in the new proposal. With the previous proposal a service provider had to write a service to get the status, one to get the results and one to delete the results for each async submit service. The logic to submit a job might be quite different for different tools, but the logic to get the status of a submitted job, to get the results or to trash a job can be exactly the same for many different tools. Therefore I like the idea of reducing redundancy by implementing only one GetResourceProperty, one GetMultipleResourceProperties and one Destroy service for all the async submit services I might want to develop. There is only one thing that I don't like about the current proposal: the location of queryID. For our current synchronous services it's an attribute of the mobyData element. In the current async services proposal the queryID jumps around the XML taking several identities: * in status_queryID01 it is part of raw text. * in it is part of an element name in the lsae namespace. (By the way: Should this element really be in the lsae namespace? I don't think our status_queryIDxx elements are part of the LSAE specs...) * in result_queryID01 it is part of raw text. * in it is part of an element name in the moby namespace. * in as an attribute. Although this might work it, I think it is confusing and if I got the specs correct it also makes life more complicated than necessary. 1. When I submit an async job, the proposed result contains a ServiceInvocationID that identifies the complete batch, but the queryIDs of the individual jobs are not listed in this result. When I want to retrieve the status, retrieve the results or destroy the jobs I do need these queryIDs though. This means that as a client I have to keep track of the queryIDs. I'm not sure how it works for the Java guys, but as I Perl guy I usually don't have to worry about the queryIDs. I don't create them myself, they are automatically created when I submit data to a service using the BioMOBY Perl modules. With the current proposal I would have parse the XML again to get the queryIDs, I would have to store them locally and finally merge this information with the ticket (ServiceInvocationID) I got back from the service to create a request to get the status or results. It would be much more convenient if the result from a asynchronous service invocation would contain both the ServiceInvocationID *AND* the associated queryIDs. In that case I only have to parse the service response to create GetResourceProperty requests. Therefore I propose to supply the queryIDs as wsa:ReferenceParameters just like the ServiceInvocationID. 2. WSRF contains an *optional* method to request a resource properties document. With this method a client can figure out which resource properties are available and hence what it can request. Although this method is optional and the current proposal doesn't mention it, I think it would good to keep the option open to supply such a method. WSRF does not put any limitations on how a service generates and provides such a document, so you can generate it dynamically or it can be a static thing. If we would want to supply such a resource properties document in the future it would be the easiest if it can be a static one. However in the current proposal the queryIDs are part of the resource properties (status_queryIDxx and result_queryIDxx). This means that the available resource properties depend on the amount of queries/jobs that were sent to a service and hence we can not use a static resource properties document. It would be more convenient if we can strip the queryIDs from the resource properties and provide them as wsa:ReferenceParameters. In that case there are only two resource properties (status and result) and we can describe those in a static resource properties document. 3. Because of the queryID merged with the "result" resource property, the result from a asynchronous service contains a bit of redundancy in the current proposal. The queryID is supplied twice: once in and once in . Furthermore because of the queryID merged to the result resource property the and tags have to be repeated for each queryID. Therefore the results are slightly different as compared to results from a synchronous service where and are present only once. If the queryIDs are stripped from the result resource property and supplied as wsa:ReferenceParameters, the results can be more similar the synchronous service output with only one "result" tag, one tag and one tag for one or more blocks. Therefore I propose a translocation of BioMOBY queryIDs from the resource properties to wsa:ReferenceParameters. As far as I understand, with all the specifications involved this would be legal, but please correct me if I am wrong. Below I included some examples of what the XML might look like when the queryIDs are moved to the SOAP header as wsa:ReferenceParameters. Let me know what you think.... Cheers, Pi Response for accepted asynchronous service execution: . . . http://myserver.com/MyService . . . GetResourceProperty request to poll for service execution status: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . . . . moby:ServiceInvocationStatus GetResourceProperty response for polling request: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse . . . GetResourceProperty request for the result: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . . . . moby:ServiceInvocationResult GetResourceProperty response for requesting results: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse . . . . . . Request for destroying the resource: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rlw-2/ ImmediateResourceTermination/DestroyRequest . . . Response for destroying the resource: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rlw-2/ ImmediateResourceTermination/DestroyResponse . . . From gordonp at ucalgary.ca Mon Aug 28 10:04:08 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 28 Aug 2006 08:04:08 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44F072E9.5050206@ebi.ac.uk> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> Message-ID: <44F2F7D8.1050905@ucalgary.ca> I agree with Tom: the most important part of using a layer like WS is the features you *haven't* thought of. Logical separation of program parts always incurs an overhead, but 1) frees the developer from tinkering with a "solved" problem, and 2) allows him/her to benefit from features they hadn't anticipated. I'll be really happy when a security payer can be automagically added to MOBY via some WS protocol... With regards to Martin's mail, I don't think usurping the Service type is a good idea (if I understand the idea correctly, which I may not). The Service Type Ontology is supposed to describe the service in biological terms, the fact that it executes asynchronously is a technical consideration (imagine doubling the size of the ontology because one half has to inherit from moby-async :-P) . > Mark Wilkinson wrote: > >> v.v. the political statement: I strongly agree with Martin, in part, and >> somewhat agree with him in another part :-) >> >> My personal opinion on the Pseudo-Web Services approach that MOBY uses is >> that it has been more of a barrier than a benefit. I don't think this is >> a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the >> WS architecture itself is not quite as useful as it was marketed to be in >> past years. In this regard, moving toward a REST-style architecture for >> "MOBY 2" is something I am strongly in favour of because it seems like the >> right thing to do, especially in the emergent Semantic Web world; the fact >> that it also moves us closer to the S-MOBY architecture is just icing :-) >> > > One thing to consider here is that you're potentially missing out on the > additional capabilities you can inherit from a web service platform. I > tend to agree with both you and Martin on this (Martin has sat next to > me in an office for some years and so should know my generally low > opinion of the current state of the web service world!). > > Where WS can really come into their own is their ability to add aspects > such as security and robust message transport without any additional > effort from the MOBY community. It might be worth taking a look at the > work we've been doing with OMII-UK (the umbrella organization in the UK > which has in the last year absorbed both myGrid and OGSA-DAI). They > (we?) have a container configuration with support for WS-Security > (certificate based authentication) and will support its use in escience > projects. > > Use of WS 'standards' incurs a cost, both in initial development time > and in runtime complexity. It potentially reaps a benefit if you go on > to make use of the full suite (or a substantial subset) of additional > capabilities such as security, WSRF style session management, full > message description and the like. Before dropping WS invocation support > entirely you need to consider the potential future requirements that it > might fill more easily than a home grown implementation. There is of > course always the political aspect - we've already had people say "we > can't use taverna as, although it works and does what we want, it isn't > a 'standard'". Sad but true. > > This isn't an exclusive choice of course, you could (and maybe should) > have a simple REST-like invocation interface alongside a more complex > and potentially extensible SOAP based one. > > Just my thoughts, > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From senger at ebi.ac.uk Tue Aug 1 15:18:02 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 1 Aug 2006 16:18:02 +0100 (BST) Subject: [MOBY-dev] Announcement: Perl Moses released Message-ID: Dear Moby developers, especially if you are funs of $%@_ characters in your code. Talking about Perl, of course. Eddie and me, we created a project "Perl Moses" that does the same things for Perl developers as the MoSeS does for Java. Which means that it uses information stored in BioMoby registry (actually in the local cache) to generate Perl code that helps to implement BioMoby services (in Perl). Again the motto is: "Concentrate on the business logic and let Moses takes care about the XML and other horrible stuff." The code is released as an alpha version (numbered 0.8). As far as we know, it is working, but we desperately need your feedback. We will be fixing bugs as you find them. (Perhaps with some delay because in the next hour, I am heading to an airport flying to South America - not only for BOSC/ISMB but almost for two months. But the South America has an Internet connection, hasn't it? :-)) The best way is probably to browse its (almost finished) documentation at: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/PerlMoses.html. This is also the right place to thank Richard Bruskiewich and the whole Generation Challenge Programme and IRRI for supporting this project. Moses would not exist without GCP (wow, it sounds strange :-)). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Tue Aug 1 15:18:17 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 1 Aug 2006 17:18:17 +0200 Subject: [MOBY-dev] Moby services in Python Message-ID: Hi all, I was wondering if anybody is using Python to create Moby services. I am planning to make use of SOAPpy but I want to know if there is any limitation with this library that can make it not work with BioMOBY. Finally, is this the correct place to ask these kind of questions? Is there any other? Thanks. Javier. From gordonp at ucalgary.ca Tue Aug 1 15:54:44 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 01 Aug 2006 09:54:44 -0600 Subject: [MOBY-dev] Moby services in Python In-Reply-To: References: Message-ID: <44CF7944.3030606@ucalgary.ca> There is a Python tree within the MOBY CVS, but I believe the developers of the initial implementation are no longer actively working on it. It'd be a starting point for you though. I don't see offhand why there should be any technical limitation on interoperability... > Hi all, > > I was wondering if anybody is using Python to create Moby services. I > am planning to make use of SOAPpy but I want to know if there is any > limitation with this library that can make it not work with BioMOBY. > > Finally, is this the correct place to ask these kind of questions? Is > there any other? > > Thanks. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Tue Aug 1 16:39:25 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 01 Aug 2006 10:39:25 -0600 Subject: [MOBY-dev] Java Web Services: part 2 Message-ID: <44CF83BD.90103@ucalgary.ca> Hi all, I have just committed some new code for creating MOBY Java servlets. It's intended for Extremely Lazy Programmers (such as myself), requiring that you download just a particular WAR. No CVS, Axis, Ant, etc. required. Some of my coworkers who have never deployed an servlet, or knew anything about MOBY were able to have a registered, tested service within 30 minutes! Hopefully this will be of use to some of you too... http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html Regards, Paul From markw at illuminae.com Tue Aug 1 21:05:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 01 Aug 2006 14:05:02 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: Message-ID: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-08-01 at 17:18 +0200, Javier de la Torre wrote: > Finally, is this the correct place to ask these kind of questions? Is > there any other? Yes, this is the place to ask those kinds of questions :-) If you do use the Python files,could you please send a message to this list indicating the current state of those files. I don't think anyone really knows if they are functional or not...?? thanks! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From edward.kawas at gmail.com Tue Aug 1 22:20:28 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 1 Aug 2006 15:20:28 -0700 Subject: [MOBY-dev] RDF Agent Message-ID: <009701c6b5b8$b285f050$6700a8c0@notebook> Dear Service Providers, It brings us great pleasure to finally announce that the RDF agent will be placed on a cron job so that it can visit any and all of your registered services on mobycentral. For the next 2 months, the agent will be checking for invalid/dead services and only *reporting* them to the provider. No service will be removed by the agent at this time. However, changes in the service description that the agent encounters when comparing what it knows versus what you have in your document will be reflected in the registry. After the 2 month period, we will either enable the removal of 'dead' services or prolong the reporting of the dead services. Our decision will be based on your concerns and feedback and will be reported to this list. Our hopes are that service providers will use this time to generate RDF for their services and update the registration details for their services [http://mobycentral.icapture.ubc.ca:8090/servlets/forms/getSignatureForm]. Once your RDF has been generated, you can verify that the signatureURL has been set properly by looking for the URL in the RDF document. If you cannot find it, please contact us with the servicename/authority and we will look into the reasons why the URL failed to update. Please make sure to place the RDF document at the exact address that you specified when using the form. In addition to updating your services, please take the added step of testing the generated RDF [http://mobycentral.icapture.ubc.ca:8090/servlets/RDFAgent_test.html]. While testing, the agent will tell you whether your services are syntactically correct, and whether the agent can in fact read the remote RDF document. If the document can be read and services are found, the agent will describe your services. If you encounter any problems while generating the RDF, updating your services, or testing the agent, please post your concerns to the list so that we can solve your problems and that others can benefit from the solutions found. Thanks, Eddie From markw at illuminae.com Wed Aug 2 01:25:55 2006 From: markw at illuminae.com (mark wilkinson) Date: Wed, 2 Aug 2006 01:25:55 +0000 GMT Subject: [MOBY-dev] Remora Message-ID: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> Hi Remora developers! I have a quick question for you - before I say this in my manuscript can you confirm that you are using SCUFL "under the hood" in Remora? I'm guessing, but I don't know... The next iteration of gbrowse-moby (available tomorrow!) generates a SCUFL document while you browse, and I want to say that this document can then be loaded to Taverna AND Remora... But I'm not certain of that. Are any of the other clients using XSCUFL? Cheers! M -- Mark Wilkinson ...on the road! From jatorre at gmail.com Wed Aug 2 10:00:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 12:00:07 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, Good to hear from you. I have downloaded and I am testing it, I dont know if I will finally make use of it. I am working on providing moby support to PyWrapper (the first TAPIR implementation, remember?). The final goal is to make easy for data providers in the GCP context (and GBIF) to make their data available as a retrieval service for moby users. I have another question. If I remember correctly it was not possible to describe moby data types with XML Schema so I suspect it is not possible to generate WSDL files for most of the services. But I see that in the Python library that there is a retrieveServiceWSDL method. What kinf of WSDL can you generate if the inputs are not fixed? You generate your WSDL for what you expect and then you dont validate the input requests and try to process them? Finally, is there a registry, or part of it, where I can play registering data types? It is easy to register things but difficult to delete them and I do not want to leave my testing in the real registry. Thanks in advance. Javier. On 8/1/06, Mark Wilkinson wrote: > On Tue, 2006-08-01 at 17:18 +0200, Javier de la Torre wrote: > > > Finally, is this the correct place to ask these kind of questions? Is > > there any other? > > Yes, this is the place to ask those kinds of questions :-) > > If you do use the Python files,could you please send a message to this > list indicating the current state of those files. I don't think anyone > really knows if they are functional or not...?? > > thanks! > > Mark > > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From raulfdez at lcc.uma.es Wed Aug 2 10:40:47 2006 From: raulfdez at lcc.uma.es (=?iso-8859-1?Q?Ra=FAl_Fern=E1ndez-Santa_Cruz?=) Date: Wed, 2 Aug 2006 12:40:47 +0200 Subject: [MOBY-dev] Remora In-Reply-To: <00bf01c6b618$08e3b950$346dd696@ac.uma.es> Message-ID: <000001c6b620$1d9d88f0$0bd6d696@hyperion> Hello Mark, In INB we use Taverna to execute the SCUFL workflows. In next versions, we want to be able to execute workflows without Taverna, but using the workflows creates by Taverna. For this reason, we will have to be able to parser SCUFL. Regards, Ra?l. ----- Original Message ----- From: "mark wilkinson" To: Sent: Wednesday, August 02, 2006 3:25 AM Subject: [MOBY-dev] Remora > Hi Remora developers! > > I have a quick question for you - before I say this in my manuscript can you confirm that you are using SCUFL "under the hood" in Remora? I'm guessing, but I don't know... > > The next iteration of gbrowse-moby (available tomorrow!) generates a SCUFL document while you browse, and I want to say that this document can then be loaded to Taverna AND Remora... But I'm not certain of that. > > Are any of the other clients using XSCUFL? > > Cheers! > > M > > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Wed Aug 2 14:38:19 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 08:38:19 -0600 Subject: [MOBY-dev] Remora In-Reply-To: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> Message-ID: <44D0B8DB.4030203@ucalgary.ca> Hi Mark, Seahawk (http://moby.ucalgary.ca/seahawk/) can export SCUFL "macros" of your browsing history, using the save icon on the toolbar. It's a little flaky when you get exceptions from services though. > Are any of the other clients using XSCUFL? > > Cheers! > > M > > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Wed Aug 2 15:09:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:09:53 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0B8DB.4030203@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> Message-ID: <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > Hi Mark, > > Seahawk (http://moby.ucalgary.ca/seahawk/) I think you should have called it "Kingfisher", to accommodate both the MOBY "fishy" theme and the Sun COE "birdie" theme :-) M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Aug 2 15:10:19 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:10:19 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0B8DB.4030203@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> Message-ID: <1154531419.25149.15.camel@bioinfo.icapture.ubc.ca> Or "Pelican"... On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > Hi Mark, > > Seahawk (http://moby.ucalgary.ca/seahawk/) can export SCUFL "macros" of > your browsing history, using the save icon on the toolbar. It's a > little flaky when you get exceptions from services though. > > Are any of the other clients using XSCUFL? > > > > Cheers! > > > > M > > > > > > -- > > Mark Wilkinson > > ...on the road! > > _______________________________________________ > > 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 -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Aug 2 15:19:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:19:32 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> Message-ID: <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-08-02 at 12:00 +0200, Javier de la Torre wrote: > I have another question. If I remember correctly it was not possible > to describe moby data types with XML Schema so I suspect it is not > possible to generate WSDL files for most of the services. But I see > that in the Python library that there is a retrieveServiceWSDL method. > What kinf of WSDL can you generate if the inputs are not fixed? The WSDL contains rudimentary XML-Schema fragments in the input and output: so basically all it is saying is that the input and output are going to be blocks of XML. The structure of that XML is opaque to the SOAP libraries, but "visible" to the MOBY libraries that can do ontology- lookups. Unfortunately, there is no pyMoSeS - the MoSeS and Perl MoSeS libraries written by Martin Senger and Eddie Kawas create Java/Perl objects that can create/interpret the XML blocks of MOBY Objects. > Finally, is there a registry, or part of it, where I can play > registering data types? I believe there is a test registry for public "play" at: http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl URI: http://bioinfo.icapture.ubc.ca/MOBY/Central We're in the process of moving that machine physically inside of our institutional firewall (and it isn't going well!) so the that server may be up/down at various times over the next week or so until we figure out why we can't "see" it once it is inside. Let me know if you have problems with it. > It is easy to register things but difficult to > delete them and I do not want to leave my testing in the real > registry. Thanks for being considerate :-) :-) Best wishes! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 2 15:51:10 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 09:51:10 -0600 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D0C9EE.60005@ucalgary.ca> I'm way ahead of you, at the bottom of the Seahawk help page is an extended passage from Moby Dick with an episode about a sea-hawk. :-) > On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > >> Hi Mark, >> >> Seahawk (http://moby.ucalgary.ca/seahawk/) >> > > > I think you should have called it "Kingfisher", to accommodate both the > MOBY "fishy" theme and the Sun COE "birdie" theme :-) > > M > > > From markw at illuminae.com Wed Aug 2 15:52:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 08:52:48 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D0C9EE.60005@ucalgary.ca> References: <1169748000-1154481972-cardhu_blackberry.rim.net-17033-@engine08-cell01> <44D0B8DB.4030203@ucalgary.ca> <1154531394.25149.14.camel@bioinfo.icapture.ubc.ca> <44D0C9EE.60005@ucalgary.ca> Message-ID: <1154533968.25301.15.camel@bioinfo.icapture.ubc.ca> Doh! :-) M On Wed, 2006-08-02 at 09:51 -0600, Paul Gordon wrote: > I'm way ahead of you, at the bottom of the Seahawk help page is an > extended passage from Moby Dick with an episode about a sea-hawk. :-) > > On Wed, 2006-08-02 at 08:38 -0600, Paul Gordon wrote: > > > >> Hi Mark, > >> > >> Seahawk (http://moby.ucalgary.ca/seahawk/) > >> > > > > > > I think you should have called it "Kingfisher", to accommodate both the > > MOBY "fishy" theme and the Sun COE "birdie" theme :-) > > > > M > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Wed Aug 2 16:23:11 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 18:23:11 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi, > The WSDL contains rudimentary XML-Schema fragments in the input and > output: Ok, then is not ok for me, pity. > I believe there is a test registry for public "play" at: > > http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl Great! I will work there. Another question. Is it mandatory for a service to implement the multiple invocations funcionality? Thanks. Javier. From markw at illuminae.com Wed Aug 2 17:22:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 10:22:35 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> Message-ID: <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> > Is it mandatory for a service to implement the multiple invocations > funcionality? well.... It *may* be that the people working on the error-handling and error-codes have reserved an error code for providers who do not WANT to handle multiple invocations in a single message, but I don't think so... I think it is mandatory at the moment. M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 2 18:13:02 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 02 Aug 2006 12:13:02 -0600 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D0EB2E.7010406@ucalgary.ca> I have always been a champion of the multiple invocations requirement, and still am, for several reasons: 0. First we must acknowledge that people will want to run a bunch of data against a service. I do already, and many Taverna workflows do to (implicit iterators). 1. Some services may use hardware accelerator, which can perform 100 jobs as quick as 1 if they are submitted together. 2. If you have a cluster running the service, it is much easier to schedule 100 jobs efficiently than to receive 100 individual requests over the course of a few seconds. i.e. division of labour is much easier when you know in advance how much there is to do! 3. If your server is running 1 CPU, you can decide to run the 100 jobs sequentially, at the pace you like (especially if you have many requests coming in from different users at the same time). If the 100 jobs are submitted separately, it is the client (e.g. Taverna) that decides how much breathing room you have. Encouraging multiple-invocations-in-one-envelope may reduce inadvertent denial-of-service attacks. 4. The network and computational overhead is much smaller for 1 large request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet invocation vs. 100, etc. 5. It's not hard to implement! All you really need to do is add a for loop to the service code... MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html) supports multiple invocations implicitly, I don't even really tell the developer about it: their processRequest() method gets called for each mobyData block. My CAD 0.02, Paul >> Is it mandatory for a service to implement the multiple invocations >> funcionality? >> > > > well.... It *may* be that the people working on the error-handling and > error-codes have reserved an error code for providers who do not WANT to > handle multiple invocations in a single message, but I don't think so... > > I think it is mandatory at the moment. > > M > > > > From jatorre at gmail.com Wed Aug 2 19:36:06 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 21:36:06 +0200 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: <44D0EB2E.7010406@ucalgary.ca> References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> <44D0EB2E.7010406@ucalgary.ca> Message-ID: No, ok, fine... Is just that the software I am working on handle this thing in a different way... Our software is a retrieval service, it is actually a database wrapper. With the protocol it works if you want to retrieve several "objects", records, you do it by defining a query. Still I think it will be ok to transform this. But I am gonna have to implement some limitations on the number of invocations. If a user send my service 10.000 records I will not handle all of them because my service can easily die. In theory if all the requested objects are of the same type, what they must be because is one single service, I can transform it into a single SQL statement to retrieve all of them at once. If I have to lunch a different database query per object then I will be into troubles... Best regards, Javier. On 8/2/06, Paul Gordon wrote: > I have always been a champion of the multiple invocations requirement, > and still am, for several reasons: > > 0. First we must acknowledge that people will want to run a bunch of > data against a service. I do already, and many Taverna workflows do to > (implicit iterators). > > 1. Some services may use hardware accelerator, which can perform 100 > jobs as quick as 1 if they are submitted together. > > 2. If you have a cluster running the service, it is much easier to > schedule 100 jobs efficiently than to receive 100 individual requests > over the course of a few seconds. i.e. division of labour is much > easier when you know in advance how much there is to do! > > 3. If your server is running 1 CPU, you can decide to run the 100 jobs > sequentially, at the pace you like (especially if you have many requests > coming in from different users at the same time). If the 100 jobs are > submitted separately, it is the client (e.g. Taverna) that decides how > much breathing room you have. Encouraging > multiple-invocations-in-one-envelope may reduce inadvertent > denial-of-service attacks. > > 4. The network and computational overhead is much smaller for 1 large > request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet > invocation vs. 100, etc. > > 5. It's not hard to implement! All you really need to do is add a for > loop to the service code... MobyServlet > (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html) > supports multiple invocations implicitly, I don't even really tell the > developer about it: their processRequest() method gets called for each > mobyData block. > > My CAD 0.02, > > Paul > >> Is it mandatory for a service to implement the multiple invocations > >> funcionality? > >> > > > > > > well.... It *may* be that the people working on the error-handling and > > error-codes have reserved an error code for providers who do not WANT to > > handle multiple invocations in a single message, but I don't think so... > > > > I think it is mandatory at the moment. > > > > M > > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From jatorre at gmail.com Wed Aug 2 17:48:05 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 2 Aug 2006 19:48:05 +0200 Subject: [MOBY-dev] License of Python libraries in the MOBY CVS Message-ID: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Hi, I am definitely going to use bioMoby-python. The part for interacting with moby-central works fine with me and I do not want to rewrite it myself. But, I would like to embed it into my software for distribution. I haven't seen a license together with the software, any idea on how is this software licensed? Would be ok to redistributed? With proper credits of course! Thanks. Javier. From markw at illuminae.com Wed Aug 2 20:05:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 13:05:22 -0700 Subject: [MOBY-dev] [moby] Moby services in Python In-Reply-To: References: <1154466302.7179.12.camel@bioinfo.icapture.ubc.ca> <1154531972.25253.5.camel@bioinfo.icapture.ubc.ca> <1154539356.30990.1.camel@bioinfo.icapture.ubc.ca> <44D0EB2E.7010406@ucalgary.ca> Message-ID: On Wed, 02 Aug 2006 12:36:06 -0700, Javier de la Torre wrote: > In theory if all the requested objects are of the same type, what they > must be because is one single service, I can transform it into a > single SQL statement to retrieve all of them at once. This is pretty much what Paul was saying - the optimization of answerig the request can be controlled by the service provider if all requests come in a single message. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From markw at illuminae.com Wed Aug 2 21:45:14 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Aug 2006 14:45:14 -0700 Subject: [MOBY-dev] MOBY License In-Reply-To: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> References: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Message-ID: I have only added a license to "my own" branch of the codebase - the Perl folder. The Perl code is released under the Perl Artistic License. I suspect that you wont get any objection from any of the other developers if you want to redistribute, but it would probably be a good idea to come to a unanimous decision on the license for the entire CVS. Do any developers object to applying the PAL to *all* parts of the MOBY CVS? M On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre wrote: > Hi, > > I am definitely going to use bioMoby-python. The part for interacting > with moby-central works fine with me and I do not want to rewrite it > myself. > > But, I would like to embed it into my software for distribution. I > haven't seen a license together with the software, any idea on how is > this software licensed? > Would be ok to redistributed? With proper credits of course! > > Thanks. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From gordonp at ucalgary.ca Thu Aug 3 13:29:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 07:29:43 -0600 Subject: [MOBY-dev] MOBY License In-Reply-To: References: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC@gmail.com> Message-ID: <44D1FA47.9020009@ucalgary.ca> I think the Perl Artistic License is a fine one. I had actually assumed that it applied to the whole CVS already :-) > I have only added a license to "my own" branch of the codebase - the Perl > folder. The Perl code is released under the Perl Artistic License. > > I suspect that you wont get any objection from any of the other developers > if you want to redistribute, but it would probably be a good idea to come > to a unanimous decision on the license for the entire CVS. > > Do any developers object to applying the PAL to *all* parts of the MOBY > CVS? > > M > > > > > > On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre > wrote: > > >> Hi, >> >> I am definitely going to use bioMoby-python. The part for interacting >> with moby-central works fine with me and I do not want to rewrite it >> myself. >> >> But, I would like to embed it into my software for distribution. I >> haven't seen a license together with the software, any idea on how is >> this software licensed? >> Would be ok to redistributed? With proper credits of course! >> >> Thanks. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > > From Sebastien.Carrere at toulouse.inra.fr Thu Aug 3 16:12:24 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 03 Aug 2006 18:12:24 +0200 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <002701c6b685$137ecae0$756fa8c0@notebook> References: <002701c6b685$137ecae0$756fa8c0@notebook> Message-ID: <44D22068.1010802@toulouse.inra.fr> Hi Mark and Eddie, I flip this discussion onto the mailing list :-[ The lack of XSCUFL specifications is a real problem for us. The only one I have been able to find is a 2 years old one (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) Nevertheless, I can start to develop a Remora/XSCUFL adapter at this time, using the template sent by Eddie to deal with secondaryArticles. By this way, we could provide Remora user the possibility to download/upload their workflow in "current" XSCUFL format. Cordialement, Sebastien Ed Kawas a ?crit : > Hi, > > I represent secondarys like the following: > parameterValue > > Where 'parameterName' is the articlename for the secondary parameter and the > 'parameterValue' is the value. > > For example: > > some description > > > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > getUniprotIdentifierByGeneName > bioinfo.icapture.ubc.ca > human > > > > > This is how it is done in Taverna. > > Eddie > >> -----Original Message----- >> From: Mark Wilkinson [mailto:markw at illuminae.com] >> Sent: Wednesday, August 02, 2006 3:36 PM >> To: Sebastien Carrere >> Cc: GOUZY J?rome; Eddie Kawas >> Subject: Re: [moby] Re: [MOBY-dev] Remora >> >> Hi Sebastien, >> >> I've spoken with Eddie and he is able to represent >> SecondaryArticles in SCUFL, at least for Taverna. By the >> sounds of it, SCUFL is relatively undefined (I can't find any >> documentation for the language anywhere) and in Taverna >> apparently you are allowed to specify your own SCUFL tags, >> and declare how they should be parsed, so it's more or less >> wide-open to be extended. >> >> So... we represent Secondary parameters in SCUFL, and they >> can be interpreted by Taverna; however since there is no >> definition of the SCUFL language anywhere that we can find, >> we are certain that (at the >> moment) only Taverna can handle these new secondary parameter >> tags. My feeling is that, from the perspective of Taverna, >> all inputs are identical, so they haven't created different >> port types for secondaries vs. primaries as we require for MOBY. >> >> Eddie will tell you more - I have c.c.'d him this message. >> >> It's probably a good idea to flip this conversation onto the >> mailing list, but I don't want to send your message to the >> list without your permission :-) If you want to c.c. the >> list with your response that would be great! >> >> Cheers! >> >> Mark >> >> >> >> >> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >> >>> Bonjour Mark, >>> >>> Remora is not yet SCUFLized. >>> When we started our project, the problem with SCUFL is that >>> >> it did not >> >>> deal with SecondaryArticles ... >>> For us it was a critic. >>> >>> So, my question is : " is SCUFL deals with >>> >> moby:SecondaryArticles now ?". >> >>> If th answer is yes, I can write a parser SCUFL <-> >>> RemoraWorkflowsDescription. >>> If no, maybe I can also write it but with loss of information ... >>> >>> Sincerely, >>> >>> Sebastien. >>> >>> mark wilkinson a ?crit : >>> >>>> Hi Remora developers! >>>> >>>> I have a quick question for you - before I say this in my >>>> >> manuscript can you confirm that you are using SCUFL "under >> the hood" in Remora? I'm guessing, but I don't know... >> >>>> The next iteration of gbrowse-moby (available tomorrow!) >>>> >> generates a SCUFL document while you browse, and I want to >> say that this document can then be loaded to Taverna AND >> Remora... But I'm not certain of that. >> >>>> Are any of the other clients using XSCUFL? >>>> >>>> Cheers! >>>> >>>> M >>>> >>>> >>>> -- >>>> Mark Wilkinson >>>> ...on the road! >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics University of >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >> Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of >> a term to >> someone who is unfamiliar with its proper application, the >> use of language that doesn't help such a person learn how to >> apply the term is pointless. Thus, "happiness is a warm >> puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Thu Aug 3 16:28:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Aug 2006 09:28:58 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D22068.1010802@toulouse.inra.fr> References: <002701c6b685$137ecae0$756fa8c0@notebook> <44D22068.1010802@toulouse.inra.fr> Message-ID: <1154622538.15856.0.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: > http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) wow! I searched for ages and couldn't find that! Well... it's a start :-) M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Thu Aug 3 16:31:44 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Aug 2006 09:31:44 -0700 Subject: [MOBY-dev] [moby] Re: Remora In-Reply-To: <44D22068.1010802@toulouse.inra.fr> References: <002701c6b685$137ecae0$756fa8c0@notebook> <44D22068.1010802@toulouse.inra.fr> Message-ID: <1154622704.15856.2.camel@bioinfo.icapture.ubc.ca> "The language itself should be considered volatile, any users of it should join the taverna developers list and monitor it, we do not support this language for use outside of Taverna." LOL! Well, Tom, when you build something this useful, you can't expect people not to use it! M On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: > Hi Mark and Eddie, > > I flip this discussion onto the mailing list :-[ > > The lack of XSCUFL specifications is a real problem for us. > The only one I have been able to find is a 2 years old one > (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > Nevertheless, I can start to develop a Remora/XSCUFL adapter at this > time, using the template sent by Eddie to deal with secondaryArticles. > > By this way, we could provide Remora user the possibility to > download/upload their workflow in "current" XSCUFL format. > > Cordialement, > > Sebastien > > Ed Kawas a ?crit : > > Hi, > > > > I represent secondarys like the following: > > parameterValue > > > > Where 'parameterName' is the articlename for the secondary parameter and the > > 'parameterValue' is the value. > > > > For example: > > > > some description > > > > > > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl > > > > getUniprotIdentifierByGeneName > > bioinfo.icapture.ubc.ca > > human > > > > > > > > > > This is how it is done in Taverna. > > > > Eddie > > > >> -----Original Message----- > >> From: Mark Wilkinson [mailto:markw at illuminae.com] > >> Sent: Wednesday, August 02, 2006 3:36 PM > >> To: Sebastien Carrere > >> Cc: GOUZY J?rome; Eddie Kawas > >> Subject: Re: [moby] Re: [MOBY-dev] Remora > >> > >> Hi Sebastien, > >> > >> I've spoken with Eddie and he is able to represent > >> SecondaryArticles in SCUFL, at least for Taverna. By the > >> sounds of it, SCUFL is relatively undefined (I can't find any > >> documentation for the language anywhere) and in Taverna > >> apparently you are allowed to specify your own SCUFL tags, > >> and declare how they should be parsed, so it's more or less > >> wide-open to be extended. > >> > >> So... we represent Secondary parameters in SCUFL, and they > >> can be interpreted by Taverna; however since there is no > >> definition of the SCUFL language anywhere that we can find, > >> we are certain that (at the > >> moment) only Taverna can handle these new secondary parameter > >> tags. My feeling is that, from the perspective of Taverna, > >> all inputs are identical, so they haven't created different > >> port types for secondaries vs. primaries as we require for MOBY. > >> > >> Eddie will tell you more - I have c.c.'d him this message. > >> > >> It's probably a good idea to flip this conversation onto the > >> mailing list, but I don't want to send your message to the > >> list without your permission :-) If you want to c.c. the > >> list with your response that would be great! > >> > >> Cheers! > >> > >> Mark > >> > >> > >> > >> > >> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: > >> > >>> Bonjour Mark, > >>> > >>> Remora is not yet SCUFLized. > >>> When we started our project, the problem with SCUFL is that > >>> > >> it did not > >> > >>> deal with SecondaryArticles ... > >>> For us it was a critic. > >>> > >>> So, my question is : " is SCUFL deals with > >>> > >> moby:SecondaryArticles now ?". > >> > >>> If th answer is yes, I can write a parser SCUFL <-> > >>> RemoraWorkflowsDescription. > >>> If no, maybe I can also write it but with loss of information ... > >>> > >>> Sincerely, > >>> > >>> Sebastien. > >>> > >>> mark wilkinson a ?crit : > >>> > >>>> Hi Remora developers! > >>>> > >>>> I have a quick question for you - before I say this in my > >>>> > >> manuscript can you confirm that you are using SCUFL "under > >> the hood" in Remora? I'm guessing, but I don't know... > >> > >>>> The next iteration of gbrowse-moby (available tomorrow!) > >>>> > >> generates a SCUFL document while you browse, and I want to > >> say that this document can then be loaded to Taverna AND > >> Remora... But I'm not certain of that. > >> > >>>> Are any of the other clients using XSCUFL? > >>>> > >>>> Cheers! > >>>> > >>>> M > >>>> > >>>> > >>>> -- > >>>> Mark Wilkinson > >>>> ...on the road! > >>>> _______________________________________________ > >>>> MOBY-dev mailing list > >>>> MOBY-dev at lists.open-bio.org > >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev > >>>> > >>>> > >>>> > >> -- > >> Mark Wilkinson > >> Asst. Professor, Dept. of Medical Genetics University of > >> British Columbia PI in Bioinformatics, iCAPTURE Centre St. > >> Paul's Hospital, Rm. 166, 1081 Burrard St. > >> Vancouver, BC, V6Z 1Y6 > >> tel: 604 682 2344 x62129 > >> fax: 604 806 9274 > >> > >> "Since the point of a definition is to explain the meaning of > >> a term to > >> someone who is unfamiliar with its proper application, the > >> use of language that doesn't help such a person learn how to > >> apply the term is pointless. Thus, "happiness is a warm > >> puppy" may be a lovely thought, > >> but it is a lousy definition." > >> > >> K?hler et al, 2006 > >> > >> > > > > > > > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Thu Aug 3 16:32:00 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 3 Aug 2006 13:32:00 -0300 Subject: [MOBY-dev] RDF Agent In-Reply-To: <009701c6b5b8$b285f050$6700a8c0@notebook> References: <009701c6b5b8$b285f050$6700a8c0@notebook> Message-ID: <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> I see there may be a small inconvenience. It may be solved using seveal scenarios, but I am not sure which way to go. The inconvenience I am talking about is for the Moses users/developers. In order to create a service implementation, the service must be registered. But when somebody registers a service, it does not exist yet, so its endpoint is a fake endpoint. And there will be always a time delay between registering the service and making it runnable. How would you suggest to solve this (if we want to solve it all, of course). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Thu Aug 3 18:30:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 12:30:43 -0600 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> Message-ID: <44D240D3.30408@ucalgary.ca> Perhaps to solve the issue, we should know why it needs to be registered before it's implemented? Martin Senger wrote: > I see there may be a small inconvenience. It may be solved using seveal > scenarios, but I am not sure which way to go. > > The inconvenience I am talking about is for the Moses users/developers. In > order to create a service implementation, the service must be registered. > But when somebody registers a service, it does not exist yet, so its > endpoint is a fake endpoint. And there will be always a time delay between > registering the service and making it runnable. > > How would you suggest to solve this (if we want to solve it all, of course). > > Martin > > From yan.wong at free.fr Thu Aug 3 18:14:05 2006 From: yan.wong at free.fr (Yan Wong) Date: Thu, 3 Aug 2006 20:14:05 +0200 Subject: [MOBY-dev] MOBY-dev Digest, Vol 44, Issue 3 In-Reply-To: References: Message-ID: <359AA0B6-BD85-4862-A859-B71CA1013EE8@free.fr> Hello everybody, I reply to the question about the licence of the bioMoby Python code: I didn't put any licence like GPL, LGPL or other BSD licences in it. At the time, I was SO busy with the technical and functionalities of the client interface that I totally forgot the licence... It is a mistake so please apologize. Can someone put the same licence as for the Perl interface? Thus it would clear my mistake. I am pretty busy at Accenture with SAP projects. However, if you still have question on how the Python interface work, I would be happy to answer questions (but don't expect quick answers). I wrote documentation for the code but you'll agree that it need to be rewritten and augmented. Cheers, Yan Wong Le 3 ao?t 06 ? 18:31, moby-dev-request at lists.open-bio.org a ?crit : > Send MOBY-dev mailing list submissions to > moby-dev at lists.open-bio.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.open-bio.org/mailman/listinfo/moby-dev > or, via email, send a message with subject or body 'help' to > moby-dev-request at lists.open-bio.org > > You can reach the person managing the list at > moby-dev-owner at lists.open-bio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MOBY-dev digest..." > > > Today's Topics: > > 1. Re: [moby] Moby services in Python (Javier de la Torre) > 2. License of Python libraries in the MOBY CVS (Javier de la Torre) > 3. Re: [moby] Moby services in Python (Mark Wilkinson) > 4. MOBY License (Mark Wilkinson) > 5. Re: MOBY License (Paul Gordon) > 6. Re: [moby] Re: Remora (Sebastien Carrere) > 7. Re: [moby] Re: Remora (Mark Wilkinson) > 8. Re: [moby] Re: Remora (Mark Wilkinson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Aug 2006 21:36:06 +0200 > From: "Javier de la Torre" > Subject: Re: [MOBY-dev] [moby] Moby services in Python > To: "Core developer announcements" > Cc: markw at illuminae.com > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > No, ok, fine... > > Is just that the software I am working on handle this thing in a > different way... > Our software is a retrieval service, it is actually a database > wrapper. With the protocol it works if you want to retrieve several > "objects", records, you do it by defining a query. > > Still I think it will be ok to transform this. But I am gonna have to > implement some limitations on the number of invocations. If a user > send my service 10.000 records I will not handle all of them because > my service can easily die. > > In theory if all the requested objects are of the same type, what they > must be because is one single service, I can transform it into a > single SQL statement to retrieve all of them at once. If I have to > lunch a different database query per object then I will be into > troubles... > > Best regards, > > Javier. > > > On 8/2/06, Paul Gordon wrote: >> I have always been a champion of the multiple invocations >> requirement, >> and still am, for several reasons: >> >> 0. First we must acknowledge that people will want to run a bunch of >> data against a service. I do already, and many Taverna workflows >> do to >> (implicit iterators). >> >> 1. Some services may use hardware accelerator, which can perform 100 >> jobs as quick as 1 if they are submitted together. >> >> 2. If you have a cluster running the service, it is much easier to >> schedule 100 jobs efficiently than to receive 100 individual requests >> over the course of a few seconds. i.e. division of labour is much >> easier when you know in advance how much there is to do! >> >> 3. If your server is running 1 CPU, you can decide to run the 100 >> jobs >> sequentially, at the pace you like (especially if you have many >> requests >> coming in from different users at the same time). If the 100 jobs >> are >> submitted separately, it is the client (e.g. Taverna) that decides >> how >> much breathing room you have. Encouraging >> multiple-invocations-in-one-envelope may reduce inadvertent >> denial-of-service attacks. >> >> 4. The network and computational overhead is much smaller for 1 large >> request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet >> invocation vs. 100, etc. >> >> 5. It's not hard to implement! All you really need to do is add a >> for >> loop to the service code... MobyServlet >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/ >> deployingServices.html) >> supports multiple invocations implicitly, I don't even really tell >> the >> developer about it: their processRequest() method gets called for >> each >> mobyData block. >> >> My CAD 0.02, >> >> Paul >>>> Is it mandatory for a service to implement the multiple invocations >>>> funcionality? >>>> >>> >>> >>> well.... It *may* be that the people working on the error- >>> handling and >>> error-codes have reserved an error code for providers who do not >>> WANT to >>> handle multiple invocations in a single message, but I don't >>> think so... >>> >>> I think it is mandatory at the moment. >>> >>> M >>> >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Aug 2006 19:48:05 +0200 > From: Javier de la Torre > Subject: [MOBY-dev] License of Python libraries in the MOBY CVS > To: Core developer announcements > Message-ID: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC at gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Hi, > > I am definitely going to use bioMoby-python. The part for interacting > with moby-central works fine with me and I do not want to rewrite it > myself. > > But, I would like to embed it into my software for distribution. I > haven't seen a license together with the software, any idea on how is > this software licensed? > Would be ok to redistributed? With proper credits of course! > > Thanks. > > Javier. > > > ------------------------------ > > Message: 3 > Date: Wed, 02 Aug 2006 13:05:22 -0700 > From: "Mark Wilkinson" > Subject: Re: [MOBY-dev] [moby] Moby services in Python > To: "Core developer announcements" > Message-ID: > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > On Wed, 02 Aug 2006 12:36:06 -0700, Javier de la Torre > > wrote: > > >> In theory if all the requested objects are of the same type, what >> they >> must be because is one single service, I can transform it into a >> single SQL statement to retrieve all of them at once. > > This is pretty much what Paul was saying - the optimization of > answerig > the request can be controlled by the service provider if all > requests come > in a single message. > > M > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > > > ------------------------------ > > Message: 4 > Date: Wed, 02 Aug 2006 14:45:14 -0700 > From: "Mark Wilkinson" > Subject: [MOBY-dev] MOBY License > To: "Core developer announcements" > Message-ID: > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > I have only added a license to "my own" branch of the codebase - > the Perl > folder. The Perl code is released under the Perl Artistic License. > > I suspect that you wont get any objection from any of the other > developers > if you want to redistribute, but it would probably be a good idea > to come > to a unanimous decision on the license for the entire CVS. > > Do any developers object to applying the PAL to *all* parts of the > MOBY > CVS? > > M > > > > > > On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre > > wrote: > >> Hi, >> >> I am definitely going to use bioMoby-python. The part for interacting >> with moby-central works fine with me and I do not want to rewrite it >> myself. >> >> But, I would like to embed it into my software for distribution. I >> haven't seen a license together with the software, any idea on how is >> this software licensed? >> Would be ok to redistributed? With proper credits of course! >> >> Thanks. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > > > ------------------------------ > > Message: 5 > Date: Thu, 03 Aug 2006 07:29:43 -0600 > From: Paul Gordon > Subject: Re: [MOBY-dev] MOBY License > To: Core developer announcements > Message-ID: <44D1FA47.9020009 at ucalgary.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I think the Perl Artistic License is a fine one. I had actually > assumed > that it applied to the whole CVS already :-) >> I have only added a license to "my own" branch of the codebase - >> the Perl >> folder. The Perl code is released under the Perl Artistic License. >> >> I suspect that you wont get any objection from any of the other >> developers >> if you want to redistribute, but it would probably be a good idea >> to come >> to a unanimous decision on the license for the entire CVS. >> >> Do any developers object to applying the PAL to *all* parts of the >> MOBY >> CVS? >> >> M >> >> >> >> >> >> On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre >> >> wrote: >> >> >>> Hi, >>> >>> I am definitely going to use bioMoby-python. The part for >>> interacting >>> with moby-central works fine with me and I do not want to rewrite it >>> myself. >>> >>> But, I would like to embed it into my software for distribution. I >>> haven't seen a license together with the software, any idea on >>> how is >>> this software licensed? >>> Would be ok to redistributed? With proper credits of course! >>> >>> Thanks. >>> >>> Javier. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> >> >> > > > > ------------------------------ > > Message: 6 > Date: Thu, 03 Aug 2006 18:12:24 +0200 > From: Sebastien Carrere > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: moby-dev at lists.open-bio.org > Cc: Ed Kawas , markw at illuminae.com > Message-ID: <44D22068.1010802 at toulouse.inra.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Mark and Eddie, > > I flip this discussion onto the mailing list :-[ > > The lack of XSCUFL specifications is a real problem for us. > The only one I have been able to find is a 2 years old one > (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > Nevertheless, I can start to develop a Remora/XSCUFL adapter at this > time, using the template sent by Eddie to deal with > secondaryArticles. > > By this way, we could provide Remora user the possibility to > download/upload their workflow in "current" XSCUFL format. > > Cordialement, > > Sebastien > > Ed Kawas a ?crit : >> Hi, >> >> I represent secondarys like the following: >> parameterValue >> >> Where 'parameterName' is the articlename for the secondary >> parameter and the >> 'parameterValue' is the value. >> >> For example: >> >> some description >> >> >> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/ >> mobycentral.pl >> >> getUniprotIdentifierByGeneName >> bioinfo.icapture.ubc.ca >> human >> >> >> >> >> This is how it is done in Taverna. >> >> Eddie >> >>> -----Original Message----- >>> From: Mark Wilkinson [mailto:markw at illuminae.com] >>> Sent: Wednesday, August 02, 2006 3:36 PM >>> To: Sebastien Carrere >>> Cc: GOUZY J?rome; Eddie Kawas >>> Subject: Re: [moby] Re: [MOBY-dev] Remora >>> >>> Hi Sebastien, >>> >>> I've spoken with Eddie and he is able to represent >>> SecondaryArticles in SCUFL, at least for Taverna. By the >>> sounds of it, SCUFL is relatively undefined (I can't find any >>> documentation for the language anywhere) and in Taverna >>> apparently you are allowed to specify your own SCUFL tags, >>> and declare how they should be parsed, so it's more or less >>> wide-open to be extended. >>> >>> So... we represent Secondary parameters in SCUFL, and they >>> can be interpreted by Taverna; however since there is no >>> definition of the SCUFL language anywhere that we can find, >>> we are certain that (at the >>> moment) only Taverna can handle these new secondary parameter >>> tags. My feeling is that, from the perspective of Taverna, >>> all inputs are identical, so they haven't created different >>> port types for secondaries vs. primaries as we require for MOBY. >>> >>> Eddie will tell you more - I have c.c.'d him this message. >>> >>> It's probably a good idea to flip this conversation onto the >>> mailing list, but I don't want to send your message to the >>> list without your permission :-) If you want to c.c. the >>> list with your response that would be great! >>> >>> Cheers! >>> >>> Mark >>> >>> >>> >>> >>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >>> >>>> Bonjour Mark, >>>> >>>> Remora is not yet SCUFLized. >>>> When we started our project, the problem with SCUFL is that >>>> >>> it did not >>> >>>> deal with SecondaryArticles ... >>>> For us it was a critic. >>>> >>>> So, my question is : " is SCUFL deals with >>>> >>> moby:SecondaryArticles now ?". >>> >>>> If th answer is yes, I can write a parser SCUFL <-> >>>> RemoraWorkflowsDescription. >>>> If no, maybe I can also write it but with loss of information ... >>>> >>>> Sincerely, >>>> >>>> Sebastien. >>>> >>>> mark wilkinson a ?crit : >>>> >>>>> Hi Remora developers! >>>>> >>>>> I have a quick question for you - before I say this in my >>>>> >>> manuscript can you confirm that you are using SCUFL "under >>> the hood" in Remora? I'm guessing, but I don't know... >>> >>>>> The next iteration of gbrowse-moby (available tomorrow!) >>>>> >>> generates a SCUFL document while you browse, and I want to >>> say that this document can then be loaded to Taverna AND >>> Remora... But I'm not certain of that. >>> >>>>> Are any of the other clients using XSCUFL? >>>>> >>>>> Cheers! >>>>> >>>>> M >>>>> >>>>> >>>>> -- >>>>> Mark Wilkinson >>>>> ...on the road! >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at lists.open-bio.org >>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics University of >>> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >>> Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of >>> a term to >>> someone who is unfamiliar with its proper application, the >>> use of language that doesn't help such a person learn how to >>> apply the term is pointless. Thus, "happiness is a warm >>> puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> >> >> >> > > -- > __________________________________________________________ > > Sebastien CARRERE LIPM (INRA-CNRS) > B.P.52627 -- 31326 CASTANET TOLOSAN > tel:(33) 5-61-28-53-29 > fax:(33) 5-61-28-50-61 > > > > > ------------------------------ > > Message: 7 > Date: Thu, 03 Aug 2006 09:28:58 -0700 > From: Mark Wilkinson > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: Core developer announcements > Message-ID: <1154622538.15856.0.camel at bioinfo.icapture.ubc.ca> > Content-Type: text/plain; charset=utf-8 > > On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: >> http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) > > wow! I searched for ages and couldn't find that! > > Well... it's a start :-) > > M > > > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K? > hler et al, 2006 > > > > ------------------------------ > > Message: 8 > Date: Thu, 03 Aug 2006 09:31:44 -0700 > From: Mark Wilkinson > Subject: Re: [MOBY-dev] [moby] Re: Remora > To: Core developer announcements > Message-ID: <1154622704.15856.2.camel at bioinfo.icapture.ubc.ca> > Content-Type: text/plain; charset=utf-8 > > "The language itself should be considered volatile, any users of it > should join the taverna developers list and monitor it, we do not > support this language for use outside of Taverna." > > LOL! Well, Tom, when you build something this useful, you can't > expect > people not to use it! > > M > > > > > On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote: >> Hi Mark and Eddie, >> >> I flip this discussion onto the mailing list :-[ >> >> The lack of XSCUFL specifications is a real problem for us. >> The only one I have been able to find is a 2 years old one >> (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html) >> >> Nevertheless, I can start to develop a Remora/XSCUFL adapter at this >> time, using the template sent by Eddie to deal with >> secondaryArticles. >> >> By this way, we could provide Remora user the possibility to >> download/upload their workflow in "current" XSCUFL format. >> >> Cordialement, >> >> Sebastien >> >> Ed Kawas a ?crit : >>> Hi, >>> >>> I represent secondarys like the following: >>> parameterValue >>> >>> Where 'parameterName' is the articlename for the secondary >>> parameter and the >>> 'parameterValue' is the value. >>> >>> For example: >>> >>> some description >>> >>> >>> http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/ >>> mobycentral.pl >>> >>> getUniprotIdentifierByGeneName >>> bioinfo.icapture.ubc.ca >>> human >>> >>> >>> >>> >>> This is how it is done in Taverna. >>> >>> Eddie >>> >>>> -----Original Message----- >>>> From: Mark Wilkinson [mailto:markw at illuminae.com] >>>> Sent: Wednesday, August 02, 2006 3:36 PM >>>> To: Sebastien Carrere >>>> Cc: GOUZY J?rome; Eddie Kawas >>>> Subject: Re: [moby] Re: [MOBY-dev] Remora >>>> >>>> Hi Sebastien, >>>> >>>> I've spoken with Eddie and he is able to represent >>>> SecondaryArticles in SCUFL, at least for Taverna. By the >>>> sounds of it, SCUFL is relatively undefined (I can't find any >>>> documentation for the language anywhere) and in Taverna >>>> apparently you are allowed to specify your own SCUFL tags, >>>> and declare how they should be parsed, so it's more or less >>>> wide-open to be extended. >>>> >>>> So... we represent Secondary parameters in SCUFL, and they >>>> can be interpreted by Taverna; however since there is no >>>> definition of the SCUFL language anywhere that we can find, >>>> we are certain that (at the >>>> moment) only Taverna can handle these new secondary parameter >>>> tags. My feeling is that, from the perspective of Taverna, >>>> all inputs are identical, so they haven't created different >>>> port types for secondaries vs. primaries as we require for MOBY. >>>> >>>> Eddie will tell you more - I have c.c.'d him this message. >>>> >>>> It's probably a good idea to flip this conversation onto the >>>> mailing list, but I don't want to send your message to the >>>> list without your permission :-) If you want to c.c. the >>>> list with your response that would be great! >>>> >>>> Cheers! >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote: >>>> >>>>> Bonjour Mark, >>>>> >>>>> Remora is not yet SCUFLized. >>>>> When we started our project, the problem with SCUFL is that >>>>> >>>> it did not >>>> >>>>> deal with SecondaryArticles ... >>>>> For us it was a critic. >>>>> >>>>> So, my question is : " is SCUFL deals with >>>>> >>>> moby:SecondaryArticles now ?". >>>> >>>>> If th answer is yes, I can write a parser SCUFL <-> >>>>> RemoraWorkflowsDescription. >>>>> If no, maybe I can also write it but with loss of information ... >>>>> >>>>> Sincerely, >>>>> >>>>> Sebastien. >>>>> >>>>> mark wilkinson a ?crit : >>>>> >>>>>> Hi Remora developers! >>>>>> >>>>>> I have a quick question for you - before I say this in my >>>>>> >>>> manuscript can you confirm that you are using SCUFL "under >>>> the hood" in Remora? I'm guessing, but I don't know... >>>> >>>>>> The next iteration of gbrowse-moby (available tomorrow!) >>>>>> >>>> generates a SCUFL document while you browse, and I want to >>>> say that this document can then be loaded to Taverna AND >>>> Remora... But I'm not certain of that. >>>> >>>>>> Are any of the other clients using XSCUFL? >>>>>> >>>>>> Cheers! >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>> -- >>>>>> Mark Wilkinson >>>>>> ...on the road! >>>>>> _______________________________________________ >>>>>> MOBY-dev mailing list >>>>>> MOBY-dev at lists.open-bio.org >>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>>>> >>>>>> >>>>>> >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor, Dept. of Medical Genetics University of >>>> British Columbia PI in Bioinformatics, iCAPTURE Centre St. >>>> Paul's Hospital, Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "Since the point of a definition is to explain the meaning of >>>> a term to >>>> someone who is unfamiliar with its proper application, the >>>> use of language that doesn't help such a person learn how to >>>> apply the term is pointless. Thus, "happiness is a warm >>>> puppy" may be a lovely thought, >>>> but it is a lousy definition." >>>> >>>> K?hler et al, 2006 >>>> >>>> >>> >>> >>> >> > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K? > hler et al, 2006 > > > > ------------------------------ > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > End of MOBY-dev Digest, Vol 44, Issue 3 > *************************************** > From gordonp at ucalgary.ca Thu Aug 3 21:03:09 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 03 Aug 2006 15:03:09 -0600 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> <44D240D3.30408@ucalgary.ca> <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> Message-ID: <44D2648D.7030300@ucalgary.ca> Perhaps then you can create that information locally first to avoid the chicken-egg issue? Registering is that last thing I do when I use MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html). In fact, MobyServlet will not let a service be registered unless it passes a live test... My CAD0.02 :-) >> Perhaps to solve the issue, we should know why it needs to be registered >> before it's implemented? >> > > > That' easy: because Moses is using information registered. > Martin > > > From martin.senger at gmail.com Thu Aug 3 18:58:41 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 3 Aug 2006 15:58:41 -0300 Subject: [MOBY-dev] [MOBY-l] RDF Agent In-Reply-To: <44D240D3.30408@ucalgary.ca> References: <009701c6b5b8$b285f050$6700a8c0@notebook> <4d93f07c0608030931s37f09643k13fda711570394da@mail.gmail.com> <44D240D3.30408@ucalgary.ca> Message-ID: <4d93f07c0608031158k55e4b469j3c2b3b0a09e43f74@mail.gmail.com> > Perhaps to solve the issue, we should know why it needs to be registered > before it's implemented? That' easy: because Moses is using information registered. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Aug 4 16:50:59 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Aug 2006 09:50:59 -0700 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community Message-ID: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Issue #1: ------------- Well, along with the rest of you, I got an inbox full of threatening emails from the agent yesterday. Ugh! Sorry about that! So, the first-try of the agent was possibly a bit of a disaster w.r.t. public relations, but we did learn from it, and we're re-coding it now to have a less annoying behaviour! History: The primary purpose of the agent is to enable a distributed and safe way to add/update/remove your services from the registry. At present, services registered without a SignatureURL can be removed by anyone, which is quite a dangerous situation. For this reason, we encourage people to now download their Service Signature RDF from the page that Eddie has set up at http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and save the output to whatever URL you enter in the Signature URL box. This will protect your service from deregistration by third-parties. If you need to deregister your service, simply remove its description from the RDF document, and the agent will remove it from the registry the next time it crawls. [[More about this in Issue #2 below...]] Another behaviour of the agent is its (configurable) ability to "cleanse" the registry of any service that do not have a SignatureURL. The assumption was that "dead" services would likely not have SignatureURLs, and that any service that was intended to be production- quality would have been registered with a SignatureURL so those without could/should be removed. This became a part of the draft policy statement for my instance of MOBY Central (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). I've had complaints about this policy from several of the key MOBY partners, and they have convinced me to loosen this policy to be less "tyrannical", and in the process we have come up with an alternative proposal that I wish to put forward to the community. My concern with the way people use the main public registry has been that people tend to leave their "trash" lying around in there for, in some cases, years! This clutters-up the search results of other people and is generally quite a nuisance. However, if we agree that services with a SignatureURL are "production quality" and that services without a SignatureURL are "test", then it is still possible to filter-out these "test" services at the client-level, while allowing them to persist in the registry for people to use and experiment with until they are ready to re-register them with a SignatureURL. i.e. the new policy proposal is that services without a SignatureURL can remain in the main public registry; however it is up to the client whether or not these services are displayed in the search results. Does this sound more reasonable to everyone? If so, I will update the policy statement, and we can make a note of this "convention" in the API documentation as well. =============== Issue #2: Immediate Deregistration/Updating The MOBY Central code does not allow you to deregister a service with a Signature URL, nor can you update it. This can be very annoying, I know!! It's not sufficient to just wait for the agent to visit during the night... there must be a better way! It is undocumented because we're still experimenting to see if there are any obvious down-sides, but MOBY Central is currently configured to trigger an Agent visit if you call the registerService method with your SignatureURL as the only parameter. This allows you to *immediately* deregister or update a service (based on a local edit of your Signature RDF document) rather than waiting for the next agent crawl. I invite all developers to try this and let us know if this seems like a sensible behaviour. There may be better ways to accomplish this, so if you have other ideas, or if you see any potential security-holes in this approach, please let us know. ============ Cheers all! Mark -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Aug 4 17:20:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 04 Aug 2006 11:20:28 -0600 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D381DC.6080405@ucalgary.ca> These both seem like great solutions to me, and exactly what I would have suggested :-) From gordonp at ucalgary.ca Fri Aug 4 17:20:28 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 04 Aug 2006 11:20:28 -0600 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <44D381DC.6080405@ucalgary.ca> These both seem like great solutions to me, and exactly what I would have suggested :-) From Pieter.Neerincx at wur.nl Sat Aug 5 15:13:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 12:13:03 -0300 Subject: [MOBY-dev] The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> Message-ID: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Dear all, Here is some feedback from the BioMOBY BOF at Fortaleza. Unfortunately Martin and I were the only Mobifiers present, but we had a good discussion and brainstorm session about these recent developments. We feel the RDF Agent is a good tool to protect services from deregistration by third parties. Furthermore if it is possible to call the Agent to pay a visit immediately it will be just as convenient for developers to use the old way of service registration as it is to use the new way with a SignatureURL. Mark wrote: "MOBY Central is currently configured to trigger an Agent visit if you call the registerService method with your SignatureURL as the only parameter. This allows you to *immediately* deregister or update a service". We were wondering though how this works if you have multiple services described in one RDF document. Can I make one call with only a SignatureURL and have all of them checked (updated/ deleted/appended)? We are glad that registering a service with a SignatureURL is optional for now. At least for the near furture, as this functionality is not yet "production ready" and only partially documented. Therefore it is currently quite difficult for people like us who are running additional registries to implement this way of service registration. Personally I'm looking forward to test this once I get back! And I'll try to contribute to the documentation where I can. (Unfortunately, the network at the conference is not very stable and way too slow for any serious networking.) We also feel the need to have some functionality for cleaning registries, but we think the RDF agent is not suitable for this task. Using a SignatureURL prevents third parties from deleting or altering service registrations, but there is no way the RDF agent can figure out whether a service is "up" and whether it is correctly registered. You can put an RDF document online and register a service that even never existed. Furthermore it is possible to make mistakes in the RDF document and list incorrect inputs and/or outputs. So with or without RDF document there is still no way a client can figure out if the information from a registry is up-to-date. Summarising, using SignatureURLs and the RDF Agent makes (de-) registration more secure, but it doesn't solve the issue of pollution of registries due to dead or mis-registered services. Registry pollution seriously hampers service discovery and spoils the fun. The recently discussed BioMOBY "ping" would be a good candidate to check whether a service is up. I think we already agreed that the ping request will be an empty request. Hence, a ping request has no query alias mobyData tag and there is an empty mobyContent tag: There was still some discussion though about what the ping response should look like. We suggest this will be the same as the input with the option to append serviceNotes. In the serviceNotes section we could optionally use exceptionCode 700 to signal everything is Ok, but just as with normal service invocation serviceNotes remain optional. So a minimal ping response would be something like this: With serviceNotes it would look like this: Some human readable information about this service... 700 Service is up The question that remains is who will use the ping? We think both a registry and the clients could take advantage of the ping. The registry could have a Ping Agent in addition to the RDF Agent to check whether services are up. And it would be fine if this Ping Agent removes dead services after a certain amount of unsuccessful attempts. Furthermore to get the most up-to-date information a client could use a ping to check whether services are up. Having an option to hide services which are down would make more sense to us compared to hiding services without a SignatureURL as a SignatureURL doesn't tell us anything about service availability nor about service quality. The SignatureURL only tells you something about registration security, which is probably not very useful for most clients. Would this make everybody happy? Cheers from Fortaleza, Martin and Pieter On 4-Aug-2006, at 1:50 PM, Mark Wilkinson wrote: > Issue #1: > ------------- > Well, along with the rest of you, I got an inbox full of threatening > emails from the agent yesterday. Ugh! Sorry about that! > > So, the first-try of the agent was possibly a bit of a disaster w.r.t. > public relations, but we did learn from it, and we're re-coding it now > to have a less annoying behaviour! > > History: The primary purpose of the agent is to enable a distributed > and safe way to add/update/remove your services from the registry. At > present, services registered without a SignatureURL can be removed by > anyone, which is quite a dangerous situation. For this reason, we > encourage people to now download their Service Signature RDF from the > page that Eddie has set up at > http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and > save the output to whatever URL you enter in the Signature URL box. > This will protect your service from deregistration by third- > parties. If > you need to deregister your service, simply remove its description > from > the RDF document, and the agent will remove it from the registry the > next time it crawls. [[More about this in Issue #2 below...]] > > Another behaviour of the agent is its (configurable) ability to > "cleanse" the registry of any service that do not have a SignatureURL. > The assumption was that "dead" services would likely not have > SignatureURLs, and that any service that was intended to be > production- > quality would have been registered with a SignatureURL so those > without > could/should be removed. This became a part of the draft policy > statement for my instance of MOBY Central > (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). > > I've had complaints about this policy from several of the key MOBY > partners, and they have convinced me to loosen this policy to be less > "tyrannical", and in the process we have come up with an alternative > proposal that I wish to put forward to the community. > > My concern with the way people use the main public registry has been > that people tend to leave their "trash" lying around in there for, in > some cases, years! This clutters-up the search results of other > people > and is generally quite a nuisance. However, if we agree that services > with a SignatureURL are "production quality" and that services > without a > SignatureURL are "test", then it is still possible to filter-out these > "test" services at the client-level, while allowing them to persist in > the registry for people to use and experiment with until they are > ready > to re-register them with a SignatureURL. > > i.e. the new policy proposal is that services without a > SignatureURL can > remain in the main public registry; however it is up to the client > whether or not these services are displayed in the search results. > > Does this sound more reasonable to everyone? > > If so, I will update the policy statement, and we can make a note of > this "convention" in the API documentation as well. > > =============== > > Issue #2: Immediate Deregistration/Updating > > The MOBY Central code does not allow you to deregister a service > with a > Signature URL, nor can you update it. This can be very annoying, I > know!! It's not sufficient to just wait for the agent to visit during > the night... there must be a better way! > > It is undocumented because we're still experimenting to see if > there are > any obvious down-sides, but MOBY Central is currently configured to > trigger an Agent visit if you call the registerService method with > your > SignatureURL as the only parameter. This allows you to *immediately* > deregister or update a service (based on a local edit of your > Signature > RDF document) rather than waiting for the next agent crawl. > > I invite all developers to try this and let us know if this seems > like a > sensible behaviour. There may be better ways to accomplish this, > so if > you have other ideas, or if you see any potential security-holes in > this > approach, please let us know. > > ============ > > Cheers all! > > Mark > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Sat Aug 5 17:16:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 14:16:37 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 2: BioMOBY meetings In-Reply-To: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Message-ID: <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> Hi All, (To prevent the previous mail from getting too looooong, you'll find a summary of other things we discussed in the next ones...) It's been a while since Mark organised the last meeting specific to BioMOBY in Vancouver. The mailinglist is a useful tool, but meeting "live" once in while is invaluable. Simply because we can work/ discuss/brainstorm much faster when we sit together as compared to sending dozens of e-mails. In addition to brainstorming and discussing we feel such meetings would also be a good place to make decisions about RFCs. When we plan a meeting we have a strict deadline that will pass by less easily without deciding what to implement. (What happened to the asynchronous services proposal??? More about that in the next mail...) In order to make decisions at such a meeting it is essential to prepare the topics well and that all or at least most of the "core developers" will join. The mailinglist would be fine for the foreplay or maybe a teleconference would be nice. So we hereby would like to propose that we try to have a real BioMOBY meeting once a year (again). BioMOBY alone might not be worth the effort to fly all over the world and most of us don't have unlimited budgets for traveling. Therefore we propose to have a meeting the day before or after some other big event. Who would be willing to join and what events would be good candidates? Any suggestions? ECCB perhaps? Cheers, Martin and Pieter From Pieter.Neerincx at wur.nl Sat Aug 5 19:21:32 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Aug 2006 16:21:32 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> Message-ID: <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> Hi all, The last e-mails about the asynchronous services proposal are more than 5 months old, so we were wondering what happened. We know it takes time to create a good proposal and just hope the people at INB in Spain have not given up on reaching consensus. We know there is a demand for asynchronous services. Both Martin and I have already implemented asynchronous services, because we needed something for the time being. If I remember correctly the INB in Spain also already has some asynchronous services and there might be more. Most likely whatever all of us implemented is "compatible" with the current BioMOBY API, but having many different ways to invoke asynchronous services doesn't make life easier for clients. Interoperability is Paramount! So let's get the asynchronous services proposal back on the agenda. Could someone from INB please give us a status update on their proposal? Thanks, Martin & Pieter From johan at ac.uma.es Sun Aug 6 10:38:02 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Sun, 06 Aug 2006 12:38:02 +0200 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> Message-ID: <44D5C68A.2020405@ac.uma.es> Hi! Yes, it is certainly on the agenda. Expect version 2 of the proposal tomorrow (Monday). Kind regards, Johan Karlsson Pieter Neerincx wrote: > Hi all, > > The last e-mails about the asynchronous services proposal are more > than 5 months old, so we were wondering what happened. We know it > takes time to create a good proposal and just hope the people at INB > in Spain have not given up on reaching consensus. We know there is a > demand for asynchronous services. Both Martin and I have already > implemented asynchronous services, because we needed something for > the time being. If I remember correctly the INB in Spain also already > has some asynchronous services and there might be more. Most likely > whatever all of us implemented is "compatible" with the current > BioMOBY API, but having many different ways to invoke asynchronous > services doesn't make life easier for clients. Interoperability is > Paramount! So let's get the asynchronous services proposal back on > the agenda. Could someone from INB please give us a status update on > their proposal? > > Thanks, > > Martin & Pieter > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From Pieter.Neerincx at wur.nl Mon Aug 7 16:16:12 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 7 Aug 2006 13:16:12 -0300 Subject: [MOBY-dev] BioMOBY meeting Fortaleza 3: Asynchronous services In-Reply-To: <44D5C68A.2020405@ac.uma.es> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <0FF1E4BC-1DA7-46EB-9EBD-2E2AC864B01C@wur.nl> <0D7114C7-C553-4D16-84BD-CC8A154BCB49@wur.nl> <44D5C68A.2020405@ac.uma.es> Message-ID: <4C141307-4323-4490-8A71-F0FBC715784E@wur.nl> That's good news! I'm looking forward to read it... Cheers, Pi On 6-Aug-2006, at 7:38 AM, Johan Karlsson wrote: > Hi! > > Yes, it is certainly on the agenda. Expect version 2 of the proposal > tomorrow (Monday). > > Kind regards, > Johan Karlsson > > Pieter Neerincx wrote: >> Hi all, >> >> The last e-mails about the asynchronous services proposal are more >> than 5 months old, so we were wondering what happened. We know it >> takes time to create a good proposal and just hope the people at INB >> in Spain have not given up on reaching consensus. We know there is a >> demand for asynchronous services. Both Martin and I have already >> implemented asynchronous services, because we needed something for >> the time being. If I remember correctly the INB in Spain also already >> has some asynchronous services and there might be more. Most likely >> whatever all of us implemented is "compatible" with the current >> BioMOBY API, but having many different ways to invoke asynchronous >> services doesn't make life easier for clients. Interoperability is >> Paramount! So let's get the asynchronous services proposal back on >> the agenda. Could someone from INB please give us a status update on >> their proposal? >> >> Thanks, >> >> Martin & Pieter >> _______________________________________________ >> 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 Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From johank at cs.umu.se Mon Aug 7 18:41:23 2006 From: johank at cs.umu.se (Johan Karlsson) Date: Mon, 07 Aug 2006 20:41:23 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 Message-ID: <1154976083.44d78953058fb@webmail.cs.umu.se> Hello, Attached to this email you can find an updated version (2.2) of the INB proposal for asynchronous services. We have added some things that were suggested during the discussions and changed some wordings to make it more clear what is intended. Please see summary in the end of this letter for the main changes. We are very grateful for earlier comments and suggestions and hope for more. If there is something we missed to update from the earlier discussion, please let us know. The great difference from the earlier public version is that we are now using an OASIS standard, the Web Services Resource Framework (WSRF), to communicate status and results. The main reason is that the polling approach that we are advocating requires that the web-service in question maintains some sort of state and WSRF is exactly intended to provide a standardised way to handle this. We realise that WSRF might be a new experience for many BioMOBY-developers and therefore we have developed some functions to simplify implementation of asynchronous services and clients (in Perl) and a prototype to illustrate their use. In fact, to write a basic asynchronous BioMOBY service with the library is not much different compared to how it is done for synchronous services (see HelloWorld.pm). More details about the modules and the prototype here: http://bioinfo.pcm.uam.es/prototype/ There you can also find an example of a WSDL (mentioned in the document but not included as appendix for reasons of readability). The parts relating to WSRF would have to be added to the WSDL that MobyCentral generates today. Let us restart the discussions and reach an agreement soon, asynchronous services/clients are definitely needed. Should we set as a goal to reach a decision on the RFC by the end of August? Suggestions/improvements and comments for both the proposal and the modules are greatly welcomed. Summary of major changes in the document: - WSRF to communicate state information instead of MobyStatus - It is possible to retrieve results or status for specific mobyData inputs ("jobs") - Better descriptions of job and batch-call - More descriptions of the error-cases - Updated information about how to describe async services in RDF (Mark, can you please double-check this, we need a Boolean value for this) - The category field from findService output will have four allowed values 'moby', 'moby-async', 'cgi' and 'soap'. - The SOAP method to start a call is now called servicename_submit (before servicename_async) Apologies for the long delay but there has been some fundamental changes that required some study and implementation. Warm greetings from Malaga, Johan Karlsson, GNV5 -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 -------------- next part -------------- A non-text attachment was scrubbed... Name: BioMOBY Asynchronous Service Call Proposal_v2.2.pdf Type: application/pdf Size: 212922 bytes Desc: not available URL: From gordonp at ucalgary.ca Tue Aug 8 15:25:38 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 09:25:38 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> Message-ID: <44D8ACF2.2000901@ucalgary.ca> Hi all, I think both RDF and ping are necessary: 1. The RDF is a contract of sorts. If you are not committed enough to keep the RDF available for download, your service should be deregistered. It also makes people aware that if they modify their service, they really should be updating the RDF (at least the service instance version number). There definitely needs to be a grace period though, as yousay, while the agent is in testing mode. 2. I think the ping should be mandatory, with a valid input test case. I think this is REALLY important: If we want users to really adopt MOBY, we MUST make it difficult to have dead services show up as service options in clients. There is NO good reason to allow lazy service provision. If our focus is on providers rather than users, to use an English idiom, we are putting the cart before the horse. If a service provider cannot easily provide a sample of valid input, they obviously have not even really tested their service! In MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html), you MUST provide one or more test "mobyData" blocks of the correct input type, and receive answers of the correct data type, THEN it register your service. I could very easily, and very happily, add the test data automatically to the registration data or RDF... Sorry for all of the capitalization, but I show no mercy to broken services! (Including some registered by people in my own lab :-)) The robustness of the individual services is (as Mark's has learned) interpreted as the robustness of the clients and the protocol itself, let's not give people any reason to doubt... Paul > Summarising, using SignatureURLs and the RDF Agent makes (de-) > registration more secure, but it doesn't solve the issue of pollution > of registries due to dead or mis-registered services. > > Registry pollution seriously hampers service discovery and spoils the > fun. The recently discussed BioMOBY "ping" would be a good candidate > to check whether a service is up. I think we already agreed that the > ping request will be an empty request. Hence, a ping request has no > query alias mobyData tag and there is an empty mobyContent tag: > > xmlns='http://www.biomoby.org/moby'> > > > > There was still some discussion though about what the ping response > should look like. We suggest this will be the same as the input with > the option to append serviceNotes. In the serviceNotes section we > could optionally use exceptionCode 700 to signal everything is Ok, > but just as with normal service invocation serviceNotes remain > optional. So a minimal ping response would be something like this: > > xmlns='http://www.biomoby.org/moby'> > > > > With serviceNotes it would look like this: > > xmlns='http://www.biomoby.org/moby'> > > > > Some human readable information about this service... > > > 700 > Service is up > > > > > > The question that remains is who will use the ping? We think both a > registry and the clients could take advantage of the ping. The > registry could have a Ping Agent in addition to the RDF Agent to > check whether services are up. And it would be fine if this Ping > Agent removes dead services after a certain amount of unsuccessful > attempts. Furthermore to get the most up-to-date information a client > could use a ping to check whether services are up. Having an option > to hide services which are down would make more sense to us compared > to hiding services without a SignatureURL as a SignatureURL doesn't > tell us anything about service availability nor about service > quality. The SignatureURL only tells you something about registration > security, which is probably not very useful for most clients. > > Would this make everybody happy? > > Cheers from Fortaleza, > > Martin and Pieter > > > On 4-Aug-2006, at 1:50 PM, Mark Wilkinson wrote: > > >> Issue #1: >> ------------- >> Well, along with the rest of you, I got an inbox full of threatening >> emails from the agent yesterday. Ugh! Sorry about that! >> >> So, the first-try of the agent was possibly a bit of a disaster w.r.t. >> public relations, but we did learn from it, and we're re-coding it now >> to have a less annoying behaviour! >> >> History: The primary purpose of the agent is to enable a distributed >> and safe way to add/update/remove your services from the registry. At >> present, services registered without a SignatureURL can be removed by >> anyone, which is quite a dangerous situation. For this reason, we >> encourage people to now download their Service Signature RDF from the >> page that Eddie has set up at >> http://mobycentral.icapture.ubc.ca/servlets/forms/getSignatureForm and >> save the output to whatever URL you enter in the Signature URL box. >> This will protect your service from deregistration by third- >> parties. If >> you need to deregister your service, simply remove its description >> from >> the RDF document, and the agent will remove it from the registry the >> next time it crawls. [[More about this in Issue #2 below...]] >> >> Another behaviour of the agent is its (configurable) ability to >> "cleanse" the registry of any service that do not have a SignatureURL. >> The assumption was that "dead" services would likely not have >> SignatureURLs, and that any service that was intended to be >> production- >> quality would have been registered with a SignatureURL so those >> without >> could/should be removed. This became a part of the draft policy >> statement for my instance of MOBY Central >> (http://mobycentral.icapture.ubc.ca/MOBYCentral_Policy.html). >> >> I've had complaints about this policy from several of the key MOBY >> partners, and they have convinced me to loosen this policy to be less >> "tyrannical", and in the process we have come up with an alternative >> proposal that I wish to put forward to the community. >> >> My concern with the way people use the main public registry has been >> that people tend to leave their "trash" lying around in there for, in >> some cases, years! This clutters-up the search results of other >> people >> and is generally quite a nuisance. However, if we agree that services >> with a SignatureURL are "production quality" and that services >> without a >> SignatureURL are "test", then it is still possible to filter-out these >> "test" services at the client-level, while allowing them to persist in >> the registry for people to use and experiment with until they are >> ready >> to re-register them with a SignatureURL. >> >> i.e. the new policy proposal is that services without a >> SignatureURL can >> remain in the main public registry; however it is up to the client >> whether or not these services are displayed in the search results. >> >> Does this sound more reasonable to everyone? >> >> If so, I will update the policy statement, and we can make a note of >> this "convention" in the API documentation as well. >> >> =============== >> >> Issue #2: Immediate Deregistration/Updating >> >> The MOBY Central code does not allow you to deregister a service >> with a >> Signature URL, nor can you update it. This can be very annoying, I >> know!! It's not sufficient to just wait for the agent to visit during >> the night... there must be a better way! >> >> It is undocumented because we're still experimenting to see if >> there are >> any obvious down-sides, but MOBY Central is currently configured to >> trigger an Agent visit if you call the registerService method with >> your >> SignatureURL as the only parameter. This allows you to *immediately* >> deregister or update a service (based on a local edit of your >> Signature >> RDF document) rather than waiting for the next agent crawl. >> >> I invite all developers to try this and let us know if this seems >> like a >> sensible behaviour. There may be better ways to accomplish this, >> so if >> you have other ideas, or if you see any potential security-holes in >> this >> approach, please let us know. >> >> ============ >> >> Cheers all! >> >> Mark >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a >> term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the >> term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 8 16:16:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 11:16:36 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8ACF2.2000901@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> Message-ID: <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> > 1. The RDF is a contract of sorts. If you are not committed enough to > keep the RDF available for download, your service should be > deregistered. Paul, you are not expressing yourself precisely. I agree that the RDF is a contract. But if I do not sign to such contract (by not providing an RDF signature URL) I should not be kick off (but my service should be considered "testing"). I was very happy that we (at least me and Mark) seemed to have consensus on this. Are you telling the same, or are you disagree (and opening this can of worms again)? > > 2. I think the ping should be mandatory, with a valid input test case. The valid input test cases are nice - and we can use them: we have all the machinery in place. Which is: an LSID resolution service to get test input data from a service provider, the predicate name for that, and MOBY_Environment project that can use this test data to check services (of course, you can use your own checking calls). But: it is beyond what a simple ping should do. Simple ping should not do that much and it will still be useful to get fast and cheap reply if a service (or at least its server) is up and running. So I am just for the ping described by Pieter. Nothing more. (And I have it implementd in Perl Moses already.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue Aug 8 17:00:31 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 11:00:31 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> Message-ID: <44D8C32F.6030106@ucalgary.ca> Sorry, I should have expressed this more clearly. I definitely agree with you that if you don't provide a signature URL, you shouldn't be deregistered. But, if you did provide one, you must maintain it. >> 1. The RDF is a contract of sorts. If you are not committed enough to >> keep the RDF available for download, your service should be >> deregistered. >> > > > Paul, you are not expressing yourself precisely. I agree that the RDF is a > contract. But if I do not sign to such contract (by not providing an RDF > signature URL) I should not be kick off (but my service should be considered > "testing"). I was very happy that we (at least me and Mark) seemed to have > consensus on this. Are you telling the same, or are you disagree (and > opening this can of worms again)? > This is where we disagree. As I said earlier, we have an opportunity to enforce robustness in the protocol, and I think we should take it. Obviously, the test case the service provider lists can be a fairly simple one, it is up to them. Which is more useful to the biologist, knowing a service is reachable (empty ping), or knowing it works (test case)? The appropriateness of an empty ping vs. a functional ping probably boils down to where we expect the "robustness score" to be store, by MOBY Centrals, or does each client instance store its own? >> 2. I think the ping should be mandatory, with a valid input test case. >> > > > The valid input test cases are nice - and we can use them: we have all the > machinery in place. Which is: an LSID resolution service to get test input > data from a service provider, the predicate name for that, and > MOBY_Environment project that can use this test data to check services (of > course, you can use your own checking calls). > But: it is beyond what a simple ping should do. Simple ping should not do > that much and it will still be useful to get fast and cheap reply if a > service (or at least its server) is up and running. > So I am just for the ping described by Pieter. Nothing more. (And I have > it implementd in Perl Moses already.) > > > Martin > > > From gordonp at ucalgary.ca Tue Aug 8 17:28:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 11:28:43 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C32F.6030106@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> Message-ID: <44D8C9CB.7010408@ucalgary.ca> Reading my own e-mail, I have an idea: make the empty-ping behaviour part of the MOBY API (which clients MAY call), AND require a valid test case in the RDF description (which MOBY Central WILL call to measure robustness). The best of both world, no? > Sorry, I should have expressed this more clearly. I definitely agree > with you that if you don't provide a signature URL, you shouldn't be > deregistered. But, if you did provide one, you must maintain it. > >>> 1. The RDF is a contract of sorts. If you are not committed enough to >>> keep the RDF available for download, your service should be >>> deregistered. >>> >>> >> Paul, you are not expressing yourself precisely. I agree that the RDF is a >> contract. But if I do not sign to such contract (by not providing an RDF >> signature URL) I should not be kick off (but my service should be considered >> "testing"). I was very happy that we (at least me and Mark) seemed to have >> consensus on this. Are you telling the same, or are you disagree (and >> opening this can of worms again)? >> >> > This is where we disagree. As I said earlier, we have an opportunity to > enforce robustness in the protocol, and I think we should take it. > Obviously, the test case the service provider lists can be a fairly > simple one, it is up to them. Which is more useful to the biologist, > knowing a service is reachable (empty ping), or knowing it works (test > case)? > > The appropriateness of an empty ping vs. a functional ping probably > boils down to where we expect the "robustness score" to be store, by > MOBY Centrals, or does each client instance store its own? > >>> 2. I think the ping should be mandatory, with a valid input test case. >>> >>> >> The valid input test cases are nice - and we can use them: we have all the >> machinery in place. Which is: an LSID resolution service to get test input >> data from a service provider, the predicate name for that, and >> MOBY_Environment project that can use this test data to check services (of >> course, you can use your own checking calls). >> But: it is beyond what a simple ping should do. Simple ping should not do >> that much and it will still be useful to get fast and cheap reply if a >> service (or at least its server) is up and running. >> So I am just for the ping described by Pieter. Nothing more. (And I have >> it implementd in Perl Moses already.) >> >> >> Martin >> >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 8 17:43:02 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 12:43:02 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C32F.6030106@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> Message-ID: <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> > I definitely agree > with you that if you don't provide a signature URL, you shouldn't be > deregistered. But, if you did provide one, you must maintain it. Clear! So is this done and agreed on with everybody? Could anybidy put it in the API documenattion please? This is where we disagree. As I said earlier, we have an opportunity to > enforce robustness in the protocol, and I think we should take it. Well, I am not saying not to take it. I am only advocating to have both, the simple ping and the testing ping. And I am implementing now the empty ping (defined as a request with no mobyData, returning the same back, possibly with some service notes added). The testing ping will have to wait when I have more time for implementing (or using) the LSID resolution service (or at least getting and reading the service RDF document where the input data could be). We (GCP) have may services and we are definitely in favor to have them robust. We think that the empty ping can discover maybe 90% of bad cases, so it means a vey good ROI. The remainig 10%, we will deal with it using test data within the MOBY_Enviroment project. For that (the tetsing ping) we do not need any changes in the MOBY API. So where is the problem? I see the problem is that most people is not saying if they agree with the API for the empty ping as suggested by me ad Pieter. If people say yes, we are done with the empty ping and can concentrate how to persuade people to have also testing ping. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Tue Aug 8 19:05:04 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 08 Aug 2006 13:05:04 -0600 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> Message-ID: <44D8E060.2000205@ucalgary.ca> I think our string of e-mails this morning proves just how valuable a face to face meeting of MOBY developers can be, since we would have found out in 20 seconds that we both agreed with each other on both issues. :-) Is it just me, or is the lag time for mailing list getting verry looooooong...... up to a hour or more? >> I definitely agree >> with you that if you don't provide a signature URL, you shouldn't be >> deregistered. But, if you did provide one, you must maintain it. >> > > > Clear! So is this done and agreed on with everybody? Could anybidy put it in > the API documenattion please? > > > > > This is where we disagree. As I said earlier, we have an opportunity to > >> enforce robustness in the protocol, and I think we should take it. >> > > > Well, I am not saying not to take it. I am only advocating to have both, the > simple ping and the testing ping. And I am implementing now the empty ping > (defined as a request with no mobyData, returning the same back, possibly > with some service notes added). The testing ping will have to wait when I > have more time for implementing (or using) the LSID resolution service (or > at least getting and reading the service RDF document where the input data > could be). > > We (GCP) have may services and we are definitely in favor to have them > robust. We think that the empty ping can discover maybe 90% of bad cases, so > it means a vey good ROI. The remainig 10%, we will deal with it using test > data within the MOBY_Enviroment project. For that (the tetsing ping) we do > not need any changes in the MOBY API. > > So where is the problem? I see the problem is that most people is not saying > if they agree with the API for the empty ping as suggested by me ad Pieter. > If people say yes, we are done with the empty ping and can concentrate how > to persuade people to have also testing ping. > > Martin > > From martin.senger at gmail.com Tue Aug 8 19:47:19 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 8 Aug 2006 14:47:19 -0500 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8E060.2000205@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> <44D8E060.2000205@ucalgary.ca> Message-ID: <4d93f07c0608081247h107acb5ej825a85a599b98ff1@mail.gmail.com> > I think our string of e-mails this morning proves just how valuable a > face to face meeting of MOBY developers can be Bingo!!! 100% truth. So what can we do about it? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Aug 8 20:14:56 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Aug 2006 13:14:56 -0700 Subject: [MOBY-dev] [moby] Re: {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8E060.2000205@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <4d93f07c0608081043l5e2a5d34u646dae84497e97af@mail.gmail.com> <44D8E060.2000205@ucalgary.ca> Message-ID: <1155068097.5412.8.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-08-08 at 13:05 -0600, Paul Gordon wrote: > I think our string of e-mails this morning proves just how valuable a > face to face meeting of MOBY developers can be Indeed! The barriers from my side have been two-fold. First, the latest MOBY funding award did not include any money for conferences (though I did request it!). In the past I have supplemented the face to face meetings out of the Genome Canada funding so that it wouldn't be so expensive for people to attend. I may be able to find a way to fund the meetings, but I have to talk to the lead PI on the Platform award. Second, I have been trying to hire for the senior developer position for quite a while. I wanted to delay the meeting until this person was hired, since they are going to more or less take-over the majority of ,y own role in running the project day by day. The first two candidates have turned-down the position, sadly. I have now identified a potential candidate who I will be interviewing in a couple of weeks. Hopefully this will come to fruition! The lack of funding for travel is also a barrier for my own attendance at meetings. The previous award had sufficient money for travel, however the new award is intended to be "maintenance only", and travel was not considered necessary for maintenance. Anyway, I'll see if I can scrape-up some funding and/or get industrial sponsorship to help defray the costs of a face-to-face MOBY meeting sometime soon. I'm supposed to be helping Jason Stajich in planning the next BioHackathon, so we might be able to piggy-back on top of that meeting?!? M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From Pieter.Neerincx at wur.nl Thu Aug 10 17:52:13 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 10 Aug 2006 14:52:13 -0300 Subject: [MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community In-Reply-To: <44D8C9CB.7010408@ucalgary.ca> References: <1154710259.1301.98.camel@bioinfo.icapture.ubc.ca> <6CFFAC60-DCDE-4047-B3CF-B7EEDD0A1427@wur.nl> <44D8ACF2.2000901@ucalgary.ca> <4d93f07c0608080916x236bc0f4tbc00a8a54a1ed01d@mail.gmail.com> <44D8C32F.6030106@ucalgary.ca> <44D8C9CB.7010408@ucalgary.ca> Message-ID: <00F44F1E-CCB6-460C-98DB-2C972587C941@wur.nl> On 8-Aug-2006, at 2:28 PM, Paul Gordon wrote: > Reading my own e-mail, I have an idea: make the empty-ping behaviour > part of the MOBY API (which clients MAY call), AND require a valid > test > case in the RDF description (which MOBY Central WILL call to measure > robustness). The best of both world, no? Yes, that sounds good to me. I agree with Martin that a ping should be a quick method to check whether a service is up. I welcome the idea of forcing "production quality" services to implement example inputs and outputs to improve robustness, while making this optional for beta services. This should already be possible using LSID resolution, but I was wondering if there is anybody out there who actually implemented this and is using it. If so, is there some documentation on how to do this? Cheers, Pi Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From martin.senger at gmail.com Thu Aug 10 23:05:29 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 10 Aug 2006 18:05:29 -0500 Subject: [MOBY-dev] RDFs from dashboard In-Reply-To: <200608041128.20740.d.haase@gsf.de> References: <200608041128.20740.d.haase@gsf.de> Message-ID: <4d93f07c0608101605o238b900dl574f0cacdac46b4f@mail.gmail.com> Thanks to the Dirk message, I have fixed a bug in jMoby's CentralImpl.java, concerning storing locally an RDF document received from the service registration request. Now the stored file (if you register your service using Dashboard, the returned RDF file is stored automatically on a place you tell Dashboard) is a proper XML document. It would be nice if somebody with a public server can test it (public, because it must invite the RDF agent to check the document). Please "cvs update -dP", as usual. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sat Aug 12 00:05:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Aug 2006 17:05:58 -0700 Subject: [MOBY-dev] Gbrowse Moby support for Secondaries!!!! Message-ID: Hi all! For any of you who have been waiting in anticipation... Gbrowse Moby now supports Secondary parameters!! http://mobycentral.icapture.ubc.ca Eddie and I have been team coding for a couple of days and it looks like it all works correctly - including writing the value of the chosen parameter into the SCUFL document so that you can run your workflow in high-throughput Taverna with exactly the same settings as in Gbrowse Moby. Thanks to the reviewers of the Gbrowse Moby manuscript (a couple of you are on this list, I'm sure :-) ) for giving me the kick in the pants that I needed to finally get this done! Cheers all! Please contact us if you notice any bugs. Mark -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From martin.senger at gmail.com Wed Aug 16 15:50:11 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 10:50:11 -0500 Subject: [MOBY-dev] MobyServlet.war should not be there Message-ID: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> Paul and all, I had big problems when teaching jMoby. Your file MobyServlet.war is 10 MB long and it causes real problems for people with a slower connection. I also think (even though I cannot be fully sure) that such files (war files) could be created from other pieces that are already part of jMoby CVS - and therefore they should not be in CVS at all. There should be an ant script that creates them if needed. Sorry, Paul, but I have to remove the file. I understand that this is not an ideal step - because now your documentation is out of sync - but I simply did not have other options. Please, please, do not put it back - but make an ant task to create it (for example). Thank you and I apologize for this rather drastic move. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Wed Aug 16 20:06:29 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 16 Aug 2006 14:06:29 -0600 Subject: [MOBY-dev] MobyServlet.war should not be there In-Reply-To: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> Message-ID: <44E37AC5.8080105@ucalgary.ca> Hi Martin, Sorry for the inconvenience. Unfortunately you cannot create it with Ant. It includes a few files not yet in the repository, and anyway would absolutely require the user to have a "virgin" JRE (i.e. with no extra libraries installed, otherwise I can't guarantee the WAR is self-contained). I can, however, repoint the docs to my own Web site to download it. I will do this today. It would be nice to have somewhere in CVS where large binaries can be plopped for the public to download...should we create one at the top level of moby-live somewhere? > Paul and all, > I had big problems when teaching jMoby. Your file MobyServlet.war is 10 > MB long and it causes real problems for people with a slower connection. > I also think (even though I cannot be fully sure) that such files (war > files) could be created from other pieces that are already part of jMoby CVS > - and therefore they should not be in CVS at all. There should be an ant > script that creates them if needed. > Sorry, Paul, but I have to remove the file. I understand that this is not > an ideal step - because now your documentation is out of sync - but I simply > did not have other options. Please, please, do not put it back - but make an > ant task to create it (for example). > > Thank you and I apologize for this rather drastic move. > Martin > > From martin.senger at gmail.com Wed Aug 16 20:35:09 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 15:35:09 -0500 Subject: [MOBY-dev] MobyServlet.war should not be there In-Reply-To: <44E37AC5.8080105@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> Message-ID: <4d93f07c0608161335h4249942fk152ccdd2025ed71@mail.gmail.com> > I can, however, > repoint the docs to my own Web site to download it. I will do this today. Thanks. It would be nice to have somewhere in CVS where large binaries can be > plopped for the public to download... We have it (we use it for third-party jar files). Module name is jars-archive. Feel free to use also for other files. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Aug 16 20:43:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 16 Aug 2006 13:43:04 -0700 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <44E37AC5.8080105@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> Message-ID: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> I don't think that putting it at the top level of moby-live will necessarily help the situation - many (most?) people simply check-out moby-live, rather than moby-live/Perl or moby-live/Java, so they will still get this large file when they do a checkout. If you send me the URL and a description I can add it to the "Tools" page on biomoby.org. I wonder if it is time to re-think the link structure of the website again to make these kinds of resources more prominent? M On Wed, 2006-08-16 at 14:06 -0600, Paul Gordon wrote: > Hi Martin, > > Sorry for the inconvenience. > > Unfortunately you cannot create it with Ant. It includes a few files > not yet in the repository, and anyway would absolutely require the user > to have a "virgin" JRE (i.e. with no extra libraries installed, > otherwise I can't guarantee the WAR is self-contained). I can, however, > repoint the docs to my own Web site to download it. I will do this today. > > It would be nice to have somewhere in CVS where large binaries can be > plopped for the public to download...should we create one at the top > level of moby-live somewhere? > > Paul and all, > > I had big problems when teaching jMoby. Your file MobyServlet.war is 10 > > MB long and it causes real problems for people with a slower connection. > > I also think (even though I cannot be fully sure) that such files (war > > files) could be created from other pieces that are already part of jMoby CVS > > - and therefore they should not be in CVS at all. There should be an ant > > script that creates them if needed. > > Sorry, Paul, but I have to remove the file. I understand that this is not > > an ideal step - because now your documentation is out of sync - but I simply > > did not have other options. Please, please, do not put it back - but make an > > ant task to create it (for example). > > > > Thank you and I apologize for this rather drastic move. > > Martin > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Wed Aug 16 21:02:03 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 16 Aug 2006 15:02:03 -0600 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <44E387CB.2080905@ucalgary.ca> I think I like Mark's approach better than the jars-archive approach, because the major point of the WAR is that you don't need to bother with CVS, Ant, etc. It's for Extremely Lazy Programmers. With regards to the links in general, I agree with Mark that they might need to be made more prominent. While the Web site is a major improvement esthetically over the old one, the useful links where a naive user might actually find something of interest are buried at least 3 links deep. The question is, who has permission and time to update this :-) > I don't think that putting it at the top level of moby-live will > necessarily help the situation - many (most?) people simply check-out > moby-live, rather than moby-live/Perl or moby-live/Java, so they will > still get this large file when they do a checkout. > > If you send me the URL and a description I can add it to the "Tools" > page on biomoby.org. I wonder if it is time to re-think the link > structure of the website again to make these kinds of resources more > prominent? > > M > > > > > On Wed, 2006-08-16 at 14:06 -0600, Paul Gordon wrote: > >> Hi Martin, >> >> Sorry for the inconvenience. >> >> Unfortunately you cannot create it with Ant. It includes a few files >> not yet in the repository, and anyway would absolutely require the user >> to have a "virgin" JRE (i.e. with no extra libraries installed, >> otherwise I can't guarantee the WAR is self-contained). I can, however, >> repoint the docs to my own Web site to download it. I will do this today. >> >> It would be nice to have somewhere in CVS where large binaries can be >> plopped for the public to download...should we create one at the top >> level of moby-live somewhere? >> >>> Paul and all, >>> I had big problems when teaching jMoby. Your file MobyServlet.war is 10 >>> MB long and it causes real problems for people with a slower connection. >>> I also think (even though I cannot be fully sure) that such files (war >>> files) could be created from other pieces that are already part of jMoby CVS >>> - and therefore they should not be in CVS at all. There should be an ant >>> script that creates them if needed. >>> Sorry, Paul, but I have to remove the file. I understand that this is not >>> an ideal step - because now your documentation is out of sync - but I simply >>> did not have other options. Please, please, do not put it back - but make an >>> ant task to create it (for example). >>> >>> Thank you and I apologize for this rather drastic move. >>> Martin >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From martin.senger at gmail.com Wed Aug 16 21:04:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 16:04:06 -0500 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0608161404u5ed9226co9fa67c84d904d918@mail.gmail.com> > I don't think that putting it at the top level of moby-live will > necessarily help the situation No, it would not. But I was not talking about the moby-live level. The jars-archive is on the same level with moby-live - so people taking moby-live are not getting jars-archive (as they are not getting Accessories and s-moby). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Aug 16 21:19:45 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 16 Aug 2006 16:19:45 -0500 Subject: [MOBY-dev] [moby] Re: MobyServlet.war should not be there In-Reply-To: <44E387CB.2080905@ucalgary.ca> References: <4d93f07c0608160850w68eeb88l185365d679c2edbe@mail.gmail.com> <44E37AC5.8080105@ucalgary.ca> <1155760984.6594.23.camel@bioinfo.icapture.ubc.ca> <44E387CB.2080905@ucalgary.ca> Message-ID: <4d93f07c0608161419h4899f2fm4925daaf0cd5ee54@mail.gmail.com> > I think I like Mark's approach better than the jars-archive approach, > because the major point of the WAR is that you don't need to bother with > CVS, Ant, etc. Do whatever you think better - but you did not understand me: my approach is the same as Mark's - the files from jars-archive are stored and updated by CVS, but users can take them by pure HTTP, as from the Mark's link. The same way as it is done for the third-party libraries in the jMoby - see the ant file and you will see the URL I was talking about. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Fri Aug 18 10:04:03 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Fri, 18 Aug 2006 12:04:03 +0200 Subject: [MOBY-dev] moby service templates Message-ID: Hi all, I am working on something like a MobyServiceTemplate. The idea is to store there templates for other programs to use them to deploy real biomoby services. In my case most of the services I will create are exactly the same, lot of differet databases with the same kind of data, but different data. Therefore their services look the same except that they have different data behind. While creating this serviceTemplates definition I have identified that this are the fields that will NOT be common: -service namespace (one would be "MNCNdatabase" and other could be "IPGRIdatabase") -authURI -contactEmail -description: it will be almost the same but just with some little differences. Apart of this, all the rest can be common: service name, category, type, input/output/secondary objects. Am I missing something? Is there anybody who has something similar? My templates definition file (with one service example and with some things that only apply to my project) can be found at: http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml Thanks in advance. Javier. From markw at illuminae.com Fri Aug 18 16:04:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 18 Aug 2006 09:04:50 -0700 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: References: Message-ID: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit of the service architecture is now auto-generated by their code, so it really just comes down to the service provider writing the business logic. I suppose if the business logic can, in your case, be even further templated then the bar for service provision gets even lower! Must run! M On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: > Hi all, > > I am working on something like a MobyServiceTemplate. The idea is to > store there templates for other programs to use them to deploy real > biomoby services. > In my case most of the services I will create are exactly the same, > lot of differet databases with the same kind of data, but different > data. Therefore their services look the same except that they have > different data behind. > > While creating this serviceTemplates definition I have identified that > this are the fields that will NOT be common: > > -service namespace (one would be "MNCNdatabase" and other could be > "IPGRIdatabase") > -authURI > -contactEmail > -description: it will be almost the same but just with some little differences. > > Apart of this, all the rest can be common: service name, category, > type, input/output/secondary objects. > > Am I missing something? > Is there anybody who has something similar? My templates definition > file (with one service example and with some things that only apply to > my project) can be found at: > > http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml > > Thanks in advance. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Fri Aug 18 16:17:49 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Fri, 18 Aug 2006 18:17:49 +0200 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: Right right, I am basing much of my work on Martin previous work. But what I am doing is adapting a wrapper software (PyWrapper) that is used to connect database to GBIF (do you remember?). The users of this software map their database to a common ontology and then the wrapper can generate "community/standard" XML schemas. The user maps his database visually (through a config tool) and then the work is done. The idea is to provide BioMOBY support there, so automatically when the user maps his database to this common ontology he will become a BioMOBY provider for a certain services. This mapping file is what indicates what "concepts" in out ontology are needed to generate a certain BioMOBY service (defined in the template). So, no programming at all, the database owner maps his database to the ontology and the software takes care of, by looking at the mapping file (curated by a MOBY expert), register and become available as a MOBY service. I think it should work (apart of the multiple invocation who is giving me some headache). The only issue I have is in finding good examples of where is this useful at all (but I suppose this is not my bussiness :D) Javier. On 8/18/06, Mark Wilkinson wrote: > Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit > of the service architecture is now auto-generated by their code, so it > really just comes down to the service provider writing the business > logic. I suppose if the business logic can, in your case, be even > further templated then the bar for service provision gets even lower! > > Must run! > > M > > > On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: > > Hi all, > > > > I am working on something like a MobyServiceTemplate. The idea is to > > store there templates for other programs to use them to deploy real > > biomoby services. > > In my case most of the services I will create are exactly the same, > > lot of differet databases with the same kind of data, but different > > data. Therefore their services look the same except that they have > > different data behind. > > > > While creating this serviceTemplates definition I have identified that > > this are the fields that will NOT be common: > > > > -service namespace (one would be "MNCNdatabase" and other could be > > "IPGRIdatabase") > > -authURI > > -contactEmail > > -description: it will be almost the same but just with some little differences. > > > > Apart of this, all the rest can be common: service name, category, > > type, input/output/secondary objects. > > > > Am I missing something? > > Is there anybody who has something similar? My templates definition > > file (with one service example and with some things that only apply to > > my project) can be found at: > > > > http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml > > > > Thanks in advance. > > > > Javier. > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Sun Aug 20 15:24:55 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Sun, 20 Aug 2006 09:24:55 -0600 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: <44E87EC7.2010105@ucalgary.ca> Hello Javier, You may alternatively want to take a quick look at MobyServlet (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html). You could subclass the MobyServlet with your schema mapping functions, and all the user would need to do is modify the web.xml file. The web.xml file for MobyServlet already contains the "template" that you are looking for... Regards, Paul > Right right, > > I am basing much of my work on Martin previous work. > But what I am doing is adapting a wrapper software (PyWrapper) that is > used to connect database to GBIF (do you remember?). The users of this > software map their database to a common ontology and then the wrapper > can generate "community/standard" XML schemas. The user maps his > database visually (through a config tool) and then the work is done. > The idea is to provide BioMOBY support there, so automatically when > the user maps his database to this common ontology he will become a > BioMOBY provider for a certain services. This mapping file is what > indicates what "concepts" in out ontology are needed to generate a > certain BioMOBY service (defined in the template). > > So, no programming at all, the database owner maps his database to the > ontology and the software takes care of, by looking at the mapping > file (curated by a MOBY expert), register and become available as a > MOBY service. > > I think it should work (apart of the multiple invocation who is giving > me some headache). > The only issue I have is in finding good examples of where is this > useful at all (but I suppose this is not my bussiness :D) > > Javier. > > On 8/18/06, Mark Wilkinson wrote: > >> Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit >> of the service architecture is now auto-generated by their code, so it >> really just comes down to the service provider writing the business >> logic. I suppose if the business logic can, in your case, be even >> further templated then the bar for service provision gets even lower! >> >> Must run! >> >> M >> >> >> On Fri, 2006-08-18 at 12:04 +0200, Javier de la Torre wrote: >> >>> Hi all, >>> >>> I am working on something like a MobyServiceTemplate. The idea is to >>> store there templates for other programs to use them to deploy real >>> biomoby services. >>> In my case most of the services I will create are exactly the same, >>> lot of differet databases with the same kind of data, but different >>> data. Therefore their services look the same except that they have >>> different data behind. >>> >>> While creating this serviceTemplates definition I have identified that >>> this are the fields that will NOT be common: >>> >>> -service namespace (one would be "MNCNdatabase" and other could be >>> "IPGRIdatabase") >>> -authURI >>> -contactEmail >>> -description: it will be almost the same but just with some little differences. >>> >>> Apart of this, all the rest can be common: service name, category, >>> type, input/output/secondary objects. >>> >>> Am I missing something? >>> Is there anybody who has something similar? My templates definition >>> file (with one service example and with some things that only apply to >>> my project) can be found at: >>> >>> http://synthesys.csic.es/biomoby/MappingTapirConcept_BioMOBYServices.xml >>> >>> Thanks in advance. >>> >>> Javier. >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> K?hler et al, 2006 >> >> _______________________________________________ >> 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 > From martin.senger at gmail.com Mon Aug 21 12:11:03 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 21 Aug 2006 07:11:03 -0500 Subject: [MOBY-dev] [moby] moby service templates In-Reply-To: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> References: <1155917090.6931.61.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0608210511q12c97563u250dea616a690be9@mail.gmail.com> Hi, Keep an eye on what Martin and Eddie are doing with MoSeS - quite a bit > of the service architecture is now auto-generated by their code, so it > really just comes down to the service provider writing the business > logic. I suppose if the business logic can, in your case, be even > further templated then the bar for service provision gets even lower! I fully agree with Mark. Here are perhaps more details about what I did with BioCASE (I guess for Tapir it will be similar, even perhaps the same) : You already know the source - but perhaps for the other: http://moby.generationcp.org/bb_services/docs/index.html. The MoSeS can generate an implementtaion class for a service - such class is the same for all services (except the service name). Everything that varies is in the "properties". So the "properties" are similar to the Javier's templates. With Milko (IPGRI), last year, we tried to find a way to define templates - but then we gave it up because of the possible complexity of mapping (just see into an example Javier gave us and you will see a huge number of places to be changed for any new template, for any new BioMoby data type). That's why we decided to go the "properties" way - where we defined a java beanshell script to convert things between biocase and biomoby. It would be nice to find a common way how to make this B(iomoby)B(iocase) wedding. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Tue Aug 22 11:34:41 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Aug 2006 13:34:41 +0200 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: References: Message-ID: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> Hi All, Today I was adding some CrossReference Information Blocks (CRIBs). According to the API documentation the xrefType attribute for an Xref is "a term from the Cross-Reference-Type Ontology indicating the semantic type of this cross-reference". However the documentation doesn't provide a link to this Cross-Reference-Type Ontology. I tried to Google it, but wasn't successful. Where should I look to figure out which xrefTypes are available? It's not part of MOBY Central is it? Cheers, Pi From d.haase at gsf.de Tue Aug 22 12:08:19 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 22 Aug 2006 14:08:19 +0200 Subject: [MOBY-dev] Agent does not change Registry Message-ID: <200608221408.19544.d.haase@gsf.de> Hi there! It seems that the proposed way to change services which are registered with signatureURL does not work. I changed the RDF description of a service, called the agent with the 'registerService' call with only the signature field present and got back the message "The RDFagent call was successful." However, when I looked up the service details with the service encyclopedia or dashboard (after a 'Reload' of course...) the modifications were not displayed. I also checked the modified RDF with the test page. Here I could see the changes, but still no effect on Moby Central. Jost, a service developer from RZPD currently has the same problem. Are we missing something or does the agent just does not work as intended? Best, dirk From edward.kawas at gmail.com Tue Aug 22 13:07:31 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 06:07:31 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608221408.19544.d.haase@gsf.de> Message-ID: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Hi Dirk, Did you by chance modify the timestamp of your LSID in your RDF? The agent only modifies the service if the LSID has changed. Note that this may change in the future. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, August 22, 2006 5:08 AM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] Agent does not change Registry > > Hi there! > > It seems that the proposed way to change services which are > registered with signatureURL does not work. I changed the RDF > description of a service, called the agent with the > 'registerService' call with only the signature field present > and got back the message "The RDFagent call was successful." > However, when I looked up the service details with the > service encyclopedia or dashboard (after a 'Reload' of > course...) the modifications were not displayed. > > I also checked the modified RDF with the test page. Here I > could see the changes, but still no effect on Moby Central. > > Jost, a service developer from RZPD currently has the same > problem. Are we missing something or does the agent just does > not work as intended? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Aug 22 13:30:32 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 22 Aug 2006 15:30:32 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <200608221530.33170.d.haase@gsf.de> On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > Hi Dirk, > > Did you by chance modify the timestamp of your LSID in your RDF? The agent > only modifies the service if the LSID has changed. Ahh, interesting! It did work when I changed the LSID (the timestamp within the LSID, to be precise...). Thanks, dirk From martin.senger at gmail.com Tue Aug 22 13:24:03 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 08:24:03 -0500 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <200608221408.19544.d.haase@gsf.de> <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> > The agent only > modifies the service if the LSID has changed. No! Eddie, haven't you consider our (me, you, Mark) recent email exchange? The service provider will *not* change the LSID. Note that this may change in the future. The future is now. Or was yesterday already. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Tue Aug 22 13:40:34 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 06:40:34 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> Message-ID: <002801c6c5f0$8cc12950$6400a8c0@notebook> Hi Martin, I am going to change it (probably should have chosen my words better). Before I make those changes, I am going to tie up some loose ends. Sorry for the miscommunication! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 6:24 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > > The agent only > > modifies the service if the LSID has changed. > > > No! Eddie, haven't you consider our (me, you, Mark) recent > email exchange? > The service provider will *not* change the LSID. > > > Note that this may change in the future. > > > The future is now. Or was yesterday already. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue Aug 22 13:58:21 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 22 Aug 2006 07:58:21 -0600 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> References: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> Message-ID: <44EB0D7D.6090800@ucalgary.ca> We never got around to making a proper ontology for it. Right now it's just a string, as far as I know. > Hi All, > > Today I was adding some CrossReference Information Blocks (CRIBs). > According to the API documentation the xrefType attribute for an Xref > is "a term from the Cross-Reference-Type Ontology indicating the > semantic type of this cross-reference". However the documentation > doesn't provide a link to this Cross-Reference-Type Ontology. I tried > to Google it, but wasn't successful. Where should I look to figure > out which xrefTypes are available? It's not part of MOBY Central is it? > > Cheers, > > Pi > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From martin.senger at gmail.com Tue Aug 22 14:09:06 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 11:09:06 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002801c6c5f0$8cc12950$6400a8c0@notebook> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> Message-ID: <4d93f07c0608220709p2713e216mcd8cb6a662afd7f@mail.gmail.com> Hi Eddie, I am going to change it Thanks! That's a good news. So have you decided to have two version of the RDF documents? The read-only (given from RESOURCES and containing the current LSIDs) and the kind-of-template (given after a service registration, and not containing any LSID)? I think it was roughly what we discussed with Mark recently. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Aug 22 14:34:03 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 22 Aug 2006 14:34:03 +0000 GMT Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002801c6c5f0$8cc12950$6400a8c0@notebook> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> Message-ID: <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> Speaking of LSID's, there's one small and rare loophole in the current plan for LSID's of service instances. Background: the RDF describing a service instance is "owned" by the service provider. It is planned that the address of this RDF document is going to be provided as the LSID resolution address when Moby Central is acting as an LSID authority server. At the moment, this RDF document includes a reference to the Service Instance LSID itself - hence the problem described below (you cannot change the signature without changing the LSID). After discussions with Martin and Eddie we have agreed that the "owner" of an LSID is the LSID authority (moby central) and so the control of LSID versioning should be in moby central rather than the service provider. The new behavior will be that moby central will update both the service registration and the LSID version when the agent visits a service provider and discovers a modified signature RDF. The "gotcha" in this scenario is when moby central is acting as the authority server for an LSID representing a service whose signature has JUST been modified (before the agent visits again). The metadata resolved will not be the same as the last resolution of that LSID. We can either shrug our shoulders and not care about this rare case, or we can slow things down a bit and have mobycentral (when acting as an authority server) resolve an LSID first on its own to be sure its registration is up to date before passing the WSDL of the LSID resolver. How important is this loophole to those who are building tools that rely on LSID resolution? M -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 22 Aug 2006 06:40:34 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] Agent does not change Registry Hi Martin, I am going to change it (probably should have chosen my words better). Before I make those changes, I am going to tie up some loose ends. Sorry for the miscommunication! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 6:24 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > > The agent only > > modifies the service if the LSID has changed. > > > No! Eddie, haven't you consider our (me, you, Mark) recent > email exchange? > The service provider will *not* change the LSID. > > > Note that this may change in the future. > > > The future is now. Or was yesterday already. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > 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 From edward.kawas at gmail.com Tue Aug 22 14:39:29 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 07:39:29 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220709p2713e216mcd8cb6a662afd7f@mail.gmail.com> Message-ID: <003501c6c5f8$c74dbe00$6400a8c0@notebook> Currently when someone registers a service, the RDF is actually taken from a source outside of RESOURCES, so LSIDs will be easy to remove. So what we discussed earlier w.r.t. LSIDs will be changed. I will also take into account all of the previous comments posted to the list (so that people don't get annoyed with the agent). Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:09 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Eddie, > > I am going to change it > > > > Thanks! That's a good news. So have you decided to have two > version of the RDF documents? The read-only (given from > RESOURCES and containing the current LSIDs) and the > kind-of-template (given after a service registration, and not > containing any LSID)? I think it was roughly what we > discussed with Mark recently. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From martin.senger at gmail.com Tue Aug 22 14:57:44 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 11:57:44 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> References: <4d93f07c0608220624n39412905p89d3a21f091541d9@mail.gmail.com> <002801c6c5f0$8cc12950$6400a8c0@notebook> <816200384-1156257271-cardhu_blackberry.rim.net-11475-@engine19-cell01> Message-ID: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> Mark, I think that you are describing a "race condition" situation - happening when an operation is not an atomic operation. I think that this loophole is not important assuming that: * after an agent visits the modified RDF, everything become again in sync, and * the database stay in a consistent state. Just my 2c's, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Tue Aug 22 15:02:24 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 22 Aug 2006 08:02:24 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> Message-ID: <003c01c6c5fb$facb04b0$6400a8c0@notebook> Hi Martin, I don't think you understand what Mark is trying to say. Imagine the following scenario: 1. Service provider registers a service gets an RDF document back. 2. Service provider updates RDF and waits for agent to check his document 3. In the meantime, someone queries mobycentral for his service and gets some information back, while someone queries the LSID resolver and gets other information. The 2 pieces of information are out of synch. Did I understand you correctly Mark? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:58 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Mark, > I think that you are describing a "race condition" > situation - happening when an operation is not an atomic > operation. I think that this loophole is not important assuming that: > * after an agent visits the modified RDF, everything > become again in sync, and > * the database stay in a consistent state. > > Just my 2c's, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Aug 22 15:31:28 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 22 Aug 2006 15:31:28 +0000 GMT Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003c01c6c5fb$facb04b0$6400a8c0@notebook> References: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> <003c01c6c5fb$facb04b0$6400a8c0@notebook> Message-ID: <997236587-1156260715-cardhu_blackberry.rim.net-3242-@engine10-cell01> I think you are both right :-) So long as it isn't absolutely critical that the two are in sync 100% of the time, then we'll just ignore the race condition. We can tighten this later if necessary. Cheers all! I'm on holiday in 5 hours! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 22 Aug 2006 08:02:24 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] Agent does not change Registry Hi Martin, I don't think you understand what Mark is trying to say. Imagine the following scenario: 1. Service provider registers a service gets an RDF document back. 2. Service provider updates RDF and waits for agent to check his document 3. In the meantime, someone queries mobycentral for his service and gets some information back, while someone queries the LSID resolver and gets other information. The 2 pieces of information are out of synch. Did I understand you correctly Mark? Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Tuesday, August 22, 2006 7:58 AM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Mark, > I think that you are describing a "race condition" > situation - happening when an operation is not an atomic > operation. I think that this loophole is not important assuming that: > * after an agent visits the modified RDF, everything > become again in sync, and > * the database stay in a consistent state. > > Just my 2c's, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > 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 From Pieter.Neerincx at wur.nl Tue Aug 22 15:58:40 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Aug 2006 17:58:40 +0200 Subject: [MOBY-dev] CRIB xrefType ontology ? In-Reply-To: <44EB0D7D.6090800@ucalgary.ca> References: <65989DEA-E66F-4A57-9199-5C0729FCF1C1@wur.nl> <44EB0D7D.6090800@ucalgary.ca> Message-ID: Hi Paul, Thanks for the explanation. Then I'll just put something sensible string there for the time being. I'll add a note to the docs that the Cross-Reference-Type Ontology is a vaportology for now... Cheers, Pi On 22-Aug-2006, at 3:58 PM, Paul Gordon wrote: > We never got around to making a proper ontology for it. Right now > it's > just a string, as far as I know. >> Hi All, >> >> Today I was adding some CrossReference Information Blocks (CRIBs). >> According to the API documentation the xrefType attribute for an Xref >> is "a term from the Cross-Reference-Type Ontology indicating the >> semantic type of this cross-reference". However the documentation >> doesn't provide a link to this Cross-Reference-Type Ontology. I tried >> to Google it, but wasn't successful. Where should I look to figure >> out which xrefTypes are available? It's not part of MOBY Central >> is it? >> >> Cheers, >> >> Pi >> >> >> _______________________________________________ >> 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 Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From martin.senger at gmail.com Tue Aug 22 17:17:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Tue, 22 Aug 2006 14:17:38 -0300 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003c01c6c5fb$facb04b0$6400a8c0@notebook> References: <4d93f07c0608220757h7df86f4fjbf8e2e4f4aec756c@mail.gmail.com> <003c01c6c5fb$facb04b0$6400a8c0@notebook> Message-ID: <4d93f07c0608221017l49a12af3gaf7fcf382eb3b6c0@mail.gmail.com> > I don't think you understand what Mark is trying to say. Imagine the > following > scenario: > 1. Service provider registers a service gets an RDF document back. > 2. Service provider updates RDF and waits for agent to check his > document > 3. In the meantime, someone queries mobycentral for his service > and gets > some information back, while someone queries the LSID resolver and gets > other > information. > > The 2 pieces of information are out of synch. Yes, that's what I understood. And it is okay. Because the registration and the agent visit are separate events, they are not treated together as an atomic event. So this happens. If I register something I expect to get back the same information I put there by registration. Which I do. If a service provider changes something but the change was not yet recognized by a registry (meaning "agent has not been traveling") I cannot see it. It seems correct to me. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Wed Aug 23 13:13:01 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 23 Aug 2006 15:13:01 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> References: <001a01c6c5eb$ede8ef10$6400a8c0@notebook> Message-ID: <200608231513.02249.d.haase@gsf.de> On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > Did you by chance modify the timestamp of your LSID in your RDF? The agent > only modifies the service if the LSID has changed. Unfortunately, this (again) leads to the impossibility to deregister a service: if you delete an RDF, you cannot change the LSID, if you provide a changed LSID, you cannot delete the RDF. I also tried an RDF with modified LSID but no operation specified, but no success: the service remains listed (with old LSID...). Does this mean de-registration still only via the Eddie-Agent? Best, dirk From edward.kawas at gmail.com Wed Aug 23 13:54:24 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 23 Aug 2006 06:54:24 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608231513.02249.d.haase@gsf.de> Message-ID: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> Hi Dirk, To remove a service, call the agent via registerService using only the signatureURL. If the URL exists, then any services the agent finds will be updated/removed/added. If the url doesn't exist, then the agent will remove any services that it once knew about at that URL. I am not sure if what I just said addresses your concerns. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, August 23, 2006 6:13 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Tuesday 22 August 2006 15:07, Edward Kawas wrote: > > Did you by chance modify the timestamp of your LSID in your > RDF? The > > agent only modifies the service if the LSID has changed. > > Unfortunately, this (again) leads to the impossibility to deregister a > service: if you delete an RDF, you cannot change the LSID, if > you provide a changed LSID, you cannot delete the RDF. I also > tried an RDF with modified LSID but no operation specified, > but no success: the service remains listed (with old LSID...). > > Does this mean de-registration still only via the Eddie-Agent? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Wed Aug 23 14:19:03 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 23 Aug 2006 16:19:03 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> References: <002a01c6c6bb$a4fa02f0$6700a8c0@notebook> Message-ID: <200608231619.03563.d.haase@gsf.de> On Wednesday 23 August 2006 15:54, Edward Kawas wrote: > Hi Dirk, > > To remove a service, call the agent via registerService using only the > signatureURL. If the URL exists, then any services the agent finds will be > updated/removed/added. If the url doesn't exist, then the agent will remove > any services that it once knew about at that URL. That's how I understood the mechanism and what the docs say... > I am not sure if what I just said addresses your concerns. In principle yes, but what I wanted to say is that the removal part of it does not work. An example is the mips service getTmhmmPrediction which is registered with the signature URL http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf This URL currently does not exist. I successfully called the agent, but the service is not deleted. Same situation for the gabi.rzpd.de service checkGabiPDBySequence. Best, dirk From edward.kawas at gmail.com Wed Aug 23 14:26:27 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 23 Aug 2006 07:26:27 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608231619.03563.d.haase@gsf.de> Message-ID: <003901c6c6c0$1f8be480$6700a8c0@notebook> Hi Dirk, The agent was misconfigured (I had it so that the agent would not remove anything from the registry). You can try again and I am sure it will work. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, August 23, 2006 7:19 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 15:54, Edward Kawas wrote: > > Hi Dirk, > > > > To remove a service, call the agent via registerService > using only the > > signatureURL. If the URL exists, then any services the agent finds > > will be updated/removed/added. If the url doesn't exist, then the > > agent will remove any services that it once knew about at that URL. > > That's how I understood the mechanism and what the docs say... > > > I am not sure if what I just said addresses your concerns. > > In principle yes, but what I wanted to say is that the > removal part of it does not work. An example is the mips > service getTmhmmPrediction which is registered with the > signature URL > http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf > This URL currently does not exist. I successfully called the > agent, but the service is not deleted. Same situation for the > gabi.rzpd.de service checkGabiPDBySequence. > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Fri Aug 25 07:54:03 2006 From: d.haase at gsf.de (Dirk Haase) Date: Fri, 25 Aug 2006 09:54:03 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <003901c6c6c0$1f8be480$6700a8c0@notebook> References: <003901c6c6c0$1f8be480$6700a8c0@notebook> Message-ID: <200608250954.03591.d.haase@gsf.de> On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > Hi Dirk, > > The agent was misconfigured (I had it so that the agent would not remove > anything from the registry). You can try again and I am sure it will work. Yes, great, now it works, thank you. BUT: in turn, changes within the RDF are not written to the database anymore either with or without LSID modification. Of course I can now change everything by de-register, change RDF, re-register. But this involves the danger of modifying the service but not the LSID - which I think is against the LSID specification, right? Best, dirk From Pieter.Neerincx at wur.nl Fri Aug 25 11:12:58 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 13:12:58 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 In-Reply-To: <1154976083.44d78953058fb@webmail.cs.umu.se> References: <1154976083.44d78953058fb@webmail.cs.umu.se> Message-ID: Hi Johan et al., Thank you very much for the updated proposal! It took me a few days to read the proposal and all the referenced standards, so I can imagine it took you quite some time to put this together. I think the big picture looks good, but I do have a few small comments / questions. I'll send them one comment / e-mail in order prevent mixed up discussions and lengthy e-mails... Thanks, Pi On 7-Aug-2006, at 8:41 PM, Johan Karlsson wrote: > Hello, > > Attached to this email you can find an updated version (2.2) of the > INB proposal > for asynchronous services. > > We have added some things that were suggested during the > discussions and changed > some wordings to make it more clear what is intended. Please see > summary in the > end of this letter for the main changes. We are very grateful for > earlier > comments and suggestions and hope for more. If there is something > we missed to > update from the earlier discussion, please let us know. > > The great difference from the earlier public version is that we are > now using an > OASIS standard, the Web Services Resource Framework (WSRF), to > communicate > status and results. The main reason is that the polling approach > that we are > advocating requires that the web-service in question maintains some > sort of > state and WSRF is exactly intended to provide a standardised way to > handle > this. > > We realise that WSRF might be a new experience for many BioMOBY- > developers and > therefore we have developed some functions to simplify > implementation of > asynchronous services and clients (in Perl) and a prototype to > illustrate their > use. In fact, to write a basic asynchronous BioMOBY service with > the library is > not much different compared to how it is done for synchronous > services (see > HelloWorld.pm). > > More details about the modules and the prototype here: > > http://bioinfo.pcm.uam.es/prototype/ > > There you can also find an example of a WSDL (mentioned in the > document but not > included as appendix for reasons of readability). The parts > relating to WSRF > would have to be added to the WSDL that MobyCentral generates today. > > Let us restart the discussions and reach an agreement soon, > asynchronous > services/clients are definitely needed. Should we set as a goal to > reach a > decision on the RFC by the end of August? > > Suggestions/improvements and comments for both the proposal and the > modules are > greatly welcomed. > > Summary of major changes in the document: > > - WSRF to communicate state information instead of MobyStatus > - It is possible to retrieve results or status for specific > mobyData inputs > ("jobs") > - Better descriptions of job and batch-call > - More descriptions of the error-cases > - Updated information about how to describe async services in RDF > (Mark, can you please double-check this, we need a Boolean > value for this) > - The category field from findService output will have four > allowed values > 'moby', 'moby-async', 'cgi' and 'soap'. > - The SOAP method to start a call is now called > servicename_submit (before > servicename_async) > > Apologies for the long delay but there has been some fundamental > changes that > required some study and implementation. > > Warm greetings from Malaga, > Johan Karlsson, GNV5 > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Aug 25 11:45:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 13:45:39 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <1154976083.44d78953058fb@webmail.cs.umu.se> References: <1154976083.44d78953058fb@webmail.cs.umu.se> Message-ID: <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> Hi all, The proposal contains some example XML for GetReourceProperty and GetMultipleResourceProperties requests. On page 12 there are the requests to poll for service execution status and on page 13/14 for service results. If I understood correctly these requests for resource properties MUST contain a tag in the SOAP header according to the WSRF standard. So I think the XML should look like this: SOAP XML requests to poll for service execution status: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . status_queryId00 Or for retrieving multiple resource properties in one go: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetMultipleResourceProperties/GetMultipleResourcePropertiesRequest . . . status_queryId00 status_queryId01 . . . Similarly http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse and http://docs.oasis-open.org/wsrf/rpw-2/ GetMultipleResourceProperties/GetMultipleResourcePropertiesResponse MUST be added to the responses for the requests. Furthermore the same tags should be added to requests and responses to retrieve the results. Or did I get these standards documents wrong? The BioMOBY Async proposal was very readable, but I have to admit the WSRF, WS Addressing and LSAE docs drove me nuts sometimes... Cheers, Pi From Pieter.Neerincx at wur.nl Fri Aug 25 12:08:06 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 14:08:06 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - xmlns:rpimpl ? Message-ID: <3A58B4C7-BCE8-4EB9-95F4-4135833F8DD6@wur.nl> Hi all, The BioMOBY Async services proposal introduces the tag as a wsa:ReferenceParameter. In all the examples this tag is put in the "rpimpl" namespace, but I was wondering: shouldn't this be in our own "moby" namespace. According to the "Web Services Resource Framework (WSRF) ? Primer v1.2" document rpimpl = Schema definition for implementation- dependent WS-Addressing reference parameters. Please note that this document is a "committee draft" and it's not a "standard" yet. I can not find any references to the rpimpl namespace in any of the documents describing the latest WS-A core, WS-A SOAP binding, WS- Resource and WS-ResourceProperties standards. As far as I can tell we can simply use . Cheers, Pi From Pieter.Neerincx at wur.nl Fri Aug 25 12:27:38 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 25 Aug 2006 14:27:38 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? Message-ID: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> Hi all, The WS-Addressing 1.0 SOAP Binding specifies that reference parameters that are used in a SOAP Header MUST have the wsa:IsReferenceParameter parameter with the value true. This is currently missing from the BioMOBY Async services proposal. Hence, if we use our "ticket" as a reference parameter in a and this ticket is used to poll for service status the tag should look like this: . . . http://myserver.com/MyService ID http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . status_queryId00 wsa:IsReferenceParameter attribute also needs to be added to the XML for other requests to get resource properties and to the XML for the destroy request. Cheers, Pi From johan at ac.uma.es Fri Aug 25 14:31:59 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 25 Aug 2006 16:31:59 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> Message-ID: <44EF09DF.6020808@ac.uma.es> Hi Pieter (and thanks for the comments)! Pieter Neerincx wrote: > Hi all, > > The proposal contains some example XML for GetReourceProperty and > GetMultipleResourceProperties requests. On page 12 there are the > requests to poll for service execution status and on page 13/14 for > service results. If I understood correctly these requests for > resource properties MUST contain a tag in the SOAP > header according to the WSRF standard. So I think the XML should look > like this: > > SOAP XML requests to poll for service execution status: > > > > . . . > http://myserver.com/MyService > ID > http://docs.oasis-open.org/wsrf/rpw-2/ > GetResourceProperty/GetResourcePropertyRequest > . . . > > > status_queryId00 > > > I think you are completely right about the missing wsa:Action, we must have missed to put it in the document... it does appear messages the prototype sends but with a slightly different URL: http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties/GetResourcePropertyResponse However, I think this comes from the WSRF::Lite version we use. We will check and let you know more. > Or did I get these standards documents wrong? The BioMOBY Async > proposal was very readable, but I have to admit the WSRF, WS > Addressing and LSAE docs drove me nuts sometimes... > I totally agree, the WRSF and WS-adressing documents are not light reading... :-) Kind regards, Johan From edward.kawas at gmail.com Fri Aug 25 15:00:58 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 25 Aug 2006 08:00:58 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608250954.03591.d.haase@gsf.de> Message-ID: <005301c6c857$466b39a0$6400a8c0@notebook> Hi Dirk, Changes that are found should be reflected in the registry if there are updates. Can you pass along the url that isn't working for you so I can try it? As for LSIDs, don't worry too much about them right now. The agent now should not be worrying about LSIDs. The registry is the only one that should be updating the LSID and now the agent takes that into account. I know that I said that LSIDs were important a few messages back, but now I retract those comments! Give it a try again and then let me know what happens. If the agent fails to update your services please just send me the URL and I will try to see what is happening. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Friday, August 25, 2006 12:54 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > Hi Dirk, > > > > The agent was misconfigured (I had it so that the agent would not > > remove anything from the registry). You can try again and I > am sure it will work. > > Yes, great, now it works, thank you. BUT: in turn, changes > within the RDF are not written to the database anymore either > with or without LSID modification. > > Of course I can now change everything by de-register, change > RDF, re-register. > But this involves the danger of modifying the service but not > the LSID - which I think is against the LSID specification, right? > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Fri Aug 25 16:44:42 2006 From: d.haase at gsf.de (Haase, Dirk) Date: Fri, 25 Aug 2006 18:44:42 +0200 Subject: [MOBY-dev] Agent does not change Registry References: <005301c6c857$466b39a0$6400a8c0@notebook> Message-ID: <1D78CE9FD586024AB0E0102F6F9A7CF86A0892@sw-rz010.gsf.de> Hi Eddie, it is still the same service which I'm playing around with: getTmhmmPrediction with the URL http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf. I changed the contact email, called the agent but could not see it in the registry (I used dashboard as browser and did reload before I checked...). Currently this RDF and registry are in sync, because I had totally un-registered it and the re-submitted the rdf, so there is not much to see now... Unfortunately I'm already out of office, so I can't do anything about it now. Nice Weekend, dirk -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Edward Kawas Sent: Fri 8/25/2006 5:00 PM To: 'Core developer announcements' Subject: Re: [MOBY-dev] Agent does not change Registry Hi Dirk, Changes that are found should be reflected in the registry if there are updates. Can you pass along the url that isn't working for you so I can try it? As for LSIDs, don't worry too much about them right now. The agent now should not be worrying about LSIDs. The registry is the only one that should be updating the LSID and now the agent takes that into account. I know that I said that LSIDs were important a few messages back, but now I retract those comments! Give it a try again and then let me know what happens. If the agent fails to update your services please just send me the URL and I will try to see what is happening. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Friday, August 25, 2006 12:54 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > Hi Dirk, > > > > The agent was misconfigured (I had it so that the agent would not > > remove anything from the registry). You can try again and I > am sure it will work. > > Yes, great, now it works, thank you. BUT: in turn, changes > within the RDF are not written to the database anymore either > with or without LSID modification. > > Of course I can now change everything by de-register, change > RDF, re-register. > But this involves the danger of modifying the service but not > the LSID - which I think is against the LSID specification, right? > > Best, > dirk > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3962 bytes Desc: not available URL: From edward.kawas at gmail.com Fri Aug 25 17:26:21 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 25 Aug 2006 10:26:21 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <1D78CE9FD586024AB0E0102F6F9A7CF86A0892@sw-rz010.gsf.de> Message-ID: <006001c6c86b$9615e130$6400a8c0@notebook> Hi Dirk, Another tool you can use to visualize the service is the lsid resolver: http://mobycentral.icapture.ubc.ca/LSID_resolver.html. This always returns the latest metadata. Maybe on Monday, you could add a space to the description or something like that and then call the agent and tell me if things went smoothly. I don't see why it isnt working for you other than the fact that there just might be a problem with the RDF. Anyways, I am going to check the logs and if I see something weird I will let you know. Thanks for your patience! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Haase, Dirk > Sent: Friday, August 25, 2006 9:45 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Eddie, > > it is still the same service which I'm playing around with: > getTmhmmPrediction with the URL > http://mips.gsf.de/proj/planet/moby/RDF/getTmhmmPrediction.rdf. > I changed the contact email, called the agent but could not > see it in the registry (I used dashboard as browser and did > reload before I checked...). > > Currently this RDF and registry are in sync, because I had > totally un-registered it and the re-submitted the rdf, so > there is not much to see now... > Unfortunately I'm already out of office, so I can't do > anything about it now. > > Nice Weekend, > dirk > > > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org on behalf of Edward Kawas > Sent: Fri 8/25/2006 5:00 PM > To: 'Core developer announcements' > Subject: Re: [MOBY-dev] Agent does not change Registry > > Hi Dirk, > > Changes that are found should be reflected in the registry if > there are updates. > Can you pass along the url that isn't working for you so I can try it? > > As for LSIDs, don't worry too much about them right now. The > agent now should not be worrying about LSIDs. The registry is > the only one that should be updating the LSID and now the > agent takes that into account. I know that I said that LSIDs > were important a few messages back, but now I retract those comments! > > Give it a try again and then let me know what happens. If the > agent fails to update your services please just send me the > URL and I will try to see what is happening. > > Thanks, > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Friday, August 25, 2006 12:54 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] Agent does not change Registry > > > > On Wednesday 23 August 2006 16:26, Edward Kawas wrote: > > > Hi Dirk, > > > > > > The agent was misconfigured (I had it so that the agent would not > > > remove anything from the registry). You can try again and I > > am sure it will work. > > > > Yes, great, now it works, thank you. BUT: in turn, changes > within the > > RDF are not written to the database anymore either with or without > > LSID modification. > > > > Of course I can now change everything by de-register, change RDF, > > re-register. > > But this involves the danger of modifying the service but > not the LSID > > - which I think is against the LSID specification, right? > > > > Best, > > dirk > > _______________________________________________ > > 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 > > From martin.senger at gmail.com Fri Aug 25 23:21:15 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 25 Aug 2006 20:21:15 -0300 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44EF09DF.6020808@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> Message-ID: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Sorry, I was not able to read the new proposal when it came. I am still not able to read it in all details (I am traveling and will be actually completely off-line next two weeks) - but I think that the proposal is fine and I would for with it. Thanks for creating it. Just two comments: I agree that storing the fact that a service is able to be called asynchronously should be part of the service registration process. That would simplify everything. But I do not fully understand why it cannot be done only by registering a service with a new category (moby-async, as suggested). Why do we need a new boolean parameter for it? Why do we need 'hasCallingDetail" - here again a new category should be enough. What am I missing? The second comment is more or less political (and I do not mean it as an argument against your proposal, I like your proposal): So far, the BioMoby did not use anything from the web services protocol. Well, the registry generated WSDL but this WSDL was not that useful. Which lead me recently to the idea that the new BioMoby (sometimes called Moby2) may abandon the SOAP completely, and to stick with the REST architecture. Mainly because of better future collaboration with the S-Moby (the semantic guys in Sante Fe will never accept SOAP - my personal feeling). So now going actually closer to the web services standards may again put us further from them. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Sat Aug 26 12:44:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 26 Aug 2006 05:44:36 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 In-Reply-To: <44EF09DF.6020808@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> Message-ID: >> > I totally agree, the WRSF and WS-adressing documents are not light > reading... :-) Yeah, I thought they lacked examples... Unfortunately, it doesn't look like there has been much up-take of this "standard" by many people so far, so there's a dearth of resources out there on the Web to look at or copy. I prefer to see the final product and dissect it rather than attempt to build the final product from the documentation... but that's the geneticist in me ;-) ;-) I'm glad this is moving forward, though! Hopefully this can get adopted quickly and we can push MOBY 1.0 out the door! M From markw at illuminae.com Sat Aug 26 13:12:09 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 26 Aug 2006 06:12:09 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: v.v. the political statement: I strongly agree with Martin, in part, and somewhat agree with him in another part :-) My personal opinion on the Pseudo-Web Services approach that MOBY uses is that it has been more of a barrier than a benefit. I don't think this is a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the WS architecture itself is not quite as useful as it was marketed to be in past years. In this regard, moving toward a REST-style architecture for "MOBY 2" is something I am strongly in favour of because it seems like the right thing to do, especially in the emergent Semantic Web world; the fact that it also moves us closer to the S-MOBY architecture is just icing :-) however, v.v. the asynchronous services proposal, I think we have to lie in the bed we have made at least for the time being. Fixing one of the most troublesome aspects of the current MOBY protocol in the short term for the wider community, while having the core developers explore what MOBY 2.0 "looks like", seems to me like a good idea, and especially if the proponents of the asynch proposal are building/have built the tooling for us already. So, given that MOBY is already married to SOAP, it doesn't concern me too much if we add another SOAPy component to it. It's a shame that the WSRF framework itself isn't more widely used, but if it does what we need it to do we might as well take advantage of it. Just my opinion... but I'm on holiday, so I'm only using a small part of my brain to think about it :-) Mark On Fri, 25 Aug 2006 16:21:15 -0700, Martin Senger wrote: > Sorry, I was not able to read the new proposal when it came. I am still > not > able to read it in all details (I am traveling and will be actually > completely off-line next two weeks) - but I think that the proposal is > fine > and I would for with it. Thanks for creating it. > > Just two comments: > > I agree that storing the fact that a service is able to be called > asynchronously should be part of the service registration process. That > would simplify everything. But I do not fully understand why it cannot be > done only by registering a service with a new category (moby-async, as > suggested). Why do we need a new boolean parameter for it? Why do we need > 'hasCallingDetail" - here again a new category should be enough. What am > I > missing? > > The second comment is more or less political (and I do not mean it as an > argument against your proposal, I like your proposal): > > So far, the BioMoby did not use anything from the web services protocol. > Well, the registry generated WSDL but this WSDL was not that useful. > Which > lead me recently to the idea that the new BioMoby (sometimes called > Moby2) > may abandon the SOAP completely, and to stick with the REST architecture. > Mainly because of better future collaboration with the S-Moby (the > semantic > guys in Sante Fe will never accept SOAP - my personal feeling). So now > going > actually closer to the web services standards may again put us further > from > them. > > Cheers, > Martin > From tmo at ebi.ac.uk Sat Aug 26 16:12:25 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Sat, 26 Aug 2006 17:12:25 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: <44F072E9.5050206@ebi.ac.uk> Mark Wilkinson wrote: > v.v. the political statement: I strongly agree with Martin, in part, and > somewhat agree with him in another part :-) > > My personal opinion on the Pseudo-Web Services approach that MOBY uses is > that it has been more of a barrier than a benefit. I don't think this is > a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the > WS architecture itself is not quite as useful as it was marketed to be in > past years. In this regard, moving toward a REST-style architecture for > "MOBY 2" is something I am strongly in favour of because it seems like the > right thing to do, especially in the emergent Semantic Web world; the fact > that it also moves us closer to the S-MOBY architecture is just icing :-) One thing to consider here is that you're potentially missing out on the additional capabilities you can inherit from a web service platform. I tend to agree with both you and Martin on this (Martin has sat next to me in an office for some years and so should know my generally low opinion of the current state of the web service world!). Where WS can really come into their own is their ability to add aspects such as security and robust message transport without any additional effort from the MOBY community. It might be worth taking a look at the work we've been doing with OMII-UK (the umbrella organization in the UK which has in the last year absorbed both myGrid and OGSA-DAI). They (we?) have a container configuration with support for WS-Security (certificate based authentication) and will support its use in escience projects. Use of WS 'standards' incurs a cost, both in initial development time and in runtime complexity. It potentially reaps a benefit if you go on to make use of the full suite (or a substantial subset) of additional capabilities such as security, WSRF style session management, full message description and the like. Before dropping WS invocation support entirely you need to consider the potential future requirements that it might fill more easily than a home grown implementation. There is of course always the political aspect - we've already had people say "we can't use taverna as, although it works and does what we want, it isn't a 'standard'". Sad but true. This isn't an exclusive choice of course, you could (and maybe should) have a simple REST-like invocation interface alongside a more complex and potentially extensible SOAP based one. Just my thoughts, Tom From d.haase at gsf.de Mon Aug 28 09:24:48 2006 From: d.haase at gsf.de (Dirk Haase) Date: Mon, 28 Aug 2006 11:24:48 +0200 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <006001c6c86b$9615e130$6400a8c0@notebook> References: <006001c6c86b$9615e130$6400a8c0@notebook> Message-ID: <200608281124.48555.d.haase@gsf.de> On Friday 25 August 2006 19:26, Edward Kawas wrote: > Maybe on Monday, you could add a space to the description or something like > that and then call the agent and tell me if things went smoothly. I don't > see why it isnt working for you other than the fact that there just might > be a problem with the RDF. Anyways, I am going to check the logs and if I > see something weird I will let you know. OK, I tried some modifications this morning and everything went well. I think, on Friday, I was bluffed by the dashboard which does an auto-reload after the agent call, but obviously first checks the LSID version and gets the service details from MOBY Central only if that had changed (which actually does make sense...). This still does not explain why certain changes were not displayed despite a LSID version update, but important is only that it does work now... > Thanks for your patience! Thanks for yours ;-) dirk From johan at ac.uma.es Mon Aug 28 11:06:18 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 28 Aug 2006 13:06:18 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? In-Reply-To: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> References: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> Message-ID: <44F2CE2A.3080806@ac.uma.es> Pieter, You are right, in fact, the prototype also contains this "isReferenceParameter" attribute. It seems that we missed to include this in the examples of the proposal. Kind regards, Johan Pieter Neerincx wrote: > Hi all, > > The WS-Addressing 1.0 SOAP Binding specifies that reference > parameters that are used in a SOAP Header MUST have the > wsa:IsReferenceParameter parameter with the value true. This is > currently missing from the BioMOBY Async services proposal. > > Hence, if we use our "ticket" as a > reference parameter in a and this ticket is > used to poll for service status the tag > should look like this: > > > > . . . > http://myserver.com/MyService > ID moby:ServiceInvocationId> > http://docs.oasis-open.org/wsrf/rpw-2/ > GetResourceProperty/GetResourcePropertyRequest > . . . > > > status_queryId00 > > > > wsa:IsReferenceParameter attribute also needs to be added to the XML > for other requests to get resource properties and to the XML for the > destroy request. > > Cheers, > > Pi > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From Pieter.Neerincx at wur.nl Mon Aug 28 11:43:34 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 13:43:34 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - wsa:IsReferenceParameter='true' attribute missing ? In-Reply-To: <44F2CE2A.3080806@ac.uma.es> References: <57432941-0EB3-4BC3-8FF0-5A7118DA12DA@wur.nl> <44F2CE2A.3080806@ac.uma.es> Message-ID: <772951DD-0BA8-406B-A7F5-3BE85C3D9724@wur.nl> Hi Johan, On 28-Aug-2006, at 1:06 PM, Johan Karlsson wrote: > Pieter, > > You are right, in fact, the prototype also contains this > "isReferenceParameter" attribute. Ok, I have to admit I didn't run the prototype yet. I Just tried to understand the proposal from the docs :). Cheers, Pi > > It seems that we missed to include this in the examples of the > proposal. > > Kind regards, > Johan > > Pieter Neerincx wrote: >> Hi all, >> >> The WS-Addressing 1.0 SOAP Binding specifies that reference >> parameters that are used in a SOAP Header MUST have the >> wsa:IsReferenceParameter parameter with the value true. This is >> currently missing from the BioMOBY Async services proposal. >> >> Hence, if we use our "ticket" as a >> reference parameter in a and this ticket is >> used to poll for service status the tag >> should look like this: >> >> >> >> . . . >> http://myserver.com/MyService >> ID> moby:ServiceInvocationId> >> http://docs.oasis-open.org/wsrf/rpw-2/ >> GetResourceProperty/GetResourcePropertyRequest >> . . . >> >> >> status_queryId00 >> >> >> >> wsa:IsReferenceParameter attribute also needs to be added to the XML >> for other requests to get resource properties and to the XML for the >> destroy request. >> >> Cheers, >> >> Pi >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Mon Aug 28 12:47:29 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 14:47:29 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - Politics In-Reply-To: <44F072E9.5050206@ebi.ac.uk> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> Message-ID: <4BA2F610-2BBB-47A2-BC75-50AE2FE7A21E@wur.nl> Hi, I'm lost; I honestly don't know who to agree with on this one. What impact exactly do the political statements below have on the BioMOBY Async Services proposal? Is WSRF bad? If so, do we have an alternative that actually works today (Ok, maybe tomorrow, but at least soon). If we can polish the proposal a little and make it forward compatible with BioMOBY 2.0 that would be great, but unless we see a proposal for that popping up in the next week, I suggest we save the politics for a discussion about BioMOBY 2.0 during a future meeting and start using standardised asynchronous services a.s.a.p. The thing I like most about BioMOBY is that it actually works for me today even though the API hasn't reached a 1.0 status yet :). Just my ? 0,02 Pi On 26-Aug-2006, at 6:12 PM, Tom Oinn wrote: > Mark Wilkinson wrote: >> v.v. the political statement: I strongly agree with Martin, in >> part, and >> somewhat agree with him in another part :-) >> >> My personal opinion on the Pseudo-Web Services approach that MOBY >> uses is >> that it has been more of a barrier than a benefit. I don't think >> this is >> a consequence of MOBY not using all of SOAP/WSDL, I feel it is >> because the >> WS architecture itself is not quite as useful as it was marketed >> to be in >> past years. In this regard, moving toward a REST-style >> architecture for >> "MOBY 2" is something I am strongly in favour of because it seems >> like the >> right thing to do, especially in the emergent Semantic Web world; >> the fact >> that it also moves us closer to the S-MOBY architecture is just >> icing :-) > > One thing to consider here is that you're potentially missing out > on the > additional capabilities you can inherit from a web service platform. I > tend to agree with both you and Martin on this (Martin has sat next to > me in an office for some years and so should know my generally low > opinion of the current state of the web service world!). > > Where WS can really come into their own is their ability to add > aspects > such as security and robust message transport without any additional > effort from the MOBY community. It might be worth taking a look at the > work we've been doing with OMII-UK (the umbrella organization in > the UK > which has in the last year absorbed both myGrid and OGSA-DAI). They > (we?) have a container configuration with support for WS-Security > (certificate based authentication) and will support its use in > escience > projects. > > Use of WS 'standards' incurs a cost, both in initial development time > and in runtime complexity. It potentially reaps a benefit if you go on > to make use of the full suite (or a substantial subset) of additional > capabilities such as security, WSRF style session management, full > message description and the like. Before dropping WS invocation > support > entirely you need to consider the potential future requirements > that it > might fill more easily than a home grown implementation. There is of > course always the political aspect - we've already had people say "we > can't use taverna as, although it works and does what we want, it > isn't > a 'standard'". Sad but true. > > This isn't an exclusive choice of course, you could (and maybe should) > have a simple REST-like invocation interface alongside a more complex > and potentially extensible SOAP based one. > > Just my thoughts, > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Mon Aug 28 13:28:39 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 28 Aug 2006 06:28:39 -0700 Subject: [MOBY-dev] Agent does not change Registry In-Reply-To: <200608281124.48555.d.haase@gsf.de> Message-ID: <001701c6caa5$e08eb020$6400a8c0@notebook> Hi Dirk, I am glad to hear that its working! Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Monday, August 28, 2006 2:25 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Agent does not change Registry > > On Friday 25 August 2006 19:26, Edward Kawas wrote: > > Maybe on Monday, you could add a space to the description > or something > > like that and then call the agent and tell me if things > went smoothly. > > I don't see why it isnt working for you other than the fact > that there > > just might be a problem with the RDF. Anyways, I am going > to check the > > logs and if I see something weird I will let you know. > > OK, I tried some modifications this morning and everything > went well. I think, on Friday, I was bluffed by the dashboard > which does an auto-reload after the agent call, but obviously > first checks the LSID version and gets the service details > from MOBY Central only if that had changed (which actually > does make sense...). This still does not explain why certain > changes were not displayed despite a LSID version update, but > important is only that it does work now... > > > Thanks for your patience! > > Thanks for yours ;-) > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Mon Aug 28 14:00:55 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 28 Aug 2006 16:00:55 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - The location of queryIDs Message-ID: Hi all, I really like the GetResourceProperty, GetMultipleResourceProperties and the Destroy methods/services in the new proposal. With the previous proposal a service provider had to write a service to get the status, one to get the results and one to delete the results for each async submit service. The logic to submit a job might be quite different for different tools, but the logic to get the status of a submitted job, to get the results or to trash a job can be exactly the same for many different tools. Therefore I like the idea of reducing redundancy by implementing only one GetResourceProperty, one GetMultipleResourceProperties and one Destroy service for all the async submit services I might want to develop. There is only one thing that I don't like about the current proposal: the location of queryID. For our current synchronous services it's an attribute of the mobyData element. In the current async services proposal the queryID jumps around the XML taking several identities: * in status_queryID01 it is part of raw text. * in it is part of an element name in the lsae namespace. (By the way: Should this element really be in the lsae namespace? I don't think our status_queryIDxx elements are part of the LSAE specs...) * in result_queryID01 it is part of raw text. * in it is part of an element name in the moby namespace. * in as an attribute. Although this might work it, I think it is confusing and if I got the specs correct it also makes life more complicated than necessary. 1. When I submit an async job, the proposed result contains a ServiceInvocationID that identifies the complete batch, but the queryIDs of the individual jobs are not listed in this result. When I want to retrieve the status, retrieve the results or destroy the jobs I do need these queryIDs though. This means that as a client I have to keep track of the queryIDs. I'm not sure how it works for the Java guys, but as I Perl guy I usually don't have to worry about the queryIDs. I don't create them myself, they are automatically created when I submit data to a service using the BioMOBY Perl modules. With the current proposal I would have parse the XML again to get the queryIDs, I would have to store them locally and finally merge this information with the ticket (ServiceInvocationID) I got back from the service to create a request to get the status or results. It would be much more convenient if the result from a asynchronous service invocation would contain both the ServiceInvocationID *AND* the associated queryIDs. In that case I only have to parse the service response to create GetResourceProperty requests. Therefore I propose to supply the queryIDs as wsa:ReferenceParameters just like the ServiceInvocationID. 2. WSRF contains an *optional* method to request a resource properties document. With this method a client can figure out which resource properties are available and hence what it can request. Although this method is optional and the current proposal doesn't mention it, I think it would good to keep the option open to supply such a method. WSRF does not put any limitations on how a service generates and provides such a document, so you can generate it dynamically or it can be a static thing. If we would want to supply such a resource properties document in the future it would be the easiest if it can be a static one. However in the current proposal the queryIDs are part of the resource properties (status_queryIDxx and result_queryIDxx). This means that the available resource properties depend on the amount of queries/jobs that were sent to a service and hence we can not use a static resource properties document. It would be more convenient if we can strip the queryIDs from the resource properties and provide them as wsa:ReferenceParameters. In that case there are only two resource properties (status and result) and we can describe those in a static resource properties document. 3. Because of the queryID merged with the "result" resource property, the result from a asynchronous service contains a bit of redundancy in the current proposal. The queryID is supplied twice: once in and once in . Furthermore because of the queryID merged to the result resource property the and tags have to be repeated for each queryID. Therefore the results are slightly different as compared to results from a synchronous service where and are present only once. If the queryIDs are stripped from the result resource property and supplied as wsa:ReferenceParameters, the results can be more similar the synchronous service output with only one "result" tag, one tag and one tag for one or more blocks. Therefore I propose a translocation of BioMOBY queryIDs from the resource properties to wsa:ReferenceParameters. As far as I understand, with all the specifications involved this would be legal, but please correct me if I am wrong. Below I included some examples of what the XML might look like when the queryIDs are moved to the SOAP header as wsa:ReferenceParameters. Let me know what you think.... Cheers, Pi Response for accepted asynchronous service execution: . . . http://myserver.com/MyService . . . GetResourceProperty request to poll for service execution status: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . . . . moby:ServiceInvocationStatus GetResourceProperty response for polling request: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse . . . GetResourceProperty request for the result: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyRequest . . . . . . moby:ServiceInvocationResult GetResourceProperty response for requesting results: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rpw-2/ GetResourceProperty/GetResourcePropertyResponse . . . . . . Request for destroying the resource: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rlw-2/ ImmediateResourceTermination/DestroyRequest . . . Response for destroying the resource: . . . http://myserver.com/MyService http://docs.oasis-open.org/wsrf/rlw-2/ ImmediateResourceTermination/DestroyResponse . . . From gordonp at ucalgary.ca Mon Aug 28 14:04:08 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 28 Aug 2006 08:04:08 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44F072E9.5050206@ebi.ac.uk> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> Message-ID: <44F2F7D8.1050905@ucalgary.ca> I agree with Tom: the most important part of using a layer like WS is the features you *haven't* thought of. Logical separation of program parts always incurs an overhead, but 1) frees the developer from tinkering with a "solved" problem, and 2) allows him/her to benefit from features they hadn't anticipated. I'll be really happy when a security payer can be automagically added to MOBY via some WS protocol... With regards to Martin's mail, I don't think usurping the Service type is a good idea (if I understand the idea correctly, which I may not). The Service Type Ontology is supposed to describe the service in biological terms, the fact that it executes asynchronously is a technical consideration (imagine doubling the size of the ontology because one half has to inherit from moby-async :-P) . > Mark Wilkinson wrote: > >> v.v. the political statement: I strongly agree with Martin, in part, and >> somewhat agree with him in another part :-) >> >> My personal opinion on the Pseudo-Web Services approach that MOBY uses is >> that it has been more of a barrier than a benefit. I don't think this is >> a consequence of MOBY not using all of SOAP/WSDL, I feel it is because the >> WS architecture itself is not quite as useful as it was marketed to be in >> past years. In this regard, moving toward a REST-style architecture for >> "MOBY 2" is something I am strongly in favour of because it seems like the >> right thing to do, especially in the emergent Semantic Web world; the fact >> that it also moves us closer to the S-MOBY architecture is just icing :-) >> > > One thing to consider here is that you're potentially missing out on the > additional capabilities you can inherit from a web service platform. I > tend to agree with both you and Martin on this (Martin has sat next to > me in an office for some years and so should know my generally low > opinion of the current state of the web service world!). > > Where WS can really come into their own is their ability to add aspects > such as security and robust message transport without any additional > effort from the MOBY community. It might be worth taking a look at the > work we've been doing with OMII-UK (the umbrella organization in the UK > which has in the last year absorbed both myGrid and OGSA-DAI). They > (we?) have a container configuration with support for WS-Security > (certificate based authentication) and will support its use in escience > projects. > > Use of WS 'standards' incurs a cost, both in initial development time > and in runtime complexity. It potentially reaps a benefit if you go on > to make use of the full suite (or a substantial subset) of additional > capabilities such as security, WSRF style session management, full > message description and the like. Before dropping WS invocation support > entirely you need to consider the potential future requirements that it > might fill more easily than a home grown implementation. There is of > course always the political aspect - we've already had people say "we > can't use taverna as, although it works and does what we want, it isn't > a 'standard'". Sad but true. > > This isn't an exclusive choice of course, you could (and maybe should) > have a simple REST-like invocation interface alongside a more complex > and potentially extensible SOAP based one. > > Just my thoughts, > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev >