[MOBY-dev] JMoby....

[Dmitry Repchevsky]

Dear Martin,

Thank you for the reply.

> Your emails are sometimes a bit aggressive (as are mine, probably) up to the
> point that they decrease motivation to respond to them.
I do not intend to offend anyone, but sometimes a provocative style is 
the only way I can get the response, unfortunately.
(I've been asked several times the same question, but got the answer 
only to the last post, so subconscious I somehow decided that this is 
the way to get answered... sorry).

As an example I would like to repeat the question I asked several times 
and still have no answer:

Q: BioMoby doesn't use WSDL file to access the Web Services, so is there 
any specification about parameter names (example part name="request")? 
Ignoring the WSDL without explicit accordance in it makes virtually all 
BioMoby requests wrong and rejected by all modern Java webservices 
stacks (even it works in AXIS).
It is as easy as to put "request parameter name must be 'request' and 
response must be named 'response'" into the "specification".
... sorry for the aggressiveness again ;-).

> ...we usually refer to this API as to a language-independent
> interface, while "Java API" (or "jMoby API") is used only for Java
> developers - if they are interested to use it.
Well there are two definition of API - specification and implementation, 
usually (in my experience) the API means concrete implementation of the 
specification, i accept that this could be different... Thank you to 
clarify this.

> As you have been informed, during the last meeting we made steps to accept also
> the document/literal style and we are working on its implementation. But any
> good clients will need to support, now and in the future, both protocols,
> RPC/encoded and document/literal styles - we cannot afford to tell the
> service providers "please throw out your running services and start again".
> Therefore, if you are using only standard web-services style, your code is
> not smart enough to be worth to look at (see? - this is my bit of
> aggressivity :-)).
This is the case. My own implementation API (or package or how should I 
call it in BioMoby terms) is compatible both with rpc/encoded AND 
document/literal styles.
:-) Strange I see nothing aggressive here... Maybe because I'm Russian :-)

> Regarding other standard - the XML Schema (of the messages between client
> and services, not between clients and registry) - and the WSDL derived from
> the schema, I believe that you are not fully aware of the fact that there is
> no way to express the current BioMoby payload in the XML Schema (unless you
> change the schema with every request). Take it or leave it.
Completely wrong! (oops, sorry :-))
I have WORKING implementation of it if you look in this thread. As I 
said it is impossible to put the ONTOLOGY in WSDL 1.1 (while it IS 
possible in WSDL 2.0), but to make XML Schema for Moby Messages is 
possible and what I am trying to explain for the last three months.

Again my solution by now is to keep two parts separately - Moby Messages 
- a set of JAXB annotated classes that comply to "Moby Message" XML 
Schema and could be put into the WSDL Schema and
Datatypes - a set of JAXB annotated classes that comply the "Ontology" 
XML Schema. The last one couldn't be put into WSDL 1.1, but are 
processed by JAX-WS automatically.

> For BioMoby the future probably is in the RDF orientation and not to
> try go back to the compliancy with the XML Schema (Mark's words in my poor
> interpretation). But it would help people (like you) to understand why
> BioMoby payload cannot be fully expressed in an XML Schema if we document
> it. I believe that during the last meeting we agreed that the reasons why
> XML cannot be created will be documented soon (on the new BioMoby pages that
> are being created as we speak).
I think there is a misunderstanding. The ontology itself can not be 
described by XML Schema (That's why OWL/RDF exist), but the 
serialization format CAN.
Of course the problem is that in the WSDL schema there will be

<xs:any namespace="##other" processContents="lax"/>

In place of concrete datatype, so it's up to the web-service protocol 
correctly marshall/unmarshall it. JAX-WS can do this. In my 
implementation if JAX-WS find some unknown type it substitutes it by 
special object "AnyMobyObject" keeping the total structure intact (so it 
can have some AminoAcidSequence object as an attribute for example).

It is possible to make an implementation that in this case consult RDF 
or Biomoby Cental to dynamically generate the class, bu I see no reason 
in it, because there is no need in object when service/client has no 
idea about, but with "AnyMobyObject" they still can get all the 
properties. Well to be fair one reason is to cast this object to the 
known one...

Yours sincerely,

Dmitry