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

[Anne Thomas Manes]

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

On 8/22/06, Naren Chawla <[EMAIL PROTECTED]> wrote:

I am wondering if I was using an intermediary (aka ESB) in my architecture, then do I need to worry about the client-side invocation frameworks like WSIF, etc.

 

One of the core feature for most ESB's is protocol switching.  An ESB acts like a proxy between a client and back-end business services and it provides configuration-based services to do the protocol-switching (apart from transformation, routing, security, etc.)

 

I guess, the value-prop of WSIF and other client-side invocation frameworks is to add a layer of abstractions and invoke underlying service in uniform way,

 

 

Let us assume you have back-end service that is using jms as protocol. Using an ESB you can configure two different proxy services using two different protocols say HTTP and SMTP on the inbound side talking to the same back-end service.    At the same time, ESB can/should support multiple message formats - SOAP, XML, Binary, Text, etc.  

 

So, my point is that with protocol-switching and support for multiple message formats in the ESB, we don't need  client-side invocations frameworks like WSIF which try to treat everything (EJB, POJO) a web service ( and pay the marhalling/unmarshalling penalty).

 

--Naren

 

 

 

 

Aleksander Slominski <[EMAIL PROTECTED] > wrote:

Keith Harrison-Broninski wrote:
> I am using XSUL for its dynamic invocation abilities - its architect
> Aleksander Slominski is on this list, I think.
>
SDI/XSUL is just souped up WSIF (which i called XWSIF) - in nutshell you
can invoke anything described in WSDL but with more flexibility than in
Apache WSIF in particular in area where data binding is done (or not if
you need work directly with XML).

best,

alek

--
The best way to predict the future is to invent it - Alan Kay

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

__._,_.___

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.

---

__,_._,___