beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: Role of .ser file in WSM
Date Thu, 07 Jul 2005 16:58:40 GMT
Good questions, here is why I came to this idea

On 7/7/05, Rich Feit <richfeit@gmail.com> wrote:
> A few questions about this (again, I'm just trying to educate myself here):
> 
>     - If WSDL is the "overwrite" format, then this means deployment-time
> overwriting would have to be done through WSDL, right?

Yes, by editing the WSDL file.

>     - Let's say that *all* the extra information you need is parameter
> names.  Can valid WSDL be sparse enough to make sense for this?

The WSDL is not sparse, just that the type information is not there. 
The JWS file specifies the method and the parameters of the method. 
From the JWS we can determine the top level element of the types but
not the schema of the type.    The schema of the type is
responsibility of the type class.   Looking at the source code of the
type you simply can't determine the schema of XML the class would
generate.

Take a look at this : 
http://e-docs.bea.com/wls/docs81/webserv/customdata.html#1060764

A Soap stack, in this case BEA's stack, would need to allow ways for
types to do their own special serialization.  Hence you wont be able
to predict the schema of a class just by  APT processing.

The type information would not be needed, or even useful anyways.  As
it should not be possible to change your schema types by just editing
your WSDL, you would need to go back to you classes and make the
changes.


>     - Why wouldn't it be possible to generate type information during
> apt processing?  apt/Mirror gives you a superset of what you have at
> runtime.  Or is it just logically impossible to get the right
> information during the processing stage?

see the above comment.

>     - At a root level, why is WSDL a better format than an XML schema
> that conforms more to the model?

1) WSDL is standard, albeit complex.  

2) It would allow the deployer to change the configuration of the web
service beyond the parameter names.

3) Even though WSDL is complex, we would have to deal with its
complexity anyways.  181 allows a JWS to specify its own WSDL file(
@WebService.wsdlLocation).  I belive this means that we need to
generate the WSDL for the service at build time (we don't right now, 
it wont be difficult to do – minus type information).

At run time we also need  to have code  to read the WSDL and compare
it to the JWS.    We can define the differences that are acceptable,
and differences that are not acceptable.  And differences that would
cause a change (overwrite) in the service configuration.

> 
> Thanks,
> Rich
> 

daryoush

