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

[Todd Biske]

As we all know, there's no right answer to this equation.  When Web Services were first being touted, one would have thought that there would be no need for anything "in the middle" in the future.  The truth is, there will always be a need for something in the middle.  I called it the Service/Event Delivery Network, and not all of the capabilities are associated with protocol or some other mediation.  The important thing is to focus on the capabilities, and make the decision that's best for your organization, whether it's WCF, ESB, SCA, XML Appliances, JINI, etc.  They will all work.   My opinion is that the most important thing to understand is what things should be "in the middle" and what things shouldn't.  My definition of "in the middle" is loosely described as out of the source code of the  consumer or provider.  In other words, externalized in the form of policy-driven logic that can be configured, rather than coded.  You might be configuring the underlying development framework, you might be configuring an ESB, an XML appliance, whatever.  If we really had a perfect world, the tools used to set those policies and configure the run-time environment would be independent of which product/technologies were chosen.   Speaking of policy-driven infrastructure, any thoughts on the BEA acquisition?  I always thought Systinet and Flashline were more competitors than collaborators, although I have zero experience with either product in the recent past, so perhaps the competition was more "in the future" than today.  After all, Systinet definitely grew more from the run-time world and Flashline grew from the development time side.   -tb On Aug 23, 2006, at 5:02 PM, Stefan Tilkov wrote: 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  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. __,_._,___