beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <ekon...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Wed, 15 Jun 2005 00:17:12 GMT
  And, I do believe there is utility in remembering why things have
been done as they are.

  :)

  In this case, it seems that we've got two options to provide the
functionality that will expose the formal argument names for use in
WSM.  Basically, given something like this:

  foo(SomeType abc, SomeType def)

WSM needs to know "abc" and "def".  Today, this is done via the .ser
file.  The options seem to be:

1) generate the equivalent of a BeanInfo class for the web service
that would provide ParameterDescriptor instances from which the
parameter names (abc and def) could be obtained

2) generate an XML file that contained something like:

  <method name="foo">
    <parameter>abc</parameter>
    <parameter>def</parameter>
  </method>

for a method signature like "foo(SomeType abc, SomeType def)".

I don't have a strong feeling either way -- (1) would be debuggable,
though (2) is almost as  debuggable via a breakpoint in WSM code.  In
the absence of any other opinion, I'd probably lean toward (2) as the
BeanInfo provides way more information than is needed in this case and
(2) is pretty darn simple.

But, both are an improvement over the long-term problems with
serialized metadata.  :)

Any thoughts on either of these options from interested parties?

Eddie



On 6/8/05, Kyle Marvin <kylemarvin@gmail.com> wrote:
> On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com> wrote:
> > In WSM we don't generate any source code, so far ".ser" has been our
> > only artifact that we generated.
> >
> > If we want to go the route of generating any file, a XML file might be a
> > better option.
> 
> Early (pre-Beehive) versions of the Controls runtime took a similar
> path:  a single generic body of code (dynamic proxy-based) that used
> metadata/reflection as inputs to the process.
> 
> The transition to a JavaBean-based architecture made it necessary to
> do codegen... JavaBeans are (by definition) classes, not interfaces or
> proxies.
> 
> I've found the transition had other side benefits, one of which is
> debugability.  It's much easier to identify issues in generated code
> (often just by inspection) than it is bugs in metadata-driven dynamic
> behavior.   It's often also going to be more performant since direct
> Java invocation is faster than dynamic proxies/reflection... although
> if you put xml marshalling/unmarshalling on either side, this hardly
> matters :)
> 
> If you do go the codegen route, a key consideration is to keep the
> codegen as thin as possible (codegen thin classes that customize base
> functionality provided in runtime jars), as this will retain your
> ability to fix a wider scope of runtime bugs w/out requiring
> re-codegen.
> 
> I know you didn't ask for a history lesson... but maybe useful for posterity :)
> 
> -- Kyle
>

Mime
View raw message