On 8/22/06, jeffrschneider <[EMAIL PROTECTED]> wrote:
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 [email protected], "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
- 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.
__,_._,___
- Re: [service-orientated-architecture] Re: Client Side In... Anne Thomas Manes
- [service-orientated-architecture] Re: Client Side I... Howard Kapustein
- Re: [service-orientated-architecture] Re: Clien... Stefan Tilkov
- Re: [service-orientated-architecture] Re: C... Gregg Wonderly
- Re: [service-orientated-architecture] R... Mark Baker
- [service-orientated-architecture] ... jeffrschneider
- Re: [service-orientated-archit... Hitoshi Ozawa
- Re: [service-orientated-archit... Gregg Wonderly
- Re: [service-orientated-architectu... Gregg Wonderly
- Re: [service-orientated-archit... Stefan Tilkov
- Re: [service-orientated-ar... Eric Newcomer
Reply via email to
