Hi, Andrus, Kevin, All.
Yes. We need to talk about this things.
0. Entity Resolving. I think, that best way for it is to keep some
configuration on both client side and server side. Some kind of entity
(or schema) names can be transported over the net and on the both
sides these names can be resolved in manner they want.
> Michael,
>
> I see some of your design-related notes in the code (e.g.
> AxisConnection has a note about EntityResolver). Please do not be
> afraid to post them here. We want to include this code in Cayenne at
> some point, so let's discuss this in public.
>
> Lots of this stuff is research... What I was hoping to achieve here is
>
> 1. expose what we have already in Hessian to the world in a standard
> form (WSDL), just to see how people might use it.
1. Currently I am doing so. I am writing set of inherited serializers
for Cayenne objects in AXIS manner. Object structure of Cayenne is
rather complex. Abstract classes and interfaces used very often in all
kinds of objects. And it is not comfortable to use this complexity
with SOAP.
I see 2 ways:
1. Make adequately big XML schema for Cayenne class hierarchy and
bring it to WSDL. Make serialization mechanisms for this. Of course
there will be changes between schema and actual class hierarchy. And
some architectural changes needed (entity resolving etc). This will
bring things, which works on hessian to SOAP and most of core Cayenne
code will not be changed.
I choose this way. And i think, it will work.
2. Hardly change Cayenne architecture to make it good for easy
platform independed SOAP interchange. I think, this way is better for
making good web service from Cayenne, but big refractoring needed and
I am not sure, that results will be adequate to work done. I will
write some ideas about it in the rest of this letter.
>
> 2. develop a serialization technique that doesn't require redefining
> WSDL for each new set of objects (CayenneDataObject may be an ideal
> candidate for the "generic object" used in the transport layer). Once
> this is in place, current Hessian transport can take advantage of
> that as well, removing the ugly requirement to keep client classes on
> the server.
2. I see, actually CayenneDataObject is Map of object properties and
their values and few other things. It's very easy to serialize them
(if I can get that Map correctly...). I use it to transport objects.
To remove classes from serverside some method needed to create
CayenneDataObjects from results of queries on serverside without
casting them to business-logic classes. I think, it is not very hard.
>
> 3. develop a base for implementation of clients in other languages.
> So yes, I agree with your comment that it is wrong for the server to
> tell the client what classes to use; however the rest of the
> EntityResolver is fine, this is just abstract entity metadata, mostly
> platform-independent (ok, the property types are also in Java, guess
> we can leave them as is for now, and later remap them as some
> "neutral" XMLSchema types or something).
>
> This is just my thoughts, certainly not a roadmap for you. But it
> would be nice if you could share your direction as well :-)
>
> Andrus
3. Other languages. Currently schema part of WSDL includes many
Cayenne dependent types, such as ObjectId, CayenneDataObject etc. Most
SOAP frameworks and programming platforms have tools (and AXIS too) to
regenerate classes from WSDL. So to create client in other language we
need to regenerate these classes from WSDL and to add Cayenne client
functionality to them. As I wrote earlier, schema is complex enough to
conform Cayenne class hierarchy.
4. Ideas... I will describe architecture. I need comments...
Server side:
- Knows from config how to map database tables to XML schema
structures. (Currently Cayenne maps DB to Java classes, so we change
it to schema complex types).
- Can process queries (brought from net). Serverside keeps query
results in something like CayenneDataObject.
- Can dynamicaly produce WSDL with configured objects (...from DB to
schema mapping...) in it's schema part.
- Can serialize that (...something like to...) CayenneDataObject to
actual XML types as declared in schema and configuration.
Client side:
- Knows from config how to map schema objects to Java (or other
language) types and how to bring remoting functionality to them.
- Can deserialize these schema types straight to their Java mappings.
So what we have:
- No client-side language classes at serverside.
- Client do not need to work with Cayenne-specified things like
ObjectIds etc.
- To write client on other language we need to regenerate from WSDL
business-logic classes and classes to make queries. We need not to
generate Cayenne classes hierarchy.
What is bad:
- Too many things to refractor.
Comments...???
--
Best regards,
Michael Victorov
