Fast Web Services is an initiative at Sun Microsystems aimed at the identification of performance problems in existing implementations of Web Services standards. Fast Web Services explores the use of more efficient binary encodings as an alternative to textual XML representations.
Sun does a performance comparison between their "Fast Web Services", using ASN.1 and X.695 encoding, and traditional XML SOAP encoding. X.694 is a specification that defines a mapping from XSD to ASN.1.
Read the complete article at:
http://developer.java.sun.com/developer/technicalArticles/WebServices/fastWS/index.html
Is it funny to see binary web services, or natural?
-
Sun writes about its "Fast Web Services" initiative (35 messages)
- Posted by: Mileta Cekovic
- Posted on: September 15 2003 07:13 EDT
Threaded Messages (35)
- Hasn't this been done already? by Greg Zoller on September 22 2003 09:55 EDT
- Hasn't this been done already? by Carlos Perez on September 22 2003 10:04 EDT
- Hasn't this been done already? by Greg Pavlik on September 22 2003 10:27 EDT
- Hasn't this been done already? by Greg Zoller on September 22 2003 11:50 EDT
- Hasn't this been done already? by Carlos Perez on September 22 2003 10:04 EDT
- Sun writes about its "Fast Web Services" initiative by Mike Perham on September 22 2003 10:16 EDT
- binary web services by Scott Ferguson on September 22 2003 10:21 EDT
- Sun writes about its "Fast Web Services" initiative by Parag Gandhe on September 22 2003 10:55 EDT
- Sun writes about its "Fast Web Services" initiative by George de la Torre on September 22 2003 10:55 EDT
- WBXML, SyncML by Sean Sullivan on September 22 2003 11:03 EDT
- WBXML specification by Sean Sullivan on September 22 2003 12:15 EDT
- W3C Workshop on Binary Interchange of XML Information Item Sets by Sean Sullivan on September 22 2003 12:19 EDT
- That's incredible by Slava Imeshev on September 22 2003 13:41 EDT
- Wisdom says: "All new things are very well forgotten old things" by Michael Poulin on September 22 2003 16:52 EDT
- Wisdom says: "All new things are very well forgotten old things" by Carlos Perez on September 22 2003 05:33 EDT
- Wisdom says: "All new things are very well forgotten old things" by Slava Imeshev on September 23 2003 11:55 EDT
- Wisdom says: "All new things are very well forgotten old things" by Michael Poulin on September 22 2003 16:52 EDT
- How about zipped streams? by Cedric Beust on September 22 2003 14:32 EDT
- How about zipped streams? by Mike Perham on September 22 2003 14:42 EDT
- How about zipped streams? by Greg Pavlik on September 22 2003 16:39 EDT
- How about zipped streams? by Brian Miller on September 22 2003 05:27 EDT
- How about zipped streams? by John Davies on September 22 2003 17:30 EDT
- How about zipped streams? by Brian Miller on September 23 2003 12:01 EDT
- How about zipped streams? by Cameron Purdy on September 22 2003 22:08 EDT
-
Wait, there's more by Cedric Beust on September 23 2003 03:06 EDT
- Wait, there's more by John Davies on September 23 2003 05:28 EDT
-
How about zipped streams? by Juan Losada on September 23 2003 07:45 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 08:02 EDT
-
How about zipped streams? by Cedric Beust on September 23 2003 10:48 EDT
- How about zipped streams? by Slava Imeshev on September 23 2003 12:02 EDT
-
How about zipped streams? by Cedric Beust on September 23 2003 10:48 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 08:02 EDT
-
How about zipped streams? by Slava Imeshev on September 23 2003 11:58 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 12:25 EDT
-
How about zipped streams? by Slava Imeshev on September 23 2003 01:53 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 03:22 EDT
- How about zipped streams? by Slava Imeshev on September 23 2003 04:14 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 03:22 EDT
-
How about zipped streams? by Slava Imeshev on September 23 2003 01:53 EDT
-
How about zipped streams? by Cameron Purdy on September 23 2003 12:25 EDT
-
Wait, there's more by Cedric Beust on September 23 2003 03:06 EDT
- Infoworld article by Sean Sullivan on September 22 2003 20:20 EDT
- XML Binary Infoset by Sean Sullivan on November 25 2003 14:33 EST
-
Hasn't this been done already?[ Go to top ]
- Posted by: Greg Zoller
- Posted on: September 22 2003 09:55 EDT
- in response to Mileta Cekovic
Isn't this basically the same approach TME's GLUE product has been
using for quite some time? -
Hasn't this been done already?[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 22 2003 10:04 EDT
- in response to Greg Zoller
What do you mean? I don't recall GLUE supporting alternative wire formats. -
Hasn't this been done already?[ Go to top ]
- Posted by: Greg Pavlik
- Posted on: September 22 2003 10:27 EDT
- in response to Carlos Perez
I always wondered if this would gain traction. In the early or mid 90's, I was working with telco infrastructure for near real time interchange of call detail information to support wireless fraud detection applications and eventually (the holy grail) billing and settlement. Of course everything there was ASN.1 encoded. A few years later, I remember going to work at Bluestone Software, where everything was Java and XML (almost). So when I really started looking hard at XML, I kept asking myself about transport efficiencies and why this couldn't be optimized a la ASN.1. I think the only person that this really resonated with when I was talking about it then was Peter Furness, then at Arjuna (soon to also be Bluestone), who has been involved for years with maintenance of OSI TP. I'm very interested to see what comes of this. -
Hasn't this been done already?[ Go to top ]
- Posted by: Greg Zoller
- Posted on: September 22 2003 11:50 EDT
- in response to Carlos Perez
I could be wrong, but my understanding is that GLUE will optimize its communications and send binary serialized objects if it detects a compatible recpient on the other end (basically another instance of GLUE). If my understanding is correct then isn't this basically the same idea as Sun's "new" approach? GLUE's been at this for a few years now. -
Sun writes about its "Fast Web Services" initiative[ Go to top ]
- Posted by: Mike Perham
- Posted on: September 22 2003 10:16 EDT
- in response to Mileta Cekovic
Web Services are best used as a coarse grained interoperable face on a business service where speed is secondary. This project is a band-aid in that it is designed to help systems which probably shouldn't have been architected to use web services in the first place. -
binary web services[ Go to top ]
- Posted by: Scott Ferguson
- Posted on: September 22 2003 10:21 EDT
- in response to Mileta Cekovic
I still don't understand why the protocols need to be so complicated.
Sun's protocol seems more complicated than the Hessian binary web service protocol.
On the other hand, any move to a binary protocol makes sense. Really, other than jumping on XML/XSchema hype, there's not much value of having the wire protocol be in XML. The only important thing is to make it easy for all systems to implement it. -
Sun writes about its "Fast Web Services" initiative[ Go to top ]
- Posted by: Parag Gandhe
- Posted on: September 22 2003 10:55 EDT
- in response to Mileta Cekovic
There is no doubt that XML on wire is not the best way for communication, especially mobile communication and small capacity devices. Descriptive nature of XML makes it very large and it is just a waste of bandwidth. But this descriptive nature is for humans only. For an application <Application>J2EE App</Application> is not much different than <Ap>J2EE App</Ap>. Thus we can cut down on the cost of descriptive nature of XML.
WS is for course grain application to application processing. Real question is "Do we need to send XML that will be consumed by an application on a MOBILE/VERY SMALL CAPACITY Device? IMHO, they can be just a clients that display the result of server processing. -
Sun writes about its "Fast Web Services" initiative[ Go to top ]
- Posted by: George de la Torre
- Posted on: September 22 2003 10:55 EDT
- in response to Mileta Cekovic
Great, its about time ASN.1 is mentioned for business applications. While, everybody was talking about how great XML Schema is going to be, ASN.1 has "been there done that" almost 20 years already.
ASN.1 is used for molecular biology databases as well http://www.ncbi.nlm.nih.gov/, therefore, business applications will get boost from using this great technology.
In fact, the perfomance issue was also solved because of the binary encoding/decoding standards of ASN.1, thus, imagine a xml packet sent in binary form, then gets processed with SAX, DOM, etc...
The bellow quote from, http://list.etsi.org/scripts/wa.exe?A2=ind0205&L=3gpp_tsg_sa_wg5_swgb&D=0&T=0&P=3839, email discusion explains further,
"Perhaps the greatest benefit to using a single schema language for both
XML and binary messages is the ability to select the form of encoding
according to the specific needs or the specific constraints, even temporary, of
the communication link. Any node in the network would be able to send or
receive XML or binary messages: binary messages would be used over slow
or congested links, XML would be used over fast links or also for storage,
query, display, monitoring, and so on. No schema language other than
ASN.1 has such a capability today." -
WBXML, SyncML[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: September 22 2003 11:03 EDT
- in response to Mileta Cekovic
SyncML has an optional binary encoding that is known as WBXML
WBXML is "WAP Binary XML" -
WBXML specification[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: September 22 2003 12:15 EDT
- in response to Sean Sullivan
-
W3C Workshop on Binary Interchange of XML Information Item Sets[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: September 22 2003 12:19 EDT
- in response to Mileta Cekovic
The W3C Workshop on Binary Interchange of XML Information Item Sets
Call for Participation
24th, 25th and 26th September, 2003
Santa Clara, California, USA
https://www.w3.org/2003/07/binary-xml-cfp.html -
That's incredible[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 22 2003 13:41 EDT
- in response to Mileta Cekovic
LOL. It's been in CORBA since 1992.
The question is - when are we going to use technologies that work instead of DODs having magic "X" letter in their name?
Slava
P.S.
I've just seen a colleague trying to deal with 80MB SOAP request (700MB parsed) and 150Kbyte data in it. Sad. -
Wisdom says: "All new things are very well forgotten old things"[ Go to top ]
- Posted by: Michael Poulin
- Posted on: September 22 2003 16:52 EDT
- in response to Slava Imeshev
Slava, CORBA also did Object Trading Service since 1997 ( check Novell's archives ), which was later rewritten as WSDL/UUDI, with errors. What do you expect ?
The power of XML was in readability, this compensated overhead and slow-go. When parsing and definition technologies mature ( like XML Schema ) , may be it is not needed to read the data and we can delegate this function to an engine?..
- Michael P. -
Wisdom says: "All new things are very well forgotten old things"[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 22 2003 17:33 EDT
- in response to Michael Poulin
Good thought, strong schema based parser diminshes the need for human readable formats.
We've had ASN.1 generators for years now, let's now make them compatible with an even more byzantine XML schema language and let's all declare victory! -
Wisdom says: "All new things are very well forgotten old things"[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 23 2003 11:55 EDT
- in response to Michael Poulin
The power of XML was in readability, this compensated overhead and slow-go.
Look, the only useful case of readability comes to my mind is ANT scripts. The rest is write-only textual data with mark-up.
> When parsing and definition technologies mature ( like XML Schema ) , may be it is not needed to read the data and we can delegate this function to an engine?..
That what drives me crasy - why do you need something dead-inefficient that you will work on for years just trying toget it just closer to it preceedor? For
no-need-to-read there is a bunch of old efficient wire and higher -level protocols. XML whatever it happens to it will nvere come close to it.
I can tell you more, though it may sound rebelish - XML and Web Services are the last children of the internet buble time when all you needed to get hell reach is to tell your VCs something they don't understand and than you are done. And they gave money and the money gave birth to those scary creatures that we now are trying to live with.
Though, there is a huge advantage in those things - they provide us job security, because they help to roll the whole industry, because things, that before were taking hours now take weeks.
I apreciate it. And there are a lot of challenges in XML and WAS to overcome ahead. And it's fun. But as an engineer, XML and its blood-sucking children make me sick. -
How about zipped streams?[ Go to top ]
- Posted by: Cedric Beust
- Posted on: September 22 2003 14:32 EDT
- in response to Mileta Cekovic
I wonder how Sun's initiative compare with exchanging zipped XML files, which I see as a much simpler and just as efficient solution.
--
Cedric -
How about zipped streams?[ Go to top ]
- Posted by: Mike Perham
- Posted on: September 22 2003 14:42 EDT
- in response to Cedric Beust
<sarcasm> How are 3 Sun engineers supposed to create a 100 page standard and earn a years worth of paychecks out of that solution? </sarcasm>
> I wonder how Sun's initiative compare with exchanging zipped XML files, which I see as a much simpler and just as efficient solution. -
How about zipped streams?[ Go to top ]
- Posted by: Greg Pavlik
- Posted on: September 22 2003 16:39 EDT
- in response to Cedric Beust
That's a very interesting question. With zip, the "compression" aspects and the datatyping are decoupled, which I suppose could have efficieny implications. Btw, Cedric, your question makes me think of Eric Newcomer's proposal to just use files and FTP to send XML documents around reliably. Neither are bad ideas.
Greg -
How about zipped streams?[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 22 2003 17:27 EDT
- in response to Greg Pavlik
Btw, Cedric, your question makes me think of Eric Newcomer's proposal to just use files and FTP to send XML documents around reliably. Neither are bad ideas.
I think HTTP is more flexible than FTP. Take for example Globus GASS, a very primitive replica manager. It uses HTTPS to shuffling files around, presumably for security and maybe because HTTP can stream stdin/out/err as if it were a file more readily than FTP can.
Anyway, zipping is a sure winner. -
How about zipped streams?[ Go to top ]
- Posted by: John Davies
- Posted on: September 22 2003 17:30 EDT
- in response to Cedric Beust
In terms of message size a zipped XML stream works very well making it a good option for slow networks but the biggest problem with XML, in any format, is the time it takes to martial, unmatial and validate so zipped streams doesn't help too much here.
-John- -
How about zipped streams?[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 23 2003 12:01 EDT
- in response to John Davies
In terms of message size a zipped XML stream works very well making it a good option for slow networks but the biggest problem with XML, in any format, is the time it takes to martial, unmatial and validate so zipped streams doesn't help too much here.
Could it really be that marshalling time dominates transmission time for XML messaging? That just doesn't sound right to me. -
How about zipped streams?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: September 22 2003 22:08 EDT
- in response to Cedric Beust
Cedric: I wonder how Sun's initiative compare with exchanging zipped XML files, which I see as a much simpler and just as efficient solution.
You're crazy. Seriously, you're crazy.
First you take programmatic structures that total about 23 bytes that you can access and manipulate with a couple hundred CPU cycles. Then you expand it into XML that takes approximately 4.8MB in memory using about 17 billion CPU cycles and stream it out into a 1.3MB buffer using another 3 billion CPU cycles. Then you compress it using ZIP (etc.) down to a 200KB document using another 8 billion CPU cycles. Then you pass it across the network, and reverse this extremely expensive process on the other end.
You're crazy. Seriously, you're crazy.
I'll let you know when someone comes up with a better idea. But it won't be this one.
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster! -
Wait, there's more[ Go to top ]
- Posted by: Cedric Beust
- Posted on: September 23 2003 03:06 EDT
- in response to Cameron Purdy
Tangoguy:
I'll let you know when someone comes up with a better idea. But it won't be this one.
Wait until you hear my next idea: once you have compressed the stream with zip, you compress it a second time to shrink it some more.
And again and again, until it reaches one byte.
Then you call the recipient on the phone to tell them the hex value.
--
Ced -
Wait, there's more[ Go to top ]
- Posted by: John Davies
- Posted on: September 23 2003 05:28 EDT
- in response to Cedric Beust
Brilliant Cedric, just brilliant!!!
But why stop at the byte, let's just use the rest of the day and compress it down to a bit. You can then save money but agreeing not to call if it's "0" and only ring once if it's a "1". The guy on the other end can then set off the decrypt process to re-generate the original message, probably using some sort of random number generator. Eventaully they'll come up with the original message.
To hell with XML, compression rules. :-)
-John- -
How about zipped streams?[ Go to top ]
- Posted by: Juan Losada
- Posted on: September 23 2003 07:45 EDT
- in response to Cameron Purdy
Excuse me, but this seems in the same line that other threads. Threads were people just try to show how brilliant are talking, or who says something ironic rather than discuss the ideas. Have you think for instance that bandwidth is more important than CPU cycles or memory use in certain areas? -
How about zipped streams?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: September 23 2003 08:02 EDT
- in response to Juan Losada
Juan: Excuse me, but this seems in the same line that other threads. Threads were people just try to show how brilliant are talking, or who says something ironic rather than discuss the ideas. Have you think for instance that bandwidth is more important than CPU cycles or memory use in certain areas?
Your criticisms are valid. What I was trying to point out (among other things) was that even zipped, the size is unacceptable, so even if memory and CPU were free (both time and money) you will still end up losing with this approach. In other words, my hypothesis is that if we start with DATA and we encode it into XML and compress it into ZIP, the resulting size of ZIP is still significantly larger than the size of DATA.
I believe that this the reason why Sun (and others) are considering binary encodings for XML and XML-like structures.
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster! -
How about zipped streams?[ Go to top ]
- Posted by: Cedric Beust
- Posted on: September 23 2003 10:48 EDT
- in response to Cameron Purdy
Cameron:
In other words, my hypothesis is that if we start with DATA and we encode it into XML and compress it into ZIP, the resulting size of ZIP is still significantly larger than the size of DATA.
Come on Cameron, you know that the goal is not to obtain the smallest possible data, but rather to reach a point where the time and CPU needed to restore the data is of no consequence because dwarfed by other considerations.
For example, imagine that you are retrieving a 100k XML document from a database. If this document can be zipped down to 10k, then the query to the database will take an order of magnitude more than the time to unzip it.
If you were to try and optimize this further, would you first try to
- find a better compression scheme or
- not hit the database at all
?
--
Cedric -
How about zipped streams?[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 23 2003 12:02 EDT
- in response to Cedric Beust
Cedric:
> For example, imagine that you are retrieving a 100k XML document from a database. If this document can be zipped down to 10k, then the query to the database will take an order of magnitude more than the time to unzip it.
>
> If you were to try and optimize this further, would you first try to
>
> - find a better compression scheme or
> - not hit the database at all
>
> ?
- IMO you forgot storing data in relational tables (I know, it sounds craizy).
Slava -
How about zipped streams?[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 23 2003 11:58 EDT
- in response to Cameron Purdy
Peace,
>
> Cameron Purdy
> Coherence: Easily share live data across a cluster!
Cameron, can you cache 800MB of DOM in 4 node cluster? -
How about zipped streams?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: September 23 2003 12:25 EDT
- in response to Slava Imeshev
Slava: Cameron, can you cache 800MB of DOM in 4 node cluster?
Sure! (Also, didn't you work on some of the JavaGroups caching stuff?)
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing! -
How about zipped streams?[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 23 2003 13:53 EDT
- in response to Cameron Purdy
Cameron:
> Slava: Cameron, can you cache 800MB of DOM in 4 node cluster?
>
> Sure! (Also, didn't you work on some of the JavaGroups caching stuff?)
No, that wasn't me. I have a well-known accomplishment in other area of caching, authorship of which I don't advertise much.
BTW, how do coop with open-source implementations of a distributed cache? That should be eating out a big chunk of your potential accounts. -
How about zipped streams?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: September 23 2003 15:22 EDT
- in response to Slava Imeshev
Slava: BTW, how do coop with open-source implementations of a distributed cache? That should be eating out a big chunk of your potential accounts.
Sure, of course it does. If you didn't have open source options, you'd have to buy everything or write it all yourself! On the other hand, if it weren't for open source, most of the last 8 years of software advances would not have happened, so I think it's been a huge net positive in our industry.
When we at Tangosol set out to build a software product, we knew we had to choose an area of the software industry in which companies would pay money for our software. (Not a bad business idea!) We sell primarily into the enterprise software market, which is rather particular about the software that they run. Further, we focused on data management and clustering, two things that traditionally have been very hard to mix effectively, and for which companies pay lots of money for working solutions. We focused on 100% uptime and linear scalability, and seeded the market very broadly with free downloads and free developer licenses (which were, are and always will be free.) We publish our prices, communicate well with and take excellent care of our customers, and have a couple hundred direct customers (and many more than that through OEMs) using the software, so its become a very trusted solution in almost every major industry and application type. Once you build up a trusted brand, your software becomes much (much!) easier to sell.
Open source software will always be getting better (see the OS Cache 2.0 thread for an example), and will do more and more of the base functionality that our software does (just like MySQL is constantly doing more and more of what Oracle does). Instead of feeling threatened by it in a bad way, we see it as a challenge that helps us keep focusing on that "next 9" in the reliability ratings, on the next incremental "%" in scalable performance, on the ability to scale up to thousands of nodes in a computational grid, on the next killer feature, or the next killer clustered service. In the high end, though, we never compete against open source -- it isn't even considered for those projects -- but there are a half dozen other companies just waiting for us to relax so that they can grab a chunk of our market, so we never slow down! And sometimes, it's our own partners (and even personal friends) competing against us, but business is business, and only the paranoid survive ;-)
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing! -
How about zipped streams?[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 23 2003 16:14 EDT
- in response to Cameron Purdy
Cameron:
> When we at Tangosol set out to build a software product, we knew we had to choose an area of the software industry in which companies would pay money for our software. We sell primarily into the enterprise software market, which is rather particular about the software that they run. Further, we focused on data management and clustering, two things that traditionally have been very hard to mix effectively, and for which companies pay lots of money for working solutions. We focused on 100% uptime and linear scalability, and seeded the market very broadly with free downloads and free developer licenses (which were, are and always will be free.) We publish our prices, communicate well with and take excellent care of our customers, and have a couple hundred direct customers (and many more than that through OEMs) using the software, so its become a very trusted solution in almost every major industry and application type. Once you build up a trusted brand, your software becomes much (much!) easier to sell.
That was god. I always enjoy giving you an opportunity to speak out. Can I use it as a pitch for my product? It's not copyrighted, is it? Can I store it in the issue tracker for future review? :)
Tip: right now there is a guy wondering in weblogic.developer.interest.ejb and caching everything in Hashtable in SLSB. Looks like your client :)
Regards,
Slava Imeshev -
Infoworld article[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: September 22 2003 20:20 EDT
- in response to Mileta Cekovic
http://www.infoworld.com/article/03/09/19/HNfastwebservices_1.html?web
{{
[...] Sun plans to have a prototype of Fast Web Services in its Java Web Services Developer Pack early in 2004. [...]
"We believe that developers are to a large degree lazy. They find a concept that they're comfortable with, they take that concept, and push it to the limit," said Pelegri-Llopart.
In Sun's view, the XML-based messaging that lies at the heart of current Web services technology carries with it a performance price. XML-based messages require more processing than protocols such as RMI (Remote Method Invocation), RMI/IIOP (RMI Over Internet Inter-ORB Protocol), or CORBA/IIOP; data is represented inefficiently and binding requires computation, according to Sun in a paper published in August.
"The main point here is there is almost an order of magnitude between straightforward Web services using XML encoding and an implementation that takes care of binary encoding," Pelegri-Llopart said.
}} -
XML Binary Infoset[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: November 25 2003 14:33 EST
- in response to Mileta Cekovic