last few weeks. A couple of points in-line.
On Wed, 2006-04-19 at 09:05, Harm Smit wrote:
> In this interoperability vs. portability connection, the following
> quotation from Roger Sessions (extracted from
> http://www.cips.ca/news/national/news.asp?aID=1698) may also be
> instructive:
>
> <quote>
>
> From my work on CORBA, at IBM, I learned the difference between
> standards that succeed and those that fail. I learned that standards
> that focus on portability fail while those that focus on
> interoperability often succeed. CORBA was a huge standards activity.
> It could be divided into two areas. The first was the hugely complex
> CORBA API, which focused on portability. This easily accounted for 95%
> of the CORBA activity. The second was IIOP, which was about
> interoperability. It accounted for at most 5% of the CORBA activity.
> Although the CORBA API received almost all of the early hype, it was
> ultimately the lowly IIOP that was the only part of CORBA that had any
> real success.
>
> </quote>
I think there's an important difference here between CORBA and (WS-* +
Platform X) and which was supposed to be the point of my article: WS-*
doesn't have to address both parts of the problem, but vendors do.
I limited my discussion to Java because that's what we're using at the
moment. However, I completely agree that interoperability and
portability are different things. I also agree that trying to achieve
portability across environments is massively complex and often results
in an LCD (least common denominator) solution.
However, in Java, we already have a number of "standardized" APIs to
support the Plug-in pattern. One of these is JMS, another is JCA and
JBI provides something else quite similar. What I'm *not* saying is
that I would expect a portable interface across languages for this sort
of thing for the very reasons you quote with CORBA. I've used CORBA
bindings in about 4 different languages, and it can be "easy" or really,
really messy.
What we have the potential to see in the Java world is that
implementations of the WS-* functionality leverage these existing
plug-in APIs and, as was mentioned, move the optional configuration to,
well, configuration rather than coding. In this way, if you decide to
integrate using Java with a reliable messaging transport, the benefits
of doing it with a JCA-based integration are huge. If you have a
trading partner that doesn't like to use WS-Reliability, that's cool,
just plug-in the WS-RM or ebMS implementation and go. Reconfigure,
(maybe redeploy), but you certainly shouldn't have to recompile (this is
my one big gripe about the JCA/RM4GS API, btw).
If you can do this, the benefits in operations, testing and maintenance
are huge. Do you really need another custom API to send a message from
point A to point B if you have the proper encapsulation of a channel and
message? I've written some stuff for us that has such an encapsulation
that can use memory queues, JMS and RRMTP without changing the service
at all. In this way, it's like JBI, but it is arguably a bit more
flexible.
Being able to have this flexibility of configuration vs. compilation is
a key factor in the reduction of software costs over the long term.
Once it's coded and working, you don't ever want to touch it again
unless you need a new feature. In my mind, the how it sends a message
is not a feature. The feature is "sending a message", so that's where
the abstraction should be. Leverage the standardized Java platform's
plug-in interfaces to achieve that as much as possible and you'll limit
the overall lifecycle costs of your solution. Why re-invent the plug-in
API wheel, or worse, ignore it completely?
ast
>
>
> Worth reading from the same source: "What is a SOA?"
> (http://www.objectwatch.com/newsletters/issue_45.htm)
>
> Harm Smit.
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Anne Thomas Manes
> Sent: mardi 18 avril 2006 14:05
> To: [email protected]
> Subject: Re: [service-orientated-architecture] WS-Portability
> or WS-Proprietary?
>
>
> Portability and interoperability are different issues.
>
> The WS framework is *not* designed to enable portability. When
> you implement a service using a particular SOAP toolkit, that
> service implementation is bound to that toolkit, and it can
> run only in containers supported by that toolkit.
>
> The Java community, which always strives to support
> portability, has defined WS APIs (JAX-RPC and JAX-WS), which
> are supposed to enable portability across Java-based SOAP
> toolkits, although as Andrew points out, portability is not so
> easy. The APIs are the same across different toolkits, but the
> configuration and administration tools are not -- hence
> JAX-RPC/JAX-WS are about as portable as EJBs. But I repeat:
> portability is not a goal of the WS framework.
>
> The WS framework *is* designed to enable interoperability.
> Services built using any WS-compliant toolkit can
> interoperate, regardless of the toolkit, language, container,
> or OS they are implemented with.
>
> Based on my interviews with Fortune 500 companies, portability
> isn't especially important, but interoperability is.
>
> btw -- I am not a WS-only proponent. Application requirements
> should always dictate technology choices. As a rule, I always
> recommend standard protocols over
> platform/product/language-specific protocols unless there is a
> compelling reason to use the proprietary protocol. (Hence my
> reservations about J/JS and MOM-based ESBs.) I also recommend
> simpler solutions over more complex solutions as long as they
> meet the requirements ( e.g., POX wins over WS in situations
> where security, reliability, etc, aren't required).
>
> Anne
>
> On 4/18/06, patrickdlogan <[EMAIL PROTECTED]> wrote:
> > So, am I as a coder expected to do all this work
> myself or can I
> > have a tool to do it? I'd prefer an automated
> approach as per
> > Sanjiva because I wouldn't want this sort of cruft
> leaking into my
> > codebase.
>
> Andrew Townley has made the point in this forum
> previously that there
> are portability issue with SOAP toolkits. Here is his
> blog entry that
> explains the issue in full detail...
>
> http://atownley.org/2005/11/in-search-of-portable-interoperability/
>
> Anyone who believes they will walk the line with SOAP
> and remain
> somehow "vendor independent" or even language
> independent, is only
> consider one factor in the equation.
>
> Theses SOA things are very big costs and the
> differences between an
> investment in Jini/Javaspaces or some other ESB-like
> thing are not as
> clear-cut as I think the WS-Only proponents are making
> it out to be.
>
> Developing in a SOAP system is as binding to a
> language and an API as
> is developing in Jini/Javaspaces. Only seems *more*
> proprietary.
>
> -Patrick
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Computer software
> Computer aided
> design software
> Computer job
> Soa
> Service-oriented
> architecture
>
> ______________________________________________________________
> YAHOO! GROUPS LINKS
> 1. Visit your group "service-orientated-architecture" on
> the web.
>
> 2. To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
> 3. Your use of Yahoo! Groups is subject to the Yahoo!
> Terms of Service.
>
>
> ______________________________________________________________
--
Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
InfoSeCon 2006. For more information, see www.infosecon.org.
***************************************************************************************************
The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
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.
