Re: [service-orientated-architecture] Client Side Invocation Frameworks?

Thu, 24 Aug 2006 08:51:17 -0700

In many cases HTTP, URI etc. do not meet customer requirements since their applications are currently built on protocols designed for use in LANs.  HTTP is designed for use in WANs, and on purpose omits key features of the protocols designed for LANs.  Perhaps the most significant is persistent sessions.  A lot of the work that people complain about in WS-* with respect to complexity derives from the need to basically reinvent these LAN based designs for HTTP. 
 
Distributed computing environments in current use in enterprise IT have better security, reliability, transactionality, and performance than HTTP.  The question is whether it's better to add all of these features and functions to HTTP, or create better bridges (or interworking) between HTTP and existing environments. 
 
Eric

----- Original Message ----
From: Stefan Tilkov <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, August 23, 2006 6:02:01 PM
Subject: Re: [service-orientated-architecture] Client Side Invocation Frameworks?

On Aug 23, 2006, at 6:51 PM, Anne Thomas Manes wrote:

> +1.
> But many times you don't have the luxury of homogeneous systems.
>
> Anne
>
Anne, you are right, of course, but I wonder if even then an ESB is
the right concept.

For example, in a company there may be CICS/COBOL, CORBA/C++, EJB,
and .NET services. In this example, I can either

(1) select an ESB that supports all of these
(2) for each technology, select some product that service-enables it

Stefan

> On 8/23/06, Stefan Tilkov < stefan.tilkov@ innoq.com> wrote:
>
> On Aug 22, 2006, at 1:42 PM, Anne Thomas Manes wrote:
>
> > Some might argue that a uniform programming interface to multiple
> > middlewares is a desirable thing. Why incur the extra cost of
> > protocol switching in an intermediary if you can simply package
> > your message in the correct protocol right from the start. The
> > client is going to do marshalling/ unmarshalling regardless, so
> > there's no extra burden on the client. (It isn't performing
> > protocol switching -- it simply calls the appropriate protocol plug-
> > in/channel to marshal the request. A well-crafted framework should
> > treat all protocols as equals.)
>
> I think it's also worth pointing out that this comes at a cost -
> creating a common abstraction above multiple protocols is costly,
> complicated, leaky, and might not work the way one wants to because
> although a framework might *consider* protocols equal, they simply
> *are* not.
>
> Instead of supporting multiple protocols and using a single framework
> to support them all, I much prefer to standardize on a protocol and
> support multiple frameworks. In other words: Standardize on plain
> HTTP or WS-I BP instead of some ESB or CSIF.
>
> Stefan
> --
> Stefan Tilkov, http://www.innoq. com/blog/ st/
>
>
>
>
>


__._,_.___


SPONSORED LINKS
Computer software program Computer software spy Computer job
Database software Discount computer software

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to