Re: [service-orientated-architecture] Epperson on SOA & High Performance

[Eric Newcomer]

Yes, this does sound a lot like a whitepaper trying to make the case for a specific product.

 

Performance is very important, and we at IONA have been doing high performance SOA for a long time based on CORBA.

 

It is also true that telcos are sensitive to the performance issues in Web services, but as someone has already pointed out on this list it may be more due to the implementations of the specifications than anything inherent to XML. 

 

As a general statement, the issues of network latency tend to be somewhat exaggerated because this is not the typical bottleneck that database access is, or managing client sessions is.  That isn't to say we don't need to work on this (as an industry) but a lot is already being done, and the typical advancements in hardware and network speeds will also contribute quite a bit. 

 

I remember when the World Wide Web was called the World Wide Wait and lots of people said it would never catch on because it was too slow.  Same for relational databases.  A lot of these problems will be solved over time more or less naturally.

 

On the other hand it is important to point out, as this article hints at, that the Web services specications are all designed to be multi-protocol and multi-data format compatible.  Which means you can have the same logical interface with different physical bindings.  If SOAP over HTTP is too slow you can reconfigure the binding to use SOAP over IIOP for example and gain about 10x in speed.

 

With respect to transactions, the work at the WS-Transactions TC (which I co-chair) is addressing this by producing specifications that support interoperability across multiple types of transaction managers.  Advanced transaction models are also being proposed but at the moment I think we will also need some kind of asynchronous messaging wire format standard such as AMQP to help address more of the overall requirements here. 

 

What this article describes as a problem for the industry is something that my company's products support every day - high performance SOA is not something new or impossible.

 

Eric

 

 

----- Original Message ----
From: Anil John <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Saturday, October 28, 2006 12:16:57 PM
Subject: RE: [service-orientated-architecture] Epperson on SOA & High Performance

I read this article, then read it again in hopes of understanding just where the author is going with it. If I understand the salient points, it would be:

>Ask any developer with SOA experience: it's well known that popular
>Web Service protocols -- in particular the default implementation of Web Services
>as SOAP over http -- are not designed for high performance environments
<aniltj>
Is a developer the right person to ask this question? All too often they are so focused on platform specific implementations, they may very well not be aware of options of speeding up XML processing that lies outside the platform.
</aniltj>

>Unless and until we have high performance standards
>for Web Services, SOA will never become a standard architecture
>for demanding applications
<aniltj>
As a good friend of mine would say, “That is a theorem without a proof!”. There is also an equating of SOA == Web Services that is going on here. And given the SOA w/ Web Services implemenations that is going on in the Financial Sector right, I am not sure about the validity of the statement either.
</aniltj>

>SOA does not require a specific protocol between a client and service.
>Only the definition of interface is required.
<aniltj>
.. and unless the metadata that describes that interface and the associated contract are clearly articulated using standards based technologies and unless you are using pervasivively supported protocols for communication, you will run into serious interoperabiliyt issues as you go across platforms and toolkits.
</aniltj>

> telecom operators have collaborated to rework the older, heavyweight
>protocol for service delivery, called Parlay, into a new lightweight SOA
>protocol called Parlay-X. This standard is much easier for third-party
>service providers to understand and implement, but the current XML
> based version has a reputation of being too slow for anything but simple trials
<aniltj>
Not familiar with this particular “SOA Protocol”, so am going to punt on it.
</aniltj>

In general, I just found this article to be like the introduction to a product brochure that sets the stages of a “widget” that someone would like to sell me.

In a lot of ways, the line of thinking that seems to be proposed here seems very much like the thought that the Binary XML folks are into. i.e. The XML Infoset is too bloated to send on the wire, so let’s come up with an alternate Binary Encoding etc.. etc..

It is a technically elegant solution, but has the unfortunate tendency to ignore the fact that unless you are using a open/public standard that has pervasive implemenation by vendors (platform & appliance), you are completely ignoring the role that intermediaries play in a SOA runtime infrastructure.

Regards,

- Anil

__._,_.___

SPONSORED LINKS

Computer software	Computer security software	Computer software program
Computer fax software	Computer virus software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___