Comments for The ServerSide Interoperability Blog http://tssblog.techtarget.com The ultimate source for all about interop. Fri, 10 Feb 2012 02:28:15 +0000 http://wordpress.org/?v=2.0.1 Comment on A look at out-of-proc or RPC interop by Chuck http://tssblog.techtarget.com/index.php/distributed-objects/a-look-at-out-of-proc-or-rpc-interop/#comment-23836 Mon, 20 Aug 2007 23:33:17 +0000 http://tssblog.techtarget.com/index.php/distributed-objects/a-look-at-out-of-proc-or-rpc-interop/#comment-23836 This is so cool! A standard platform for writing code. Microsoft had it right when they started to emphasize integration and interoperability. That is what is really important. This is what has made the VM concept so useful in the last few years. If Sun and friends, and Microsoft would get out of their self-serving marketing wars (boht Microsoft and the anti-Microsofties), we might get what the computing community really wants and needs. A standard platform for writing code. Bytecode level (hardware and VM) interoperability is what really needs to happen. Let the compilers, linkers, loaders, and interpreters figure out how to make everything work together. As an applications developer, I just want to be able to write my code and stop having to bother with the limitations of incompatible infrastructures. I want the libraries from C, COM, .Net, UNIX, Windows, and Java. In short, I want it all, I do not want to make any compromises, and I don't care which camp wrote it. If the library is useful, I want to make use of it. This is a step closer. This is so cool! A standard platform for writing code.

Microsoft had it right when they started to emphasize integration and interoperability. That is what is really important. This is what has made the VM concept so useful in the last few years.

If Sun and friends, and Microsoft would get out of their self-serving marketing wars (boht Microsoft and the anti-Microsofties), we might get what the computing community really wants and needs.

A standard platform for writing code.

Bytecode level (hardware and VM) interoperability is what really needs to happen. Let the compilers, linkers, loaders, and interpreters figure out how to make everything work together.

As an applications developer, I just want to be able to write my code and stop having to bother with the limitations of incompatible infrastructures.

I want the libraries from C, COM, .Net, UNIX, Windows, and Java. In short, I want it all, I do not want to make any compromises, and I don’t care which camp wrote it. If the library is useful, I want to make use of it.

This is a step closer.

]]> Comment on Mini-Guide: REST (Representational State Transfer) by Jerome Louvel http://tssblog.techtarget.com/index.php/interoperability/mini-guide-rest-representational-state-transfer/#comment-23419 Thu, 16 Aug 2007 18:47:42 +0000 http://tssblog.techtarget.com/index.php/interoperability/mini-guide-rest-representational-state-transfer/#comment-23419 Thanks Brent for collecting and organizing those resources. I'd like to suggest a couple more: On REST blog - Tracking news on the REST architecture style http://news.onrest.org/ Search engine dedicated to REST (powered by Google) http://search.restlet.org/ Restlet - Lightweight REST framework for Java http://www.restlet.org Regards, Jerome Thanks Brent for collecting and organizing those resources. I’d like to suggest a couple more:

On REST blog - Tracking news on the REST architecture style
http://news.onrest.org/

Search engine dedicated to REST (powered by Google)
http://search.restlet.org/

Restlet - Lightweight REST framework for Java
http://www.restlet.org

Regards,
Jerome

]]> Comment on Adobe adds .NET interoperability to Cold Fusion by Vince Bonfanti http://tssblog.techtarget.com/index.php/interoperability/adobe-adds-net-interoperability-to-cold-fusion/#comment-23114 Mon, 13 Aug 2007 19:35:28 +0000 http://tssblog.techtarget.com/index.php/interoperability/adobe-adds-net-interoperability-to-cold-fusion/#comment-23114 BlueDragon.NET, a ColdFusion-compatible application server implemented completely in .NET (using a combination of J# and C#) was introduced by New Atlanta more than two years ago, in March 2005. BlueDragon.NET provides true integration of CFML (ColdFusion Markup Language) with .NET and ASP.NET, not just "interoperability" via a Java-.NET bridge. MySpace.com was the lead customer for BlueDragon.NET (http://www.newatlanta.com/corporate/news/myspace_announce.jsp). For more info on BlueDragon: http://www.newatlanta.com/products/bluedragon/index.cfm BlueDragon.NET, a ColdFusion-compatible application server implemented completely in .NET (using a combination of J# and C#) was introduced by New Atlanta more than two years ago, in March 2005. BlueDragon.NET provides true integration of CFML (ColdFusion Markup Language) with .NET and ASP.NET, not just “interoperability” via a Java-.NET bridge.