> Daryoush Mehrtash wrote:
> 
> >An idea from "sleepless night in Seattle" :)
> >
> >I think there is an overall agreement that we need *something* to keep the
> >missing information form class files. And we all seem to agree that the
> >serialized java file is not the right solution.
> >
> >Instead of creating yet another XML file, why not just use a WSDL file to be
> >the additional information. We can build a WSDL (minus its type information)
> >during the APT process. In run time the code would look something like:
> >
> > Load the object model from reflection (java.reflection or ASM)
> >
> >If there is a WSDL file
> >
> >To the extend possible use the WSDL information to over write the JWS
> >settings
> >
> >Make sure there are no conflicts between WSDL and JWS file
> >
> >Run the web service….
> >
> >I don't believe it would be possible to generate the WSDL's type information
> >during the APT processing. Furthermore, the real WSDL of the service is
> >generate by the SOAP stack, and may be different from the WSDL file that is
> >generated during the APT processing. Nevertheless I think the WSDL (or a
> >subset of a complete WSDL) would be a logical format to keep the missing
> >information.
> >
> >Thoughts?
> >
> >Daryoush
> >
> >
> >On 7/6/05, Daryoush Mehrtash <dmehrtash@gmail.com> wrote:
> >
> >
> >>Yes. We essentially need some information that is lost when the JWS
> >>files are compiled. The curent solution is to build the complete
> >>object model during the APT build process. The model containes all
> >>that is needed to run the web service (information on the web
> >>servicer, every method, parameter etc). Most of the information is
> >>available from the class file, so the serialized information is
> >>redundant, and as Eddie has said at time the information is not even
> >>valid.
> >>
> >>For run time I am proposing we build the model of the web service from
> >>the JWS class file, but have a file that would over write the
> >>information in the class files.
> >>
> >>At build time we can save the missing information to this file. We
> >>only need the parameter names, but the same mechanisem could
> >>potentially be used by a deployer to overwrite the information in the
> >>class files.
> >>
> >>Right now we are dependent on APT process. But in my model you can
> >>also work based on straight Javac. Although with APT you get a more
> >>conformant (default parameter names) implementation.
> >>
> >>Daryoush
> >>
> >>On 7/6/05, Richard Feit <richard.feit@bea.com> wrote:
> >>
> >>
> >>>Just to make sure I'm clear on this, we're talking about something that
> >>>*was* a Serialized object written to a ".ser" file, but that will no
> >>>longer have anything to do with Serialization? The "overwrites" that
> >>>you're talking about are simply the parameter names, written to XML?
> >>>
> >>>Just trying to understand -- I haven't been involved in the coding of
> >>>this piece, so I'm starting from scratch here.
> >>>
> >>>Thanks,
> >>>Rich
> >>>
> >>>Daryoush Mehrtash wrote:
> >>>
> >>>
> >>>
> >>>>Beside the format of the ".ser" file we also need to reach closure on
> >>>>its content and its role.
> >>>>
> >>>>Right now the .ser file contains the complete model and is the sole
> >>>>means to build the object model at run time. I think we need to change
> >>>>both aspect of the .ser file.
> >>>>
> >>>>My suggestion on this is to always build the run time object model of
> >>>>the web service based on Reflection (or similar class analysis e.g.
> >>>>
> >>>>
> >ASM)
> >
> >
> >>>>and use the ".ser" (in any format you choose to keep it) to overwrite
> >>>>the reflection information. The ".ser" then doesn't have to be a
> >>>>complete model, rather it would only contain the overwrites. The
> >>>>overwrites would take precedence over the class file annotations and
> >>>>would be used by the build process, or deployment process to control
> >>>>
> >>>>
> >the
> >
> >
> >>>>final web service.
> >>>>
> >>>>
> >>>>Daryoush
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Eddie ONeil [mailto:ekoneil@gmail.com]
> >>>>>Sent: Wednesday, July 06, 2005 10:13 AM
> >>>>>To: Beehive Developers; mmerz@acm.org
> >>>>>Cc: Eddie O'Neil; Daryoush Mehrtash
> >>>>>Subject: Re: Role of .ser file in WSM
> >>>>>
> >>>>>And, again, I can see the value of having *something* that conveys
> >>>>>this information (the formal argument names), but I disagree with
> >>>>>using a serialized Java object to convey this information -- the
.ser
> >>>>>file.
> >>>>>
> >>>>>Seems to me that there are more architecturally flexible / loosely
> >>>>>coupled ways of conveying this information than serializing the entire
> >>>>>object model (which includes fully-qualified paths from the build
> >>>>>environment). Information like these fully qualified paths shouldn't
> >>>>>be made available to the runtime side.
> >>>>>
> >>>>>That's why I was suggesting either XML or a generated BeanInfo file.
> >>>>>
> >>>>>Hope that's clear...
> >>>>>
> >>>>>Eddie
> >>>>>
> >>>>>
> >>>>>
> >>>>>On 7/6/05, Michael Merz <michael.merz@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi guys,
> >>>>>>
> >>>>>>Sorry for the late response -- I've been *really* busy for a
while
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>;)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>There were reasons for using a .ser file, the most prominent
one
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>being
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>that interfaces will *not* contain the parameter names of methods
--
> >>>>>>even when compliled with the debug version. A serialized object
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>model
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>file seemed to be the only way of capturing all information.
> >>>>>>
> >>>>>>I agree that the .ser-file/object model needs some clean-up since
it
> >>>>>>has "grown". If you'd like to work on it, I would suggest storing
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>all
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>metadata (as it will be used, i.e. with defaults where applicable)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>in
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>a .ser file rather than just select/currently required information
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>and
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>to stay closer to the way that information is organized in 181.
> >>>>>>
> >>>>>>Cheers,
> >>>>>>
> >>>>>>-michael
> >>>>>>
> >>>>>>--
> >>>>>>Michael Merz
> >>>>>>mmerz@acm.org
> >>>>>>
> >>>>>>
> >>>>>>Yeah -- if at all possible, it seems good to avoid generating
code
> >>>>>>in the WSM case just because we don't need to, though it's a
good
> >>>>>>point -- I'd forgotten controls did that.
> >>>>>>
> >>>>>>But, it could definitely work either way. A source code file
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>seems
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>easier to deal with than a serialized object for the obvious
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>reasons.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>It's just that the XML file seems sufficient for today's needs...
> >>>>>>
> >>>>>>Eddie
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>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.
> >>>>>>>=20
> >>>>>>>If we want to go the route of generating any file, a XML
file
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>might be
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>a
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>better option.
> >>>>>>>=20
> >>>>>>>daryoush
> >>>>>>>=20
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: Kyle Marvin [mailto:kylemarvin@gmail.com]
> >>>>>>>>Sent: Wednesday, June 08, 2005 2:34 PM
> >>>>>>>>To: Beehive Developers
> >>>>>>>>Subject: Re: Role of .ser file in WSM
> >>>>>>>>
> >>>>>>>>On 6/8/05, Daryoush Mehrtash <dmehrtas@bea.com>
wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>.ser file exist for one reason and one reason only.
JSR 181
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>says
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>that
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>name of a @WebParam by default is:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Name of the parameter as it appears in the argument
list.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>The issue is that this name gets lost after the class
is
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>compiled.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>The
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>original WSM was based on Reflection that there was
no
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>Serialized
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>file.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>An alternative solution is to require the JWS files
to be
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>compiled
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>with
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>Debug option which preserves the argument names.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Is it needed? Well it depends on your preferred method
to get
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>>>argument name: require the user to compile its JWS
in debug,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>or
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>keep
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>the serialized file. Is there a third option?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>The Controls runtime stores method parameter names into
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>generated
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>code
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>associated with the original interface. These names are
used
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>to
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>>support named argument lookup during extensible method
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>invocation.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>=20
> >>>>>>>=20
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>--
> >>Daryoush
> >>
> >>Weblog: http://perlustration.blogspot.com/
> >>
> >>
> >>
> >
> >
> >
> >
> 


-- 
Daryoush

Weblog:  http://perlustration.blogspot.com/
Mime
View raw message