RE: Default bean mappings

[Sedukhin, Igor]

Title: Message

Glen,

 

I want to understand exactly what you're after here.  You're looking for transparent end-to-end Java->WSDL->Java, right? 

Pertty much easy Java->WSDL->.NET (C#) mostly for the sake of interop.

 

Right now, I think we may not even emit unmapped types for dynamically generated WSDL on a running service (since the type has to be mapped to be useful, and this is really a broken deployment).

They do seem to be emitted in WSDL right now. The example that I've included was from the real document generated by the latest build of Axis. I didn't place any explicit beanMappings when deploying. And I like it that way.

 

WSDL with type QNames like "java:myapp.address.model.Address".

How would that fit in WSDL? To get typeQName this way, schema definition should be like

<schema targetNamespace="java" ...>
<complexType name="myapp.address.model.Address"> ...

I'm not sure it will be interoperable with .NET for instance.

 

The bonus here is that GLUE (and perhaps WASP as well) do something exactly like this, and assuming our default mappings are the same, we'd get seamless interoperability with those toolkits.

I think the problem is more like WSDL does not define how a type hierachy should be translated back into language (or rather language-independent, UML-like) OO model. Even if we are interoping with these guys, .NET won't get it. So, rather than defining it for java specifically, we may pursue it in WSDWG to define type OO model interpretation rules for WSDL. I think it is really a big blank spot right now.

 

Currently, even though I have two namespaces for type representation, .NET  would flatten it out when generating a client proxy. I understand this -- there are no guidelines right now.

 

So, my proposition was to simply match SOAP processing pipeline to what Emitter is already doing anyways. It'll keep things interoperable in general sense, while still keeping it useful for future. The defaultComplexType check can be written such that it can be extended later to support whatever default template suggests.

 

-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 9:26 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Default bean mappings

I want to understand exactly what you're after here.  You're looking for transparent end-to-end Java->WSDL->Java, right? 

 

First off, for services where you have an explicit mapping of a type, you should get whatever QName you've mapped.  In other words, the "model.address.myapp" pattern will only happen when there is NO mapping for a particular type.  Right now, I think we may not even emit unmapped types for dynamically generated WSDL on a running service (since the type has to be mapped to be useful, and this is really a broken deployment).

 

Into the future, I can see two ways of doing this, one of which we've been discussing and one of which we haven't yet.

 

1) Use a well-defined "java:" namespace by default for generated WSDL without explicit mappings.  In other words, we allow you to deploy services with NO typemappings even on the server side, and we'll generate WSDL with type QNames like "java:myapp.address.model.Address".  Then our stub generator does the right thing with auto-mapping these guys to the right classes when it sees one of those types.  The bonus here is that GLUE (and perhaps WASP as well) do something exactly like this, and assuming our default mappings are the same, we'd get seamless interoperability with those toolkits.

 

2) Optionally emit an extensibility element (axis-specific) for ALL generated types, which indicates a "suggested" Java class to use.  This would allow our stubgen to be smart about this as well.

 

Neither of these options rely on having to deconstruct a particular namespace generation scheme, which I think would be VERY brittle.

 

Cheers,

--Glen

-----Original Message-----
From: Sedukhin, Igor [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 8:55 AM
To: [EMAIL PROTECTED]
Subject: Default bean mappings

This bugs me for a while already. May be there is a reason it is happening this way, but please refresh me on it.

Here is what:
By default Emitter generates type namespaces and type declarations like this:
<wsdl:definitions ... xmlns:tns1="http://model.address.myapp" ...>
<types>
<schema targetNamespace="http://model.address.myapp" ...>
<complexType name="Address"> ...
This is basically for a class myapp.address.model.Address.

So, why is it that I had to explicitly declare beanMappings during the deployment for proper ser/deser to be selected by the RPCHandler? It seems it is very easy to try and reconstruct a class name from the default assumption about the namespace format and then check if the class is loadable, then only apply explicit beanMappings.

I'd really like to get it this simple.
It is possible to change DefaultTypeMappingImpl to implement getTypeQName, getSerializer and getDesearializer to take care of it as explained above.

Does anyone have objection or comments on this?

-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788