Cleaning up my mail box...
I believe this is a clear match for RH.
Jung, the microkernel arch with JMX bus plugs nicely with the detyped
invokers and adding an XML invoker is still a bit priority. In fact I don't
see a reason why any service in JBoss wouldn't be invocable through SOAP
that is the power of the detaching going on in RH.
BTW the same logic applies to the clustering of the invokers... I will try
to show that in the coming days,
regards
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr.
|Christoph
|Sent: Monday, May 14, 2001 11:54 AM
|To: '[EMAIL PROTECTED]'
|Subject: [JBoss-user] Open letter: ZOAP is dead, long live JBossSOAP!
|
|
|
|
|> -----Urspr�ngliche Nachricht-----
|> Von: Jung , Dr. Christoph
|> Gesendet: Montag, 14. Mai 2001 10:33
|> An: '[EMAIL PROTECTED]'; Jboss-Development (E-Mail);
|> '[EMAIL PROTECTED]'
|> Betreff: Open letter: ZOAP is dead, long live JBossSOAP!
|>
|> 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-user mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
