soaplab-two-dev Mailing List for Soaplab (Page 3)
Brought to you by:
marsenger
Menu
▾
▴
soaplab-two-dev — New Generation of Soaplab
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(25) |
Jun
(17) |
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Mahmut U. <ul...@eb...> - 2006-06-02 14:39:22
|
Hi Peter, > In general, what are the reasons to stick with the (more complicated) > rpc/rpc compared to document/literal? I assumed you meant 'rpc/encoded' in the above discussion. The following article is a good source for finding an answer to the above question. http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/ The main advantage of the rpc/encoded style is that the WSDL is as straightforward as it's possible for a WSDL to be. However, the main disadvantage is that it is not WS-I compliant. > Does rpc/rpc provide features, missing in document/literal but > necessary or good to have in Soaplab? Using rpc/encoded style it is possible to reference the same object in more than one place by using the href and the id attributes, so avoiding duplication of data in some cases. Regards, Mahmut |
|
From: Mahmut U. <ul...@eb...> - 2006-06-01 10:07:46
|
Hi Martin, There was a communication between Peter and you sometime ago in the list about using CORBA in the analysis provider plug-in for the command-line tools. I wonder whether you made a final decision on it. We plan to have a short presentation about Soaplab2 next week in an EMBRACE workshop. The presentation will be based on your first email to the Soaplab2 list, and the other emails in the list. I would appreciate it much if you can send any other information that would be included in the presentation. For example, I plan to mention about the change in the version of Axis and the possibility of using document/literal binding style in the derived services. Regards, Mahmut > I mean, with the CORBA applab layer in soaplab1 it was possible to > call a *service* on machine A, while the actual *command* is run on > machine B. This feature is lost, I guess ? If so, is there a way to > mimick that ? > Well, nothing is lost yet :-) And I am aware of the features that the Tomcat/CORBA separation gave us. We may still have a plugin in soaplab2 that allows the same distributive feature (perhaps even written in corba). I will keep this in mind. |
|
From: Mahmut U. <ul...@eb...> - 2006-06-01 09:08:03
|
> The data transfer between Soaplab and Applab is realised with a > HashMap. But this means, that the order of the parameters on the > command-line gets lost. I had a quick look at the Soaplab source code that makes the actual Applab call. It seems that just before Soaplab makes the call the data in the HashMap is converted to an array of org.omg.CosPropertService.Property objects. This suggests that we don't have to store the inputs in a HashMap which doesn't allow multiple values for the same key. Regards, Mahmut |
|
From: Jon I. <ji...@eb...> - 2006-05-31 16:01:49
|
Thanks for the reply I'm not sure myself whether the difference is just conceptual or whether in practice we'll need to work with two different files. It seems sensible for the EMBOSS distibution to include a schema for the current ACD syntax because many projects (other than SOAPLAB) would use it. Whether the distributed schema should be identical to or a subset of the one used in SOAPLAB isn't clear to me yet. I suspect it depends on the number and nature of the differences, requirements of interface developers (some people might only want the EMBOSS part) and the best route for support and maintainance. Presumably the EMBOSS bods will want to extend things as new applications are added to EMBOSS, whereas the SOAPLAP bods will want to extend things as new services are supported, which suggests managing it as a "schema in two parts" could be appropriate. Cheers Jon >> Last thought is that it might be sensible if the XML schema used by SOAPLAB (or indeed >> any interface to EMBOSS) was managed as an extension to the (more basic) ACD-XML schema. >> > You said it already before. I still need to be convinced that there is > a difference between them. If ACD is just for EMBOSS then yes, there will > be a difference, but I considered always to have ACD for any command-line > application - so its XML schema should be actually thye same as the > Soaplab one. > > Cheers, > Martin |
|
From: Peter E. <P....@dk...> - 2006-05-31 15:43:16
|
On Wed, 31 May 2006, Mahmut Uludag wrote: > Do we plan to have a Soaplab2 branch on the Soaplab CVS repository? or > soaplab-dkfz-1 branch will be used for the Soaplab2 development? I think that Soaplab2 deserves its own branch or module. I created the branch, in order to share the code I found useful here in my institute. The code could not go into the main branch, because some changes are incompatible or break the old Soaplab behaviour. Sometimes because, the changes are in fact incompatible, and sometimes just because I did not know how to do it properly in Soaplab (e.g. with configuration options, etc.). (Martin seems to have answered already). Peter |
|
From: Martin S. <se...@eb...> - 2006-05-31 15:40:05
|
> Do we plan to have a Soaplab2 branch on the Soaplab CVS repository? or > soaplab-dkfz-1 branch will be used for the Soaplab2 development? > There will be a new CVS module (not a branch) in the Soaplab sourceforge CVS repository, called Soaplab2. I will re-use there what Peter put, so far, into a branch in the current Soaplab. Martin -- Martin Senger email: mar...@gm... skype: martinsenger |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 15:34:35
|
> > Is there some relation between Peter's work on the soaplab-dkfz-1 branch > > and the Soaplab2 development? > > > Definitely! I have actually a contract working on one project with the > Peter's employer - and we are planning to use there Soaplab2 (it is about > using Soaplab web services to access GRID, such as EEGE). Do we plan to have a Soaplab2 branch on the Soaplab CVS repository? or soaplab-dkfz-1 branch will be used for the Soaplab2 development? Regards, Mahmut |
|
From: Peter E. <P....@dk...> - 2006-05-31 15:34:11
|
On Wed, 31 May 2006, Martin Senger wrote:
> > Martin, do we have any plans to use literal encoding in Soaplab2?
> >
> I do not know. Some times ago I spoke with Peter about it - but I am
> still not sure. Perhaps for derived services.
I changed the derived services to document/literal and left the others to
rpc/rpc.
I am using derived services only, but the Soaplab building process
communicates with /axis/services/AnalysisFactory, and this communication
failed, when I changed the style of non-derived services to
document/literal.
I did not investigate this problem any further.
In general, what are the reasons to stick with the (more complicated)
rpc/rpc compared to document/literal?
Does rpc/rpc provide features, missing in document/literal but
necessary or good to have in Soaplab?
In fact, I don't think that the communication style is an important
issue for Soaplab code. I guess that most, if not all, differences
between those 2 styles can be hidden from Soaplab by Axis.
I believe, it will be easy to make the style configurable to the
site administrator.
I have not commit it to the soaplab-cvs-branch, yet, but I added to my
building process (build.xml) a deployment-descriptor-template, that
contains the information about the style to use by Axis, e.g.:
<service xmlns:tns="{$nsURI}" name="{$xmlFullName}" provider="java:RPC" style="wrapped" use="literal">
<parameter name="wsdlServiceElement" value="{$shortName}Service"/>
<parameter name="allowedMethods" value="runAndWaitFor createAndRun waitFor getStatus getResults"/>
[.....]
</service>
Regards,
Peter
|
|
From: Martin S. <se...@eb...> - 2006-05-31 15:25:44
|
> Is there some relation between Peter's work on the soaplab-dkfz-1 branch > and the Soaplab2 development? > Definitely! I have actually a contract working on one project with the Peter's employer - and we are planning to use there Soaplab2 (it is about using Soaplab web services to access GRID, such as EEGE). Martin -- Martin Senger email: mar...@gm... skype: martinsenger |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 15:17:45
|
> > Martin, do we have any plans to use literal encoding in Soaplab2? > > > I do not know. Some times ago I spoke with Peter about it - but I am > still not sure. Perhaps for derived services. It seems that Peter has already made this change on the soaplab-dkfz-1 branch. Using the modified version for example he generated the following wsdl with the style 'document' ant the use 'literal'. http://genome.dkfz-heidelberg.de/menu/hobit/embapps/wsdl/domainsweep.wsdl Is there some relation between Peter's work on the soaplab-dkfz-1 branch and the Soaplab2 development? Regards, Mahmut |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 14:14:44
|
> > Martin, do we have any plans to use literal encoding in Soaplab2? > > > I do not know. Some times ago I spoke with Peter about it - but I am > still not sure. Perhaps for derived services. Today there was a new message in Taverna developers list with a link to the following page (Guidelines to web service providers). http://www.cs.man.ac.uk/~sowen/files/taverna-manual/guidlines_to_sp.html The guideline says that the preferred binding style for Taverna is Document/literal wrapped. Regards, Mahmut |
|
From: Martin S. <se...@eb...> - 2006-05-31 14:05:43
|
> Martin, do we have any plans to use literal encoding in Soaplab2? > I do not know. Some times ago I spoke with Peter about it - but I am still not sure. Perhaps for derived services. Martin -- Martin Senger email: mar...@gm... skype: martinsenger |
|
From: Peter E. <P....@dk...> - 2006-05-31 13:28:31
|
On Wed, 31 May 2006, Mahmut Uludag wrote:
> Can you please give brief information about the Soaplab <-> Applab
> issues that prevented the use of the XML schema?
The data transfer between Soaplab and Applab is realised with a
HashMap. But this means, that the order of the parameters on the
command-line gets lost. For example, in the Emboss program "water",
you can have two times the parameter "sformat":
$ water -sformat=gcg seq1.gcg -sformat=fasta seq2.fa
In order to distinguish between both "sformat"s, SoapLab uses the
alernative notation: -sformat1=... and -sformat2=...
But therefore I couldn't reference an external Emboss/Acd type like
this:
<xs:complexType name="Tsequence">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="sbegin" type="xs:integer" use="optional"/>
<xs:attribute name="send" type="xs:integer" use="optional"/>
<xs:attribute name="sformat" type="xs:string" use="optional"/>
[....]
</xs:extension>
</xs:simpleContent>
</xs:complexType>
Different types must be created for sformat1 and sformat2. See
http://genome.dkfz-heidelberg.de/menu/hobit/embapps/wsdl/water.wsdl
for an example.
The problem disappears, when the order of the parameters on the
command-line is defined, and doesn't get lost. I guess this is
something that must be fixed anyway, because it is not so unusal, that
the order of the parameters on the command-line matters for a tool.
Kind regards,
Peter
|
|
From: Peter E. <P....@dk...> - 2006-05-31 13:04:31
|
On Wed, 31 May 2006, Mahmut Uludag wrote: > > When it comes to services and their outputs, one should not forget > > those tools, that already produce XML according to a defined > > XML-Schema. > > Can you please give some examples to those tools? Did you mean we should > use such tools? We create such tools here (e.g. http://genome.dkfz-heidelberg.de/menu/biounit/dev.shtml#task), and there are other bioinformatics groups, having such tools, too (e.g. http://hobit.gsf.de/wiki/display/wiki/Services). Our tools create XML output and there is a XML-Schema describing their output. I patched the CVS-Soaplab, to enable it for servicing these tools. Recently, I created a branch in the CVS repository of Soaplab "branch-soaplab-dkfz-1", where I am currently in the process of committing my modifications. See the file "ChangeLog.branch-dkfz-1" for details. My greatest concern with the original Soaplab was the output WSDL file. In my experiments, it was hardly usable with other toolkits than Axis. I tried gSoap (C++), VisualStudio.NET and Soap::Lite (Perl). To see a WSDL file for an XML output tool from my patched Soaplab, follow http://genome.dkfz-heidelberg.de/menu/hobit/embapps/wsdl/domainsweep.wsdl (search for "taskresult"). Kind regards, Peter |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 09:32:08
|
Dear Peter, > I attach to this mail a XML schema, I generated from Emboss for use in > Soaplab. It didn't make it into Soaplab, because of Soaplab <-> Applab > issues. Can you please give brief information about the Soaplab <-> Applab issues that prevented the use of the XML schema? Regards, Mahmut |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 09:22:53
|
Dear Peter, Thank you for your comments. > When it comes to services and their outputs, one should not forget > those tools, that already produce XML according to a defined > XML-Schema. Can you please give some examples to those tools? Did you mean we should use such tools? > Because Emboss tools currently do not produce such outputs, there is > nothing forseen in ACD so far, to define the relationship (XML > output according schema with URI ... located at ....). > > But Soaplab can handle such XML-output-tools, if literal encoding is > used (instead of RPC-encoding). Martin, do we have any plans to use literal encoding in Soaplab2? Regards, Mahmut |
|
From: Mahmut U. <ul...@eb...> - 2006-05-31 09:15:51
|
> > What is the "service container" in the deployment component ? > > > I guess it is a file with everything needed for a services (including > java classes and configuration files, like its XML files, etc.) Actually, by the "service container" I meant the Axis server which is generally a Tomcat server. Axis2 documentation calls the files that include everything for a service, as "service archive files". M. |
|
From: Martin S. <se...@eb...> - 2006-05-30 14:19:44
|
> Why we do not want to use any 'pure' servlets? > > Using only JSPs contradicts with my perception of a good design, based > on my readings and previous experience. > I think that using 'pure' servlets (meaning extending directly HTTPServletRequest) is using too low level. Your programs must do many more things (it is like writting a code in assemblre versus writting it in C). There may be cases where you need it but unless you find that something is not accessible what you need I think that it is better to stay on the higher level. Do not take mw wrong: I have been myself writing 'pure' servlets regularly, but later I found that creating, for example, JSP script/page is much more maintainable and les error-prove - even for things that do not create an HTML output. If you wish to see one, very small, project where I am using JSP even for replying to Ajax (HTTPRequest) request by a JSP page, you can look at the page at http://moby.generationcp.org/mobyenv/checkservices, andcheck out the code from https://cropforge.org/projects/gcpmoby/, doing: cvs -d :pserver:ano...@cv...:/cvsroot/gcpmoby login (password is empty) cvs -d :pserver:ano...@cv...:/cvsroot/gcpmoby co Moby_Environment Regards, Martin -- Martin Senger email: mar...@gm... skype: martinsenger |
|
From: Mahmut U. <ul...@eb...> - 2006-05-30 12:32:23
|
> > We will use JSPs to generate the presentation layer and servlets as > > the controllers > > > I think it is enough to say "use JSPs". Because JSPs *are* already > servlets. I do not think that you wish to create any piece of the > dashboard as a "pure" servlet (by implementing the HTTPServletRequest > interface). I would not recommend it. Why we do not want to use any 'pure' servlets? Using only JSPs contradicts with my perception of a good design, based on my readings and previous experience. Regards, Mahmut |
|
From: Martin S. <se...@eb...> - 2006-05-29 23:46:44
|
My 2c's are: > What (in basic terms) is the "Soaplab build.xml file" ? > It is a configuration file for Ant. It defines various tasks that the Ant can do for us. > Would EMBOSS (for example) be a "service group" ? > No, the "service group" would be identical what you can find in the ACD files in application/groups key. > What is the "service container" in the deplyoment component ? > I guess it is a file with everything needed for a services (including java classes and configuration files, like its XML files, etc.) > If an administrator deployed an archive file by copying the archive file to the Axis2 > services repository, or by using the Axis2 administration tools, would these services > later be visible to the "service explorer" component ? > Yes, it will be visible to "service client" component (and very probably also to "service administrator" component - but that has to be yet defined). > It's more obvious to me now how the dashboard and acdtools / JACD fit together. The > Service Editor and JACD-GUI have common ground, but I face an easier proposition > because JACD-GUI only need support what can be defined in an ACD file / by the XML-ACD > schema, whereas the service editor needs (presumably) to handle stuff outside that > scope / in an extended schema. > No, my vision of a service editor is that it handles and edit ACD files in a user-friendly GUI. I think that the service editor in the dashboard will use your JACD-GUI as much as possible. I do not recommend to Mahmud to spend *any* time of a service editor now. We should wait for your JACD-GUI and to see how it can be used for the dashboard. > Both might need to handle dependencies between options of the type, "The value of option X > depends on the the value of option Y" - not easy, perhaps we could help each other with that > part? > That's definitely an easy thing (I know it because I have never implemented in Soaplab). Perhaps this will need even some chnages (some additional tags and attributes) in the Soaplab XML files. Any suggestion from you is welcome here. > Last thought is that it might be sensible if the XML schema used by SOAPLAB (or indeed > any interface to EMBOSS) was managed as an extension to the (more basic) ACD-XML schema. > You said it already before. I still need to be convinced that there is a difference between them. If ACD is just for EMBOSS then yes, there will be a difference, but I considered always to have ACD for any command-line application - so its XML schema should be actually thye same as the Soaplab one. Cheers, Martin -- Martin Senger email: mar...@gm... skype: martinsenger |
|
From: Martin S. <se...@eb...> - 2006-05-29 23:36:07
|
Hi,
Thanks for putting this together. Here are my comments (not realy big
ones):
> We will use JSPs to generate the presentation layer and servlets as
> the controllers
>
I think it is enough to say "use JSPs". Because JSPs *are* already
servlets. I do not think that you wish to create any piece of the
dashboard as a "pure" servlet (by implementing the HTTPServletRequest
interface). I would not recommend it.
> The dashboard will include the following basic components.
>
That's okay - I would like just to add that the dashboard will be
designed in a way that adding a new component (not listed in your
description) will be possible (and hopefully easy - like a plugin, or
a pluglet).
> -- Service Editor
> This component will present users an HTML form that can be used to
> provide the definition of a new service. When the form is submitted, the
> dashboard Servlet will generate the files required by Axis2 and will
> then pack them in a Web Service archive.
>
That's not I see it. The editor output should be an ACD file, or
bot an ACD and XML file. What you just described is part of the
deployment.
> The information to be provided using the form will basically include the
> following.
>
I do not think that this list is complete. It must provide
everything what is possible to put in the ACD files.
> -- Deployment component
>
You are describing in details *how* to deploy a service (I would
not call it a component). But you should rather to say *what* this
deployment contains. But anyway, I think that we have the same
understanding of what to be done here.
I would suggest to do it similarly as in the Tomcat manager (where
a war file can be deployed either from the server file or uploaded
from a user machine).
> One issue regarding the Soaplab service archive files; it would be wise
> to have the Soaplab library and other libraries used by Soaplab, in the
> shared libraries directory of the Axis2 repository rather than in the
> service archive file.
>
This could be an option in the deployment Dashboard component.
> -- Service explorer
> This component will basically be used for exploring and calling Soaplab
> services.
>
I would separate it into two components: One for normal service
users calling Soaplab services, and one for Soaplab admins calling a
separate, usually not public, admin interface (which I/we have to
define yet). "Service client" and "Service administrator".
Cheers,
Martin
--
Martin Senger
email: mar...@gm...
skype: martinsenger
|
|
From: Peter E. <P....@dk...> - 2006-05-29 12:28:52
|
Concerning XML-ACD Schema:
In fact I see 2 schemas:
1. The schema describing the XML files that replace the ACD files.
2. Soaplab processes input documents (XML instances), that relate to ACD
files, but are not described already by (1).
In fact, every service in soaplab needs its special schema, but
the types used in these schemas, are "ACD types". But these "ACD
types" are not described by (1), I suppose.
I attach to this mail a XML schema, I generated from Emboss for use in
Soaplab. It didn't make it into Soaplab, because of Soaplab <-> Applab
issues, but it explains the "ACD types" from (2).
Kind regards,
Peter
|
|
From: Jon I. <ji...@eb...> - 2006-05-26 13:48:53
|
Hi Peter These terms relate to a piece of software I'm designing for (amongst other things) capturing user requirements for EMBOSS applications ... there were some discussions at the EBI which you missed. I'll forward you the messages off-list, 'cause it's not strictly soaplab stuff, just related. Cheers Jon > Sorry if I missed something, but what are: > > 1. JACD-GUI > 2. ACD-XML > 3. ACD-XML schema ?? > > Cheers, > > Peter > > > On Fri, 26 May 2006, Jon Ison wrote: > >> It's more obvious to me now how the dashboard and acdtools / JACD >> fit together. The Service Editor and JACD-GUI have common ground, >> but I face an easier proposition because JACD-GUI only need support >> what can be defined in an ACD file / by the XML-ACD schema, whereas >> the service editor needs (presumably) to handle stuff outside that >> scope / in an extended schema. >> >> Both might need to handle dependencies between options of the type, >> "The value of option X depends on the the value of option Y" - not >> easy, perhaps we could help each other with that part? >> >> Last thought is that it might be sensible if the XML schema used by >> SOAPLAB (or indeed any interface to EMBOSS) was managed as an >> extension to the (more basic) ACD-XML schema. > |
|
From: Peter E. <P....@dk...> - 2006-05-26 13:40:24
|
Sorry if I missed something, but what are: 1. JACD-GUI 2. ACD-XML 3. ACD-XML schema ?? Cheers, Peter On Fri, 26 May 2006, Jon Ison wrote: > It's more obvious to me now how the dashboard and acdtools / JACD > fit together. The Service Editor and JACD-GUI have common ground, > but I face an easier proposition because JACD-GUI only need support > what can be defined in an ACD file / by the XML-ACD schema, whereas > the service editor needs (presumably) to handle stuff outside that > scope / in an extended schema. > > Both might need to handle dependencies between options of the type, > "The value of option X depends on the the value of option Y" - not > easy, perhaps we could help each other with that part? > > Last thought is that it might be sensible if the XML schema used by > SOAPLAB (or indeed any interface to EMBOSS) was managed as an > extension to the (more basic) ACD-XML schema. |
|
From: Peter E. <P....@dk...> - 2006-05-26 13:37:43
|
Dear Mahmut,
thank you for the detailed description of your plan.
For now, I just have a small comment concering the service editor:
When it comes to services and their outputs, one should not forget
those tools, that already produce XML according to a defined
XML-Schema.
Because Emboss tools currently do not produce such outputs, there is
nothing forseen in ACD so far, to define the relationship (XML
output according schema with URI ... located at ....).
But Soaplab can handle such XML-output-tools, if literal encoding is
used (instead of RPC-encoding).
Kind regards,
Peter
On Thu, 25 May 2006, Mahmut Uludag wrote:
> The dashboard will include the following basic components.
>
> * Service editor, for defining new services (possibly for
> modifying existing services as well) and for preparing
> deployable service archive files for Axis2.
>
> * Deployment component, for hot-deployment of Soaplab service
> archive files.
>
> * Service explorer, for exploring services on a given Soaplab
> server.
|
1 message has been excluded from this view by a project administrator.