MySpace.com was the lead customer for BlueDragon.NET (http://www.newatlanta.com/corporate/news/myspace_announce.jsp).

For more info on BlueDragon:

http://www.newatlanta.com/products/bluedragon/index.cfm

]]> Comment on SOAP and High Performance: An Oxymoron? by LC http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21893 Wed, 01 Aug 2007 17:07:57 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21893 You missed the point... Use-cases will drive the decision. If you have a business critical service requiring integration with a multitude of client platforms (from VB6 client apps to IBM MQSeries), the *safest* bet is a SOAP Service over HTTP. On the other-hand (the article example - financial services) where performance has a much higher priority - SOAP payload may not be a consideration. Simply put SOAP serves a need, however there are other solutions to other problems too. You missed the point…
Use-cases will drive the decision. If you have a business critical service requiring integration with a multitude of client platforms (from VB6 client apps to IBM MQSeries), the *safest* bet is a SOAP Service over HTTP. On the other-hand (the article example - financial services) where performance has a much higher priority - SOAP payload may not be a consideration. Simply put SOAP serves a need, however there are other solutions to other problems too.

]]> Comment on Run-time libraries with knowledge of Java and .NET by Roy Osherove http://tssblog.techtarget.com/index.php/interoperability/run-time-libraries-with-knowledge-of-java-and-net/#comment-21869 Wed, 01 Aug 2007 09:02:34 +0000 http://tssblog.techtarget.com/index.php/interoperability/run-time-libraries-with-knowledge-of-java-and-net/#comment-21869 I've written my thoughts on codemesh vs. mainsoft grasshopper at our mainsoft blog: http://blog.mainsoft.com/blog/codemesh-does-interop-with-net-and-java-too-how-do-we-compare/ Your thoughts are welcome! Roy. I’ve written my thoughts on codemesh vs. mainsoft grasshopper at our mainsoft blog:
http://blog.mainsoft.com/blog/codemesh-does-interop-with-net-and-java-too-how-do-we-compare/

Your thoughts are welcome!

Roy.

]]> Comment on SOAP and High Performance: An Oxymoron? by Dave http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21840 Wed, 01 Aug 2007 01:25:35 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21840 Okay maybe 3k is a slight overstatement. But 1/2 - 1k would be correct! That's still way too much overhead. The corrected title of this posting should read: "SOAP and high-performance: a moron". -- Dave Okay maybe 3k is a slight overstatement. But 1/2 - 1k would be correct! That’s still way too much overhead.

The corrected title of this posting should read: “SOAP and high-performance: a moron”.

– Dave

]]> Comment on SOAP and High Performance: An Oxymoron? by Dave http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21839 Wed, 01 Aug 2007 01:22:27 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21839 ICE? YAML? JSON? Take your pick! But anyone who thinks that 3k of deep-nested XML in a SOAP envelope t to send a basic 1-string snippet of information between 2 apps "does not have a performance issue" needs their head read! ICE? YAML? JSON?

Take your pick!

But anyone who thinks that 3k of deep-nested XML in a SOAP envelope t to send a basic 1-string snippet of information between 2 apps “does not have a performance issue” needs their head read!

]]> Comment on SOAP and High Performance: An Oxymoron? by LC http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21838 Wed, 01 Aug 2007 01:16:07 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21838 The word is interoperability. In the pragmatic world, across vendor frameworks, various standards and platforms, SOAP services the interoperability problem very well. Performance is a consideration, but when two systems can not communicate with each other, performance is not the first NFR to be considered. In summary I guess, sometime performance is a trade-off for interoperability The word is interoperability. In the pragmatic world, across vendor frameworks, various standards and platforms, SOAP services the interoperability problem very well. Performance is a consideration, but when two systems can not communicate with each other, performance is not the first NFR to be considered.

In summary I guess, sometime performance is a trade-off for interoperability

]]> Comment on SOAP and High Performance: An Oxymoron? by Jim Cakalic http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21825 Tue, 31 Jul 2007 19:08:01 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21825 Hmm ... sounds like a reinvention of JINI/JavaSpaces. Hmm … sounds like a reinvention of JINI/JavaSpaces.

]]> Comment on SOAP and High Performance: An Oxymoron? by Anonymous http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21813 Tue, 31 Jul 2007 18:31:01 +0000 http://tssblog.techtarget.com/index.php/xmlweb-services/soap-and-high-performance-an-oxymoron/#comment-21813 No, this view is not entirely correct... SOAP by itself has no performance issue, http://webservices.sys-con.com/read/250512.htm No, this view is not entirely correct…
SOAP by itself has no performance issue,

http://webservices.sys-con.com/read/250512.htm

]]>