Thanks everyone for a valuable insight to this topic. Let me summarize, what I have heard so far related to my need and still try to resolve my open questions. It definitely looks like WS-RM is just too premature and even not complete for my inside firewall requirements. However, issue related to JMS goes back to my original question,
1. SOAP over JMS is not a standard, 2. The vendors that are proposing this spec do not seem to be getting traction, as there is a large Messaging QUEUE vendor who may not care about it. 3. Though, I have a limited vendor interoperability experience, whatever SOAP implementation that I have seen so far has been done by tight coupling with protocol (either HTTP or JMS but, NO transport decoupling). So the question really is can I represent SOAP (independent of transport) and get all the benefits of SOAP, WSDL, UDDI? What issues do I need to worry about it? e.g. Can I use Systinet for UDDI to store WSDL interface which doesn't have transport set? Any issue in creating SOAP/WSDL and passing it over using JMSSend ()? In other words how can I avoid SOAPAction (Vendor 1) and soapAction (Vendor 2) issues? I believe SOAPAction/text vs byte support etc comes when we explicitly select SOAP over JMS binding explicitly. I can do some POC to answer this question, but some explanation can certainly help. Thanks, Unmesh --- In [email protected], Steve Ross- Talbot <[EMAIL PROTECTED]> wrote: > > Todd, > > I'm not saying that I don't want it reliable. I certainly do. But I do > not > need WS-RM to get that. I only need a JMS provider that ensures an > appropriate SLA/QoS on the publishing of a message. Most JMS providers > give me this and I don't need any WS-RM to get it. So my question is > that > within the firewall why would I want to use WS-RM? What business > imperative > would lead me down a WS-RM path? I just don't know what the answer is > but anyone who is a vendor of WS-RM based messaging or comms I would > imagine does have an answer and that is what I would like to hear. > > I take you point about the weakest link. Weakest links become a problem > when > you go outside of the firewall. And I can see a need for something that > can > help me in this regard. But my point is within the firewall. And the > reason why > this is important is this is where many software projects start from. > So you > either need to address it to those that choose technology to implement > within > the firewall or explain how it fits a wider picture so that they make > informed > decisions. > > Cheers > > Steve T > > > > On 1 Apr 2006, at 14:25, Todd Biske wrote: > > > Just because it's internal, doesn't mean we don't need it sent > > reliably. Chances of a failure are probably far less, but if it's a > > mission critical order processing system, reliability is important. > > > > One thing that must be considered, however, is that the whole thing > > must be reliable. It's only as reliable as it's weakest point.  > > Therefore, if I use reliable messaging for the front end to talk to > > the order entry system, but my front end is web-based, I still have > > issues to deal with. If the browser request when I hit "Place Order" > > times out, I have no idea what the state of the system is anymore.  > > In this case, designing the interfaces so they handle repeat > > submissions properly is very important. If it can handle repeat > > submissions, then you may be able to say that reliable messaging > > really wasn't necessary. It's a complex problem. Too often, we just > > throw a technology at it, rather than really understand the problem.  > > Often times, the technology is far more expensive than just creating > > a process where a person figures out what's wrong in the .001% of > > messages where it times out, but yet we do it anyway... > > > > -tb > > > > On Apr 1, 2006, at 4:41 AM, Steve Ross-Talbot wrote: > > > > > If you were building an application that is totally within an > > > enterprise what compelling reason would make you even look at > > WS-RM? I > > > can see if you cross organisational boundaries this stuff might be > > > attractive but if you are within a domain of control (an > > organisation) > > > then I cannot see why you would use WS-RM. If you have MSoft on the > > > desk top you can always use ASP.NET Web Service style and pass to a > > > service that is a proxy for JMS. Any light on this would be most > > > welcome. > > > > > > I might just be behind the times. > > > > > > Cheers > > > > > > Steve T > > > > > > On 31 Mar 2006, at 17:52, Logan, Patrick D wrote: > > > > > >>> The response was "who needs WS-RM, just use JMS" > > >> > > >> I would be interested in real experience reports comparing these > > two > > >> approaches. How well does WS-RM line up with the various > > >> capabilities > > >> of > > >> JMS, and how well various vendors' implementations of WS- RM > > >> implement > > >> the standard, how well they interop with each other and so on. > > >> > > >> Is WS-RM even a standard yet? > > >> > > >> Unless someone can produce the information above, I'd have to say > > >> the > > >> better investment for the time being would be in JMS. > > >> > > >> I am willing to be convinced otherwise, but I've not found a > > >> shred of > > >> support for that yet. I'd *really* like to see it so please > > respond. > > >> > > >> I'll have to interpret no response as implying no evidence. > > >> > > >> Thanks > > >> -Patrick > > >> > > >> > > >> > > >> YAHOO! GROUPS LINKS > > >> > > >>      ⪠     Visit your group "service- orientated-architecture" > > on the web. > > >> > > >>      ⪠     To unsubscribe from this group, send an email to: > > >> [EMAIL PROTECTED] > > >> > > >>      ⪠     Your use of Yahoo! Groups is subject to the Yahoo! > > Terms of > > >> Service. > > >> > > >> > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > YAHOO! GROUPS LINKS > > > > ⪠ Visit your group "service-orientated-architecture" on the web. > >  > > ⪠ To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > >  > > ⪠ Your use of Yahoo! Groups is subject to the Yahoo! Terms of > > Service. > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
