Speaking for IONA and Artix/Celtix, our view is that WSDL separates the logical service from its physical deployment (i.e. the binding to communication protocol and/or data formats), which means that the same logical service definition can be used with multiple protocols and formats.  Our microkernel runtime supports switching among supported protocols and formats via configuration.
 
Eric

----- Original Message ----
From: jeffrschneider <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, August 22, 2006 1:10:33 PM
Subject: [service-orientated-architecture] Re: Client Side Invocation Frameworks?

Agreed.

The CSIF abstracts the API. The intermediary abstracts the protocol.

The two should be used together.

I don't want to put words in Anne's mouth, but I believe her point
was:
1. Use both
2. If possible, use the CSIF to produce the target protocol
3. Use the intermediary to perform protocol mediation when it isn't
economically feasible to create the target protocol at the client
4. In addition, use the intermediary for functions other than
protocol mediation (policy enforcement, monitor, etc.)

Jeff

--- In service-orientated- architecture@ yahoogroups. com, "Anne Thomas
Manes" <[EMAIL PROTECTED] > wrote:
>
> Naren,
>
> 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.)
>
> Examples of uniform middleware invocation frameworks include
Microsoft WCF
> (aka "Indigo"), WSIF, and IONA Artix.
>
> I'm not a huge fan of WSIF, because the programming model is a
little too
> tightly aligned with RMI for my taste. But one of its greatest
strengths is
> its dynamic invocation capabilities. It's much more capable than
the JAX-RPC
> DII.
>
> Note that the original question was regarding any type of
invocation
> framework -- not just about uniform invocation frameworks. That
includes
> SOAP-only frameworks, like JAX-RPC, JAX-WS, Axis2, etc.
>
> What client-side invocation framework do you use when sending
requests to
> your ESB?
>
> Anne


__._,_.___


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


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to