Re: [service-orientated-architecture] Re: Messaging Standards-(Reliable and Durable)

Sun, 02 Apr 2006 13:30:34 -0700

I have to say I am somewhat surprised by this comment about WS-RM.  I believe that most of the WS-RM vendors posting to this list, including ourselves, have said that several implementations are indeed ready and interoperable.  But perhaps it is that WS-RM doesn't meet your requirements?  Is this the "persistence" issue?  If so, it may be a misunderstanding of the WS-RM specification since the "R" in RM implies persistence, but the interoperability protocol does not need to define it (i.e. persistence can be implementation specific as long as the interop protocol is preserved, and the purpose of the spec is to define interop, which is working).
 
Certainly one of the issues in the industry today is the variation in approach to Web services.  The answer your question about SOAP relative to IONA's approach is yes.  We support the decoupling of data format and communications transport in WSDL.  Some of our customers send SOAP messages over IIOP for example.  We also can change the WSDL bindings to send SOAP messages over various flavors of JMS, WebSphereMQ, Tuxedo, Tibco RV, and FTP (in addition to HTTP of course), without impacting the data format at all.  And of course you can use other data formats than SOAP.  We provide this using our microkernal, pluggable runtime both in our closed source product Artix and through contributions to the ObjectWeb open source project, Celtix.
 
Regarding the question of interoperability issues, this is something that today us vendors more or less have to work out for ourselves, since no independent authority defines and executes conformance testing.  (WS-I conformance is self-certifying.)  But many vendors (and here again it's best if I speak for IONA since I don't want to speak definitively for others) regularly perform interoperability testing with other vendors to try to catch and eliminate these kinds of problems as much as possible.  I do not remember how many other vendor products we test with regularly but it's 5-10 or so, and we always do our best to fix interoperability problems whenever we find out about them.
 
Regards,
 
Eric
CTO, IONA Technologies
 

----- Original Message ----
From: unmesh <[EMAIL PROTECTED]>
To: [email protected]
Sent: Sunday, April 2, 2006 12:56:16 PM
Subject: [service-orientated-architecture] Re: Messaging Standards-(Reliable and Durable)

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



Reply via email to