Re: [service-orientated-architecture] RE: Messaging Standards-(Reliable and Durable)
- 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
I might just be behind the times.
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
> 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.
> YAHOO! GROUPS LINKS
> ▪ Visit your group "service-orientated-architecture" on the web.
> ▪ To unsubscribe from this group, send an email to:
> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
- On 4/7/06, Gregg Wonderly <gergg@...> wrote:
> Mark Baker wrote:As Jan said, what I said above doesn't imply HTTP, just uniform
> > Gregg,
> > On 4/5/06, Gregg Wonderly <gergg@...> wrote:
> > > The issue with REST is that it considers HTTP as the invocation layer too, with
> > > the PUT, GET, POST, etc operations as the fixed set of "functions" that you can
> > > invoke.
> > Right, nicely said.
> > > In a more sophisticated invocation layer, you can imagine the use of
> > > multiple wire protocols such as HTTP being used to perform a single server side
> > > operation.
> > Separating the concerns of application operations and on-the-wire
> > representations had value in CORBA, DCOM, DCE, RMI and other RPC style
> > systems, because they had to support a wide variety of interfaces and
> > operations. But once you embrace a fixed set of operations, the value
> > of keeping these layers separate, drops.
> Except when HTTP is not available. That's the issue. Not everything is HTTP
> and not everything works with HTTP.
operations. SMTP - email - also has uniform operations, just less of
them than HTTP. i.e. it only has an equivalent for POST ("DATA"), not
of GET, PUT, or DELETE.
> I think your view of "services" is still confined to "transfer a document."Absolutely.
> This is by far the least common service in my world.They don't exchange data in your world? Wow, where do you live anyhow? 8-)
It's the most common form of communication used in e-business today (think EDI).
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca