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?

Isn't this basically the same approach TME's GLUE product has been
using for quite some time?

What do you mean? I don't recall GLUE supporting alternative wire formats.

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.

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.

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.

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.

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.

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."

SyncML has an optional binary encoding that is known as WBXML

WBXML is "WAP Binary XML"

WAP Binary XML (WBXML) specification

https://www.w3.org/1999/06/NOTE-wbxml-19990624/

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

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.

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.

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!

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.

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

<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.

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

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.

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-

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.

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!

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

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-

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?

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!

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

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

>
> Cameron Purdy
> Coherence: Easily share live data across a cluster!

Cameron, can you cache 800MB of DOM in 4 node cluster?

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!

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.

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!

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

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.

}}

Binary Infoset Workshop Report

http://www.xml.com/pub/a/2003/11/19/deviant.html