The Helper class concept may be familiar to those who have used CORBA.
The Helper class provides implementation specific type information and
serialization assistance.
Decoupling the Helper and Bean classes allows the code to migrate in a
semi-independent fashion.
This is important if additional implementation code is added to the Bean or
if the meta data in the
Helper class needs to be regenerated.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
R J Scheuerle
Jr/Austin/IBM@IBM To: [EMAIL PROTECTED]
US cc: [EMAIL PROTECTED]
Subject: RE: Bean Class/Bean Class
Helper Generation
03/12/2002 09:21
AM
Please respond to
axis-dev
The intent of the Helper class is to provide the necessary flexibility to
use alternate meta data models and custom serialization.
----------------------------------------------------------------------
Let's use Doug's case as a scenario.
I am not sure how one would populate the BeanInfo class with meta data. (I
am not familiar with all the capabilities of BeanInfo.)
Let's assume that there is a way to set properties on the BeanInfo class
related to xml data.
Solution 1:
Doug would need to write his own BeanSerializerForBeanInfo that can read
the meta data out of the BeanInfo class. Ditto for the Deserializer.
Doug would need to write his own BeanSerializerFactoryForBeanInfo.
Ditto for Deserializer.
Doug would need to override the "type writer" in WSDL2Java. The
extended Java type writer would need to construct the "logical parts" of
the bean...as it does today. And the Java type writer would need to
generate code in the bean to set properties in the BeanInfo class (this
would be analgous to the static TypeDesc section in the current bean
generation).
Doug would need to override the "stub writer" and "deploy writer" and
change the emitted code to generate TypeMappings that use his factories.
Problems with 1:
He needs to override three emitter writer classes to get things to work.
He needs to keep track of any changes in these three complicated
classes. (We would need more architecture work on these classes to make
this easier to do.)
His generated Bean classes are tightly coupled to the BeanInfo class.
This is a problem if he adds implementation code to the Bean classes,
and later wants to switch to a new meta model...or enhance the existing
model. (So he has a very bad migration issue.)
Solution 2 (Assuming that we have a Helper architecture):
Doug would need to write his own BeanSerializerForBeanInfo...just like
above. Ditto for the Deserializer.
Doug would need to provide his own "helper writer" WSDL2Java. The
Helper writer would populate the BeanInfo class with the meta data.
Note that no changes are necessary to the logical bean class.
Pros with 2:
It is assumed that the axis BeanSerializerFactory/DeserializerFactory
would automatically locate the Helper class for a bean and pass this to
the serializer/deserializer. Thus no specialized TypeMapping
registration is necessary.
The logical Bean class is loosely coupled to the meta data. The Bean
class can be safely modified to add implementation specific code.
Changes to the meta model, or the use of a completely new meta model
only requires changing the Helper class...the Bean class is unaffected.
The use of a alternate meta models reduces the risk of Axis being
married to a particular model or implementation. I am not against
having default meta models, but the use of a particular model in the
runtime should not be forced. This makes it easier to switch models
without affecting users.
Swirl on 2:
It would be possible to provide a switch to WSDL2Java to embed the
Helper class inside the Bean class.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Russell
Butek/Austin/IBM@ To:
[EMAIL PROTECTED]
IBMUS cc:
Subject: RE: Bean
Class/Bean Class Helper Generation
03/11/2002 07:36
PM
Please respond to
axis-dev
Whoa! A -1 on moving the meta data out of the bean class!?!?! I hate to
be nasty, but I'm moving closer and closer (not QUITE there, yet) to saying
-1 on keeping it IN! It puts non-bean stuff on beans (bad bad bad). It
locks out the possibility of using beans that come from somewhere else in
AXIS. It might require users - who only use the bean stuff - to recompile
if this non-bean stuff changes.
I hope we're not at a philosophical impasse!
I'm gonna have to relearn the BeanInfo class, I think. See if Doug's
suggestion is doable.
Russell Butek
[EMAIL PROTECTED]
Tom Jordahl <[EMAIL PROTECTED]> on 03/11/2002 05:00:34 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Bean Class/Bean Class Helper Generation
-1 on moving the meta data out of the bean class and in to some other
place.
I find this mechanism simple and easy to understand and use (hey, what do
you know, I coded it). I do not think a helper class would be as
straightforward, nor would it be as easy for users to grasp quickly. I
don't see the advantage of emitting (another!) class.
I also don't see how we are limited by this architecture. It has already
proven its flexibility by getting extended (in a cool way!) by Glen. I see
nothing that would prevent us from dealing with "future expansion".
P.S. What do you mean the equals method "needs work"?
I think its pretty good for getting whipped off in 10 minutes at the
interop.
:-)
--
Tom Jordahl
Macromedia
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 11, 2002 5:15 PM
To: [EMAIL PROTECTED]
Subject: Bean Class/Bean Class Helper Generation
There have been several recent changes to the Bean Class generation to
support more advanced
xml features...namely attributes.
I applaud the new functionality, but we need to step back and consider a
more flexible architectural direction.
I would like to see all of the meta data information removed from the java
bean class and placed in a
Helper class that extends a Helper interface. Here is a first pass at the
Helper interface:
interface Helper {
public org.apache.axis.description.TypeDesc getTypeDesc();
public org.apache.axis.encoding.Serializer getSerializerAs(String
mechanismType);
public org.apache.axis.encoding.Deserializer getDeserializerAs(String
mechanismType);
}
The generated bean class should contain ONLY the getters/setters describing
the bean (and perhaps
the equals() method...which needs some work). This would adequately
decouple
the logical bean from the serialization/deserialization of the bean.
The BeanSerializerFactory/BeanDeserializerFactory could be tweaked to
always look for a corresponding
Helper class to find the meta data or find the custom
serializer/deserializer. The generic serializer/deserializer
classes should use default behaviour if the helper class is not available.
(In fact I am in favor of having
separate meta data aware serializers/deserializers.)
Separating the bean and the bean helper would allow users to provide custom
Helper emitters to
add custom serializers etc.
Please comment.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
