> For example, if the WSM annotation processor produced a JSR 101 / > 109 deployable unit (or the source files / descriptors for such a > unit), it might include enough information that the .ser file wouldn't > be needed. In this case, Beehive WSM only runs at build time and > doesn't have a runtime component.
In the ".ser" mode of thinking the deployment descriptor for say 109 would be generated from the .ser file. The idea is that 109 translator would not have to worry about any of the validation and defaults, it has a valid .ser file that it can work off. I am not sure where the spec is going on this, but it seems to me once you have annotations the idea of 109 descriptor is rather obsolete. You would think the container can figure most (if not all) of the information from the annotations that are in the class files. I see your concern, and far as WSM is concern, my personal view is that having a configuration file (.ser) defeats the purpose of the annotations. I also feel that even if you do all the validation at build time, the classes that the run time sees may not be valid (e.g. missing classes). So even though you want the build time validation we can't avoid having the runtime validation. I think what is missing from the current system, or where we went wrong, is that we dropped the ability to build the service model from class files and started to only rely on the build time artifacts. In our Alpha (also in Beta I think) release of the WSM we only did the runtime deployment from class files, and it all worked fine (well except the default parameter names). I see three ways of building the web service object model: a) from WSDL, b) from mirror events, c) from class files. The (a) case would be used by the "from wsdl" use case in WSM and service control. (b) Would be used by IDEs or build process, (c) would be used by run time environments (also 109 type descriptor generator tool that would run during the build process). The (b) and (c) differ in the way the annotation information is collected from the files, but they both use the same underlying implementation to enforce the Jsr 181 rules and defaults. The (a) case would use a different implementation where XML-Java rules are enforced. Make snese? Daryoush On 6/16/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > Sure... > > So, today, the WSM annotation processor produces .ser files in order > to allow a web service stack (Axis 1.2 today) to discover the formal > argument names of methods exposed as @WebMethod. > > I was speculating -- which perhaps I shouldn't do :) -- that if WSM > were to target a web service technology in addition to Axis that the > .ser file wouldn't necessarily be needed. > > For example, if the WSM annotation processor produced a JSR 101 / > 109 deployable unit (or the source files / descriptors for such a > unit), it might include enough information that the .ser file wouldn't > be needed. In this case, Beehive WSM only runs at build time and > doesn't have a runtime component. > > I agree that there is nothing Axis specific in the .ser file and was > just making the point that the .ser file might not be needed depending > on how WSM is integrated into Axis or if / when WSM targets additional > web service stacks / standards. > > I'm not a web service expert by any means (clearly!), but it seems > like generation / use of the .ser file should be a *choice* and not a > requirement. > > Does that make more sense? > > Eddie > > > > > On 6/16/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > Eddie in the previous thread you said: > > > > The .ser file is an artifact of the fact that the services are > > deployed on Axis. Were the annotation processor targeting JAX-RPC > > directly, the output of the annotation processor might not use the > > .ser file. > > > > > > > > I am not sure I follow your point here. As I said in the previous thread on > > the .ser file, the original of this was to solve the parameter name default. > > We started off in WSM by deploying source and compile at runtime (similar to > > the drop in deployment model in Axis), then evolved into having seperate > > build time and run time phases that deployed services by doing reflection on > > .class files, to the current iteration that uses the .ser file which means > > all the work is done at build time.. > > > > You have looked at the .ser file more closely recently, but AFAIK, there is > > nothing Axis specifc in it. It is essentially the 3rd itteration of the > > model we are using to deploy services. It is true that our Axis > > implementation understands the .ser file, but if we were say to port the WSM > > to XYZ stack, our apprach would be to write an extension in the XYZ stack > > that would understand the .ser file. > > > > I don't follow what you mean when you say if we were "targeting JAX-RPC > > directly....". Can you please be more specific here. > > > > > > > > -- > > Daryoush > > > > Weblog: http://perlustration.blogspot.com/ > > > > > -- Daryoush Weblog: http://perlustration.blogspot.com/
