On 14 Nov, Till: [EMAIL PROTECTED] wrote: > Just my 2c. > > I think that an XML/HTTP integration of JBossMQ should be done by making > a JAXM personality of JBossMQ. I had a quite lengty mail conversation > with a guy a couple of month ago where we sort of tried to interpret the > spec in a JMS way. He said he was going to implement the stuff, but then > just disapeared. > > If this is the way to go, what should actually be added as a message > type is a SOAPMessage with attachement, I think. > > Unfortunately I do not have the time jsut not to implement JAXM on top > of JBossMQ. But if anyone else is prepared to do it I might be able to > help out (I have read the the fckn spec a number of times). > > //Peter >
Hi again, just saw that the JAXM has gone throug a ballot. If I understand it correct it was approved, but several heavy instances voted against it, among them apache, bea, ibm and compaq. I thing the reason from compaq gets the essence of the negative votes: "Compaq agrees with the issues raised by BEA concerning JSR 67 - JAXM. The JAXM specification has too much overlap with JMS. In addition, we have issues with the maturity and directions of the specification. We believe there are better approaches for delivering the capabilities that JAXM has tried to address. We believe the needs of the Java community would be better served by using JAX-RPC for synchronous XML/SOAP communication, and by extending JMS to handle XML/SOAP payloads for asynchronous messaging. The APIs for SOAP (with attachments) should be standardized as part f the JAX-RPC JSR (JSR 101). An additional effort should be undertaken to add XML/SOAP payloads to JMS. This should be an easy task, as proven by the large number of applications that are already doing so. This would create a much more unified approach to messaging that will be easier for the Java community to use and program against. A difficult aspect of this vote is the all or nothing nature of the outcome. A lot of good work has been done as a part of this JSR. In particular, the APIs for accessing and manipulating the SOAP portion of a message are an important byproduct of the JAXM specification that are useful for the JAX-RPC and JMS-SOAP. We encourage the JAX-RPC JSR effort to include this portion of the JAXM JSR and assume responsibility for its standardization without major redesign or significantly delay. We cannot vote for the JAXM JSR simply to get the SOAP manipulation APIs advanced to standardization. This would be the tail wagging the dog." If these big gyues get what they want it will mean that the JMS spec will eventually be agumented with a SOAP API, probably based on the SOAP with atachment specifyed in JSR 101. Any work done on this in JBossMQ should probably be based on that assumption. Just to have a SOAP with attachments would be neat. Ad to that an HTTP SOAP invikation layer and content based routing. Really, really neat. //Peter > > On 13 Nov, Hiram Chirino wrote: >>>From: Charles Chan <[EMAIL PROTECTED]> >>>Reply-To: [EMAIL PROTECTED] >>>To: Hiram Chirino <[EMAIL PROTECTED]> >>>Subject: Re: JBossMQ PM XAResource interface >>>Date: Tue, 13 Nov 2001 18:29:40 -0800 (PST) >>> >>>My initial idea with XML is simple... Just create an >>>XMLMessage type (extended from TextMessage). Create a >>>new Session interface that exposes the factory method >>>to create this type of message. We could also provide >>>a proprietary message selector based on XPath. That's >>>what BEA WebLogic basically do. >>> >> >> That would be cool. >> >>>However, after much thought, I think what you've >>>suggested made more sense. HTTP is becoming important. >>>We need a solid messaging framework over HTTP if we >>>want reliable web services. >>> >> >> I agree. >> >>>I am not sure if JBossSOAP uses JBossMQ as its >>>transport but it can't unless JBossMQ supports HTTP >>>and HTTPS. >>> >> >> JBoss SOAP aka JBoss.Net will use the apache Axis server for HTTP and HTTPS. >> What I want to do is be able either deploy a web service or a plain >> servlet that would allow JBossMQ clients come in over HTTP/S >> >> So what I think we need is an IL that kinda goes like this: >> HTTPServerIL -> (uses HTTP) -> MQHTTPServlet -> (JVM-IL) -> Server >> >> The hard part of this IL is going to be that the server can't directly >> invoke methods on the client. The client is going to have to poll for >> asynch message from the client by some thing like: >> >> 1. (Data structure accessible via the servlet) <- (JVM-IL) <- Server >> 2. Client pool -> (uses HTTP) -> MQHTTPServlet -> (Data structure accessible >> via the servlet) >> >> This approach would also let us run the web server in a different process as >> the MQ server since the JVM-IL in my example could be replaced with any of >> the other ILs. >> >> >> What do you think?? >> >> Regards, >> Hiram >> >>>Any discussion on this issue yet? I would like to look >>>deeper into this. :) >>> >>>Thanks >>>Charles > > -- Jobba hos oss: http://www.tim.se/weblab ------------------------------------------------------------ Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems Architect WWW: http://www.tim.se Email: [EMAIL PROTECTED] WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ------------------------------------------------------------ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
