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/
