[Biocatalogue-hackers] Errors registering certain services and new version code base

Jackson, Tod tod.jackson at emory.edu
Thu May 6 10:29:59 EDT 2010


Yes, that is correct.  I'm not sure what happened there?  I must have inadvertently missed it when I cut and pasted it.  It certainly wouldn't work without that call!  Sorry about that.

Thanks,
Tod


On 5/6/10 9:25 AM, "Jiten Bhagat" <jits at cs.man.ac.uk> wrote:

Hi Todd,

I've been integrating your code (thanks again!) into the current branch
I am working on - service-updates-and-curation - and noticed an issue:

Your "hacked_from_xml" method below...

> def hacked_from_xml(xml, options = {})
>   Rails.logger.info("conversions.rb:  hacked_from_xml called.")
> end

Seems to be missing a call to some where?

So I have worked it out to be:

def hacked_from_xml(xml, options = {})
  Rails.logger.info("conversions.rb:  hacked_from_xml called.")
  return hacked_typecast_xml_value(unrename_keys(XmlMini.parse(xml)),
options)
end

... and it seems to work! Is this correct?

Note: I have created a task on our task list for this -
http://www.mygrid.org.uk/dev/issues/browse/BIOCAT-315, and have
committed these changes in revision 1919 (commit log attached).

Cheers,
Jits


