Dear fellow JBoss developers, dear JBoss board, dear JBoss users striving
for SOAP-support in their favorite bean container!
As the initiator of the ZOAP module, I must excuse for making myself quite
scare to the JBoss-lists for the last months (this was not only because of
having huge ssh-problems accessing sourceforge) - hereby leaving many people
puzzled about the state of the project. My professional engagement (as you
all have experienced: first your have to earn bread, then the butter) does
not allow me anymore to operate as the single architect, developer,
documentation writer and (perhaps the most important role, from what I
learned during the past year) supporter of the module.
I have to admit that this typical OS dead-end situation has been my own
fault: I made a lot of mistakes when it comes to finding the right way of
attaching to existing code, sharing the results, engaging people,
advertising the project, etc. My only excuse is that I was coming straight
from university/research at that time and I had to learn a lot about
"real-world" programming practices in general and engaging into Open Source
in particular ...
Maybe also the point in time (mid-2000) when we were first propagating SOAP
for EJBs was rather early such that
- there was not yet any broad need, and
- there was no fixed and accepted standard to which you can commit
to
(see the Apache-MS-SOAP-interoperablity thread that is relevant
until today!).
Hence, the decision to write a proprietary and generic (de-)serialisation
framework was motivated by IBMīs/Apacheīs neglectance of DOM-impasses,
XML-Schema and most of EJB. This decision has helped me to deepen my
understanding of which added-value purist XML-middleware could introduce
into todays business platforms (and we have a working system based on that
ideas here at infor). But this has in turn cost a lot of resources and,
finally, acceptance in the community.
IMHO (and I refer to the latest contributions to the mailing-lists as
examples) this situation has changed now. The role of XML in business
frameworks has been widely recognized and emphasised. The need for our
beloved JBoss beans to interoperate with XML-enabled Web-applications is
definitely there. And the SOAP standard has now a quite accepted and fixed
basis; Open Source implementations such as Apache and IdooXoap are heading
towards practicability. Thus, it would be silly to neglect SOAP in a
first-class project such as JBoss and it would be even more silly if an
existing, but more or less closed module, such as ZOAP, would prevent doing
a first-class integration of SOAP into JBoss.
After having put enough ashes onto my head, here is now a proposal how to
proceed:
- Letīs face the dead of the ZOAP (code).
- Letīs find out who is still interested and willing to
contribute to the issue of integration XML/SOAP into jBoss.
- Letīs discuss the prime needs of the community with respect to
this topic.
- Letīs initiate the "real" JBossSOAP project as a properly
structured contrib-module which takes over
Apache/Axis/whateverCodeIsMostAppropriate in a realistic setting/timeframe
with several architects/developers,
supporters, example and documentation writers, and testers.
- first a plain but most useful
invocationhandler-invoker-integration with servlets using the pure
Apache/.../...
(the ZOAP code and existing knowledge on the JBoss-lists
could certainly give some useful hints for reaching
this in a couple of weeks)
- later we could think about integrating Castor for doing
more advanced mapping/serialisation (here, the ZOAP mapping
idea could survive, but in a more standardised setting)
- MDB-support
- ...
I would like to ask the board to evaluate and comment my email/proposal. If
we somehow agree on that issue being important and promising, I would ASAP
care about updating the web-presentation, inform the community, etc.
I would like to ask interested developers that have already done or that are
about to do some Apache-SOAP/whatever-SOAP integration
to join this effort as I am convinced that sharing knowledge and code will
pay off in the long run. If there are enough people committed,
we will agree on an architecture (first cut should be quite straightforward)
and start we will committing source and doco ;-)
And I would like to ask anyone interested in this topic to share experiences
and needs such that we will not run into a dead-end again.
Peace,
Dr. Christoph G. Jung
Software Engineer
infor: business solutions AG
http://www.infor.de/
mailto:[EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
