Hi Sanjiva:
Sanjiva Weerawarana wrote:
-1 .. :(. All of that stuff is about doing yet-another-RPC-SOAP-thing.
All of that stuff is about a) RPC encoded support, and b) easy
interoperability/usage for Java coders. Both of which were discussed at
the last f2f, and agreed to by the team.
I don't agree that we need to *build into the core of Axis2* every
possible thing that Axis1 did. If we go with that all the way, then we
have no room to create anything new .. all we're doing is reimplementing
what we had before.
I couldn't disagree more, Sanjiva. Axis2 is quite different from Axis1
in any number of ways already - let me just list a few:
* Deployment model (aars, directory-based, hot-deploy)
* Module architecture
* Async built-in
* Extensible context architecture
* OM (and resultant performance gains)
None of these go away just because you're using data/operation binding.
Disabling simple "code-first" use cases and the ability to map basic
schemas to code in friendly ways would, IMHO, be a silly thing to do.
Why wouldn't you want Axis2 to be as easy to use out of the box as GLUE
or WASP? Just because people want to use that stuff doesn't mean that
the engine doesn't still a) benefit from the speed/architecure
improvements, and b) allow for the XML-centric use cases as well.
I know there are many people in the world who *still* want to use Web
services to SOAP enable RPC stuff. If that's what you want to do then
Axis1 does one hell of a job of doing that; please keep using it .. the
code works fine and many smart people have put in a lot of effort on it.
...and people also want to do this stuff with the benefits of Axis2.
IMO Axis2 is about future Web service stuff where its much more than
about RPC style stuff. That's why to me it is *fundamental* that data
binding is not in the core and that data binding has nothing to do with
the message exchange pattern. I've converted over time ..I used to be an
RPC style bigot too but now I'm totally convinced that the value of Web
services will show thru much better when we start adopting XML all the
way through. Data binding is contrary to that view; hence my desire to
keep it out of the core.
First, the data binding doesn't have anything to do with the MEP, I'm
not sure where that comes from...?
Second, this really hinges around what "core" means. If you mean
"should it be in the distribution", my answer is an EMPHATIC "yes". If
you mean "should it be in the axis-core.jar file", then I'm open to
discussion - I'm perfectly fine with having this framework be a
"standard extension" in a separate jar which can still be easily used
out-of-the-box without downloading other packages.
I think we should do the work to produce something that does this work,
whether using JiBX/XStream or building it ourselves, and I think it
needs to come with the download. Aside from that, I'm +1 to having it
be pluggable or not used at all by XML-puritans.
While I agree with David Sosnoski that many people do and will continue
to start with a piece of code and "Webservicify" it, I disagree that
that's what Axis2 should be focused on. We put a lot of effort to create
the MEP & context framework which allows one to deal with any kind of
MEP. And the reality is that starting with Java code is a flat out lousy
way to implement anything except in-out type MEPs - that's all the Java
programming model gives you in its guts: a method call. If you want to
do other stuff (including a simple in-only or out-only) then Java code
is not a great way to start .. you need to start at a "higher" level and
then write the code .. or take Java code and annotate it to death.
Again, I disagree here. :( I think the question of binding MEPs to Java
is separate from the question of binding schemas to Java, and I think
frankly that we are going to need to deal with the MEP-binding issue no
matter WHAT data binding framework we use. The moment you move away
from a service class that looks like:
class Service {
public void receiveMessage(MessageContext mc) {
// Process ANY and ALL messages for this service
// with no help from the framework
}
}
...you immediately need to deal with things like how MEPs bind to Java.
It really comes down to why we are doing Axis2. For some its to try to
gain performance improvement out of going to a StAX model etc.. While I
agree that is a VERY important requirement, I would put the priority of
that requirement below the priority of making it an idea framework for
doing all kinds of asynchronous message exchange patterns. So I'm not
saying Axis2 cannot be used to write a super-duper-best-of-breed
yet-another-RPC-SOAP-thing; what I want to see is that "old" RPC stuff
kept out of the core to the maximum possible extent. Yes so I can live
with leaving hooks to make that work, of course.
See above. I think you're perhaps being a little reactionary here... I
don't think it's as black-and-white as you make it out to be.
--Glen