Jiten Bhagat wrote:
> Hi Tod,
>
> Thanks very much for the detailed explanation. I like the way you've
> isolated it so that just the one place (ie: the WSDL parser) uses the
> "hacked" method. I will look to integrate this fix soon.
>
> On a related note: I have made some major refactorings of the WSDL
> parsing modules (in a separate branch, not directly in trunk) so that
> now there is only one canonical WSDL Parser -
> BioCatalogue::WsdlParser.parse(..) which then takes care of using the
> WSDLUtils parser or fails over to the old WSDL parser (the one you've
> modified; which now resides in
> BioCatalogue::WsdlParser::Legacy.parse(..)) if required. I expect we'll
> merge this into trunk in roughly 2-3 weeks time, after which you can
> pick up the changes if you'd like.
>
> Thanks again! And let me know if I can help with anything else.
>
> Cheers,
> Jits
>
>
> Jackson, Tod wrote:
>
>> Okay Jits, here's an attempt at describing what I did to get past the issues were were having.  Like I said, I probably broke a few rules along the way but it does seem to have got us past the issue.  I'm sure some of this might not make sense so please feel free to ask for clarification wherever needed.
>>
>> Best Regards,
>> Tod
>>
>> First, after spending some time trying to narrow in on what I *thought* the issue was, I did some research and found a few references to what I thought were people having similar issues.  The one that seemed most relevant to me was this blog by Peter Wagenet (http://in.finitu.de/2008/11/05/stop-hash-from_xml-from-killing-xml-attributes).  It seemed like Peter was describing a very similar situation to what I thought we were seeing (losing attributes when you had an element with only attributes).
>>
>> In the blog, Peter references a patch that he had submitted but after spending quite a bit of time trying to track the patch down and apply it (or parts of it anyway) I reverted to what is probably a complete hack.  I was concerned with applying a "global patch" anyway because I thought it might introduce backward compatibility issues.  So, I focussed my efforts on the things I knew about and thought I had at least some control over.  Namely, the WsdlParser module (lib/bio_catalogue/wsdl_parser.rb).  As you mentioned, this module is used when/if the new parser fails.  In my case, that was happening so that's where I focussed.
>>
>> Ultimately, I took snippets of the code from the blog I mention above and added a couple new methods to the Hash class which is defined in the vendor/rails/activesupport/lib/active_support/core_ext/hash/conversions.rb file (did I mention it's a hack?).  Here are the methods I added (I took this code pretty much verbatim from Peter's blog but I didn't use everything he mentions, only these methods):
>>
>>           def hacked_from_xml(xml, options = {})
>>             Rails.logger.info("conversions.rb:  hacked_from_xml called.")
>>           end
>>
>>           private
>>             def hacked_typecast_xml_value(value, options = {})
>>               options.symbolize_keys!
>>               options.reverse_merge!(:preserve_attributes => false)
>>
>>             case value.class.to_s
>>                 when 'Hash'
>>                   if value['type'] == 'array'
>>                     child_key, entries = value.detect { |k,v| k != 'type' }   # child_key is throwaway
>>                     if entries.nil? || (c = value['__content__'] && c.blank?)
>>                       []
>>                     else
>>                       case entries.class.to_s   # something weird with classes not matching here.  maybe singleton methods breaking is_a?
>>                       when "Array"
>>                         entries.collect { |v| hacked_typecast_xml_value(v, options) }
>>                       when "Hash"
>>                         [hacked_typecast_xml_value(entries, options)]
>>                       else
>>                         raise "can't typecast #{entries.inspect}"
>>                       end
>>                     end
>>                   elsif value.has_key?("__content__")
>>                     content = value["__content__"]
>>                     if parser = XML_PARSING[value["type"]]
>>                       if parser.arity == 2
>>                         XML_PARSING[value["type"]].call(content, value)
>>                       else
>>                         XML_PARSING[value["type"]].call(content)
>>                       end
>>                     elsif options[:preserve_attributes] && value.keys.size > 1
>>                       value["content"] = value.delete("__content__")
>>                       value
>>                     else
>>                       content
>>                     end
>>                   elsif value['type'] == 'string' && value['nil'] != 'true'
>>                     ""
>>                   # blank or nil parsed values are represented by nil
>>                   elsif value.blank? || value['nil'] == 'true'
>>                     nil
>>                   # If the type is the only element which makes it then
>>                   # this still makes the value nil, except if type is
>>                   # a XML node(where type['value'] is a Hash)
>>                   elsif value['type'] && value.size == 1 && !value['type'].is_a?(::Hash)
>>                     nil
>>                   else
>>                     xml_value = value.inject({}) do |h,(k,v)|
>>                       h[k] = hacked_typecast_xml_value(v, options)
>>                       h
>>                     end
>>
>>                     # Turn { :files => { :file => #<StringIO> } into { :files => #<StringIO> } so it is compatible with
>>                     # how multipart uploaded files from HTML appear
>>                     xml_value["file"].is_a?(StringIO) ? xml_value["file"] : xml_value
>>                   end
>>                 when 'Array'
>>                   value.map! { |i| hacked_typecast_xml_value(i, options) }
>>                   case value.length
>>                     when 0 then nil
>>                     when 1 then value.first
>>                     else value
>>                   end
>>                 when 'String'
>>                   value
>>                 else
>>                   raise "can't typecast #{value.class.name} - #{value.inspect}"
>>               end
>>             end
>>
>> Then, I modified wsdl_parser.rb to use my new "hacked" version of these methods.  I changed this:
>>
>> wsdl_hash = Hash.from_xml(wsdl_file_contents)
>>
>> to this:
>>
>> wsdl_hash = Hash.hacked_from_xml(wsdl_file_contents, :preserve_attributes => true)
>>
>> We haven't had any of the issues since putting these changes in.  Since I thought I new where the issues were occurring, I felt somewhat okay with making the change this way because I could "hack" the foundation and only use that hack in the one place I knew were were having issues thereby avoiding the introduction of backward compatibility issue if there were other places throughout the app that was still using the original Hash.from_xml method.
>>
>> ________________________________________
>> From: Jiten Bhagat [jits at cs.man.ac.uk]
>> Sent: Wednesday, April 21, 2010 11:35 AM
>> To: Jackson, Tod
>> Cc: biocatalogue-hackers at rubyforge.org
>> Subject: Re: [Biocatalogue-hackers] Errors registering certain services and new version code base
>>
>> Hi Tod,
>>
>> Yes please, I'd be very interested in checking out what you have done.
>> It sounds useful for the long run, and potentially for others too. So I
>> would say feel free to share your findings on this list (also adds more
>> closure to the issues raised here).
>>
>> Thanks,
>> Jits
>>
>>
>> Jackson, Tod wrote:
>>
>>
>>> Thanks for the confirmation Jit.  That seems to line up with what we were seeing.
>>>
>>> In the meantime, I did do a little more digging and was able to find a few references to this behavior in the ether.  I even found what I thought might be a patch that seemed to be talking about something very similar to the behavior we were seeing.  After several unsuccessful attempts to work the patch into a local deployment, I finally resorted to a "hack" based on the information I was able to derive from the various discussions I found about this issue.  What I did is definitely NOT a long term solution but it did allow me to get it working in our environment.
>>>
>>> As I mentioned before, I'm pretty new to Ruby/Rails so I'm sure what I did broke all kinds of rules but at least it worked.  Would you be interested in hearing more about the things I did to get it to work?  I can send you references to the other information I found about this too because it may be relevant to the work you're thinking about for the parser itself?  Let me know if you're interested and the best way for me to share the information I have.  I'm not sure if this distribution list is the best way or not?
>>>
>>> Thanks again for all your help!
>>>
>>> Tod
>>>
>>> On Apr 19, 2010, at 11:42 AM, Jiten Bhagat wrote:
>>>
>>>
>>>
>>>
>>>> Hi Tod,
>>>>
>>>> On closer inspection, turns out that both the WSDLs you mention below
>>>> will cause a fallback to the old parser because the new parser doesn't
>>>> yet support WSDLs with XSD imports that are relative paths. I.e.:
>>>> <xsd:import namespace="http://www.openeai.org/ahs/"
>>>> schemaLocation="AcademicHistoryService?xsd=ahs.xsd"/>
>>>>
>>>> ... and so you are hitting the issue you described in your previous
>>>> email with the old parser and it's use of Hash.from_xml (thanks for
>>>> digging up that info).
>>>>
>>>> The only thing I can suggest at this stage, just to get this working, is
>>>> to put in an absolute path in the XSD imports in the WSDLs. This should
>>>> hopefully allow the new parser to be able to parse it.
>>>>
>>>> We'll look into sorting the issue out in the new parser.
>>>>
>>>> Cheers,
>>>> Jits
>>>>
>>>>
>>>>
>>>> Jiten Bhagat wrote:
>>>>
>>>>
>>>>
>>>>> Hi Todd,
>>>>>
>>>>> Jackson, Tod wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Greetings BioCataloguers,
>>>>>>
>>>>>> My colleagues and I at Emory University are still working on a
>>>>>> deployment of the BioCatalogue application for use by the PESC
>>>>>> sponsored EdUnify task force.  There are several things we'd like to
>>>>>> work with you on at some point in the future if possible but we've
>>>>>> been investigating an issue for a bit now and I think the time has
>>>>>> come to just try and get some input from you all if possible.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sure thing, we'll help as much as we can :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> There's at least one reference in the wsdl_parser.rb file that seems
>>>>>> to indicate there might be some general limitations and plans for
>>>>>> perhaps a more elegant solution in the future, but I'm not sure if
>>>>>> this is an example of one of those or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Yeah, the wsdl_parser.rb parser was an initial "quick and dirty"
>>>>> implementation we used in the early days of the BioCatalogue and is only
>>>>> used right now as a fallback when the new WSDL parser -
>>>>> lib/wsdl_utils_parser_client.rb - fails.
>>>>>
>>>>> This new WSDL parser connects to a separate service which the BioCat app
>>>>> accesses to handle WSDL parsing needs. The constant WSDLUTILS_BASE_URI
>>>>> in config/initializers/biocat_local.rb determines the location of this
>>>>> parser service. There's 2 things you can do here:
>>>>> 1. Set this to "http://www.biocatalogue.org/WSDLUtils/WSDLUtils.php" to
>>>>> use the parser service used by the main BioCatalogue website.
>>>>> 2. See vendor/wsdl-parsing-service/ for the code and instructions to set
>>>>> the WSDL parsing service up on your own servers (note that it doesn't
>>>>> currently work on PHP 5.3 or higher).
>>>>>
>>>>> This WSDL parser was developed by the EMBRACE Registry project (which is
>>>>> merging into the BioCatalogue) and allows for much better parsing,
>>>>> including parsing of schemas etc. More information is available here:
>>>>> http://www.biocatalogue.org/wiki/doku.php?id=development:wsdl_parsing
>>>>>
>>>>> If, for whatever reason, this WSDL parser fails to parse (such as if the
>>>>> server is inaccessible), the old parser is used as a fallback, just to
>>>>> see if it can get back anything useful. This is probably what is
>>>>> happening in your case.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> This leads to the second point of this email.  Is the source code of
>>>>>> the new version of BioCatalogue available?  I tried getting an updated
>>>>>> code base from the SVN repository link I used initially but it looks
>>>>>> like it may be the same version I got the first time I downloaded it all??
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> The latest code should always be available at
>>>>> http://biocatalogue.rubyforge.org/svn/trunk/. Is this what you have
>>>>> checked out? What does the output of 'svn update' give you? Lots of new
>>>>> code has been put in in the last few months so you should pick up lots
>>>>> of changes. Please see our release notes for more info:
>>>>> http://www.biocatalogue.org/wiki/doku.php?id=development:release_notes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I apologize in advance for the long-winded message.  Any help or
>>>>>> advice you might offer would be appreciated.  We will continue to
>>>>>> investigate but figured a cry for help might be more fruitful.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> No problem. Feel free to post your questions! Hopefully we can help.
>>>>>
>>>>> I'm hoping that the issue you have explained below is resolved by using
>>>>> the new WSDL parser. Let us know how it goes. We can investigate further
>>>>> if it still doesn't work. (My first attempt at previewing the WSDL
>>>>> fails, but you might have more luck by debugging what's going on).
>>>>>
>>>>> Cheers,
>>>>> Jits
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Best Regards,
>>>>>> Tod Jackson
>>>>>>
>>>>>>
>>>>>> We have the application deployed and have been able to register
>>>>>> several services.  However, there are times when we get an error that
>>>>>> we haven't been able to effectively debug.  We're still fairly new to
>>>>>> Ruby on Rails so that could be part of the issue.  The following WSDL
>>>>>> URL loads and registers just fine:
>>>>>>
>>>>>> http://www.openeai.org/live/services/ahs/midlandstech.wsdl
>>>>>>
>>>>>> However, the following URL does not work.  They are basically just
>>>>>> different deployments of the same service and we have successfully
>>>>>> worked with this URL in various other applications.  I'm including
>>>>>> this example because it's an example where we have one deployment of
>>>>>> the service that registers and one that doesn't.  Just in case there
>>>>>> are notable differences that might help explain the behavior we're seeing.
>>>>>>
>>>>>> http://wsdev.openeai.org:8585/axis2/services/AcademicHistoryService?wsdl
>>>>>>
>>>>>> When we try this URL, we aren't even able to preview the service.
>>>>>>
>>>>>> Here is the error we're getting (from the log):
>>>>>>
>>>>>> ERROR    Exception occurred whilst parsing WSDL
>>>>>> 'http://wsdev.openeai.org:8585/axis2/services/AcademicHistoryService?wsdl'.
>>>>>> Exception:
>>>>>> ERROR    You have a nil object when you didn't expect it!
>>>>>> You might have expected an instance of Array.
>>>>>> The error occurred while evaluating nil.split
>>>>>> ERROR    /opt/biocat/dev/www/lib/bio_catalogue/wsdl_parser.rb:224:in
>>>>>> `map_messages_and_operations'
>>>>>> /opt/biocat/dev/www/lib/bio_catalogue/wsdl_parser.rb:214:in `each'
>>>>>>
>>>>>> We've drilled down on it a bit and have inspected the wsdl_hash
>>>>>> variable which is built from the wsdl_file_contents string.  The
>>>>>> wsdl_file_contents variable is getting populated with "roughly" the
>>>>>> same content for both of these URLs.  However, when we inspect the
>>>>>> wsdl_hash variable that is built using the Hash.from_xml method, there
>>>>>> are definitely differences.
>>>>>>
>>>>>> Below is the content of the wsdl_hash variable for each URL, the first
>>>>>> one works and we're able to successfully register it, the second
>>>>>> doesn't work and we can't even preview it:
>>>>>>
>>>>>> GOOD: {"definitions"=>{"name"=>"AcademicHistoryService",
>>>>>> "target_namespace"=>"http://www.openeai.org/AcademicHistoryService/",
>>>>>> "port_type"=>{"name"=>"AcademicHistoryService",
>>>>>> "operation"=>[{"name"=>"academicCalendarQuery",
>>>>>> "output"=>{"message"=>"tns:AcademicCalendarProvideReply"},
>>>>>> "input"=>{"message"=>"tns:AcademicCalendarQueryRequest"}},
>>>>>> {"name"=>"academicHistoryQuery",
>>>>>> "output"=>{"message"=>"tns:AcademicHistoryProvideReply"},
>>>>>> "input"=>{"message"=>"tns:AcademicHistoryQueryRequest"}},
>>>>>> {"name"=>"pingQuery", "output"=>{"message"=>"tns:PingProvideReply"},
>>>>>> "input"=>{"message"=>"tns:PingQueryRequest"}},
>>>>>> {"name"=>"statisticsQuery",
>>>>>> "output"=>{"message"=>"tns:StatisticsProvideReply"},
>>>>>> "input"=>{"message"=>"tns:StatisticsQueryRequest"}}]},
>>>>>> "service"=>{"name"=>"AcademicHistoryService",
>>>>>> "port"=>{"address"=>{"location"=>"https://mtconline.midlandstech.edu/axis2/services/AcademicHistoryService/"},
>>>>>> "name"=>"AcademicHistoryServiceSOAP",
>>>>>> "binding"=>"tns:AcademicHistoryServiceSOAP"}},
>>>>>> "binding"=>{"name"=>"AcademicHistoryServiceSOAP",
>>>>>> "type"=>"tns:AcademicHistoryService",
>>>>>> "binding"=>{"transport"=>"http://schemas.xmlsoap.org/soap/http",
>>>>>> "style"=>"document"}, "operation"=>[{"name"=>"academicCalendarQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/academicCalendarQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}},
>>>>>> {"name"=>"academicHistoryQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/academicHistoryQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}, {"name"=>"pingQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/pingQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}, {"name"=>"statisticsQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/statisticsQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}]},
>>>>>> "types"=>{"schema"=>{"target_namespace"=>"http://www.openeai.org/AcademicHistoryService/",
>>>>>> "import"=>{"namespace"=>"http://www.openeai.org/ahs/",
>>>>>> "schema_location"=>"ahs.xsd"},
>>>>>> "element"=>[{"name"=>"AcademicCalendarQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1",
>>>>>> "ref"=>"ahs:AcademicCalendarQuerySpecification"}}}},
>>>>>> {"name"=>"AcademicCalendarProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicCalendar"}]}}},
>>>>>> {"name"=>"AcademicHistoryQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicHistoryQuerySpecification"}}}},
>>>>>> {"name"=>"AcademicHistoryProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicHistory"}]}}},
>>>>>> {"name"=>"PingQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:PingQuerySpecification"}}}},
>>>>>> {"name"=>"PingProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Ping"}]}}},
>>>>>> {"name"=>"StatisticsQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:StatisticsQuerySpecification"}}}},
>>>>>> {"name"=>"StatisticsProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Statistics"}]}}}]}},
>>>>>> "message"=>[{"name"=>"AcademicHistoryProvideReply",
>>>>>> "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:AcademicHistoryProvideReply"}},
>>>>>> {"name"=>"AcademicHistoryQueryRequest", "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:AcademicHistoryQueryRequest"}},
>>>>>> {"name"=>"AcademicCalendarProvideReply",
>>>>>> "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:AcademicCalendarProvideReply"}},
>>>>>> {"name"=>"StatisticsProvideReply", "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:StatisticsProvideReply"}},
>>>>>> {"name"=>"AcademicCalendarQueryRequest",
>>>>>> "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:AcademicCalendarQueryRequest"}},
>>>>>> {"name"=>"PingProvideReply", "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:PingProvideReply"}},
>>>>>> {"name"=>"StatisticsQueryRequest", "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:StatisticsQueryRequest"}},
>>>>>> {"name"=>"PingQueryRequest", "part"=>{"name"=>"parameters",
>>>>>> "element"=>"tns:PingQueryRequest"}}]}}
>>>>>>
>>>>>>
>>>>>> BAD:  {"definitions"=>{"name"=>"AcademicHistoryService",
>>>>>> "target_namespace"=>"http://www.openeai.org/AcademicHistoryService/",
>>>>>> "port_type"=>{"name"=>"AcademicHistoryService",
>>>>>> "operation"=>[{"name"=>"academicCalendarQuery", "output"=>"\n    ",
>>>>>> "input"=>"\n    "}, {"name"=>"academicHistoryQuery", "output"=>"\n
>>>>>> ", "input"=>"\n    "}, {"name"=>"pingQuery", "output"=>"\n    ",
>>>>>> "input"=>"\n    "}, {"name"=>"statisticsQuery", "output"=>"\n    ",
>>>>>> "input"=>"\n    "}]}, "service"=>{"name"=>"AcademicHistoryService",
>>>>>> "port"=>{"address"=>{"location"=>"http://74.207.231.80:8585/axis2/services/AcademicHistoryService/"},
>>>>>> "name"=>"AcademicHistoryServiceSOAP",
>>>>>> "binding"=>"tns:AcademicHistoryServiceSOAP"}},
>>>>>> "binding"=>{"name"=>"AcademicHistoryServiceSOAP",
>>>>>> "type"=>"tns:AcademicHistoryService",
>>>>>> "binding"=>{"transport"=>"http://schemas.xmlsoap.org/soap/http",
>>>>>> "style"=>"document"}, "operation"=>[{"name"=>"academicCalendarQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/academicCalendarQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}},
>>>>>> {"name"=>"academicHistoryQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/academicHistoryQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}, {"name"=>"pingQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/pingQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}, {"name"=>"statisticsQuery",
>>>>>> "output"=>{"body"=>{"use"=>"literal"}},
>>>>>> "operation"=>{"soap_action"=>"http://www.openeai.org/AcademicHistoryService/statisticsQuery"},
>>>>>> "input"=>{"body"=>{"use"=>"literal"}}}]},
>>>>>> "types"=>{"schema"=>{"target_namespace"=>"http://www.openeai.org/AcademicHistoryService/",
>>>>>> "import"=>{"namespace"=>"http://www.openeai.org/ahs/",
>>>>>> "schema_location"=>"AcademicHistoryService?xsd=ahs.xsd"},
>>>>>> "element"=>[{"name"=>"AcademicCalendarQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1",
>>>>>> "ref"=>"ahs:AcademicCalendarQuerySpecification"}}}},
>>>>>> {"name"=>"AcademicCalendarProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicCalendar"}]}}},
>>>>>> {"name"=>"AcademicHistoryQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicHistoryQuerySpecification"}}}},
>>>>>> {"name"=>"AcademicHistoryProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:AcademicHistory"}]}}},
>>>>>> {"name"=>"PingQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:PingQuerySpecification"}}}},
>>>>>> {"name"=>"PingProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Ping"}]}}},
>>>>>> {"name"=>"StatisticsQueryRequest",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:StatisticsQuerySpecification"}}}},
>>>>>> {"name"=>"StatisticsProvideReply",
>>>>>> "complex_type"=>{"sequence"=>{"element"=>[{"min_occurs"=>"1",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Result"}, {"min_occurs"=>"0",
>>>>>> "max_occurs"=>"1", "ref"=>"ahs:Statistics"}]}}}]}},
>>>>>> "message"=>[{"name"=>"StatisticsQueryRequest", "part"=>"\n    "},
>>>>>> {"name"=>"AcademicHistoryQueryRequest", "part"=>"\n    "},
>>>>>> {"name"=>"AcademicCalendarProvideReply", "part"=>"\n    "},
>>>>>> {"name"=>"PingProvideReply", "part"=>"\n    "},
>>>>>> {"name"=>"AcademicHistoryProvideReply", "part"=>"\n    "},
>>>>>> {"name"=>"PingQueryRequest", "part"=>"\n    "},
>>>>>> {"name"=>"AcademicCalendarQueryRequest", "part"=>"\n    "},
>>>>>> {"name"=>"StatisticsProvideReply", "part"=>"\n    "}]}}
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> This e-mail message (including any attachments) is for the sole use of
>>>>>> the intended recipient(s) and may contain confidential and privileged
>>>>>> information. If the reader of this message is not the intended
>>>>>> recipient, you are hereby notified that any dissemination, distribution
>>>>>> or copying of this message (including any attachments) is strictly
>>>>>> prohibited.
>>>>>>
>>>>>> If you have received this message in error, please contact
>>>>>> the sender by reply e-mail message and destroy all copies of the
>>>>>> original message (including attachments).
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Biocatalogue-hackers mailing list
>>>>>> Biocatalogue-hackers at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/biocatalogue-hackers
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Biocatalogue-hackers mailing list
>>>>> Biocatalogue-hackers at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/biocatalogue-hackers
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> Biocatalogue-hackers mailing list
> Biocatalogue-hackers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/biocatalogue-hackers
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/biocatalogue-hackers/attachments/20100506/007cc2f9/attachment-0001.html>


More information about the Biocatalogue-hackers mailing list