Sanjiva Weerawarana wrote: > > > On Wed, Sep 2, 2009 at 1:15 AM, Gregg Wonderly <[email protected] > <mailto:[email protected]>> wrote: > > > */[HS] It seems to me that Gregg’s underlying assumption is that the > > whole world speaks Java. As you say, this is not how the world > works./* > > My question (not assumption) is why is it more expensive or less > attractive to > speak the Java serialization standard as opposed to XML? Both > require software > systems to be integrated and installed as part of your SOA. What > things make it > seem "cheaper" or "easier" to use XML. > > > Greg, even if your position was technically correct (at least I > personally don't think so) , the practicality of advocating that is as > naiive as Microsoft's earlier woo to Java developers: "Have you heard of > .Net?". (Now Microsoft has gotten past that silliness IMO and is > advocating simply running your Java on Windows.)
Well, maybe you don't remember, but microsoft introduced XML as the only standard that they would be able to support for all other systems in the world to communicate with their systems. That was "silliness" at first sight, but when everyone decided that they wanted to talk to microsoft software, guess what? this happened vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > XML is the ONLY standard for exchanging information that is supported by > everyone. > Until that changes, there's no point in wasting time IF the > objective of the endpoint is to be universally communicable. If you're > in some closed world you can do whatever you want - and there's no > shortage of alternatives there, including Java serialization. Microsoft made sure that Java wouldn't be the only "standard" on the block. Java works "everywhere" in the same way that XML works "everywhere". If you have the engine on the OS/platform, you can use it. Plain and simple. Yes, it is valuable, as I said in my previous post for technical data exchange between disparate systems. But, as soon as you want to have transactions, leasing and other distributed systems functionality, you need "messages" to carry around more than just the "data". This mixing of "the data" and "the transport/transaction" into a single document means that "the data" now has semantic meaning. This means that you need more software and more infrastructure to support that "standard" and my question still is, why would it be beneficial to "reinvent" all of the infrastructure when there are other systems that already do this and do it quite well? I keep pushing back on "everything XML is good" suggesting that this just complicates software development and adds costs when its not needed. <A side track> I can only guess that people just do things like "use XML everywhere" based on the "creeping knowledge syndrome" (CKS, there I just created a new acronym). This is the problem where people know they have a problem but don't know exactly why (or they wouldn't of got to the position they are in) and many don't seem to know "how" or "what" to do to solve the problem. They learn a little bit at a time, and keep changing what they do as they learn, instead of being "trained" for the job at hand and getting it "right" the first time (or at least close). The occasional post on this list and those that I see elsewhere point out that people want to know "which ESB or REST or XML product is the best for SOA." I can see the lack of knowledge of what "SOA" is supposed to mean in such questions. People think that SOA is a system, not a behavior change that allows one to build better systems. I think this falls out of the fact that everything talked about in computer science and "IT" is technologies and products, by and large. We have "the waterfall model" and "OO" and other design paradigms. We see products advertised as "SOA ready" which for many seems to smell like "XML ready" or "IIOP capable" or "...". When people come ask which technology is best for their SOA, we, as a community of SOA "experts" tell them to go read SOA books, take SOA classes and "do all the right stuff" to discover "how" and "what" to do to make SOA work for them. The problem is, that they have management above them that is ignorant too (because they got to this point either by making mistakes due to ignorance or not being able to afford the "right stuff"). All the choices and all the "ways" and "means" to accomplish "SOA" do not add value that is traceable to the bottom line. Technologies solve problems (you guys have been telling me repeatedly that XML solves the data interchange problem), SOA is a way to solve non-technical problems. The issue is, you have to know that's how you use SOA. And the same is true for technical problems. You have to know which tool is best, and usually only experience makes this become truely visible, and sometimes that experience is expensive to gain. </a side track> Gregg Wonderly > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ <http://www.opensource.lk/> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > <http://www.wso2.com/> > Member; Apache Software Foundation; http://www.apache.org/ > <http://www.apache.org/> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > <http://www.cse.mrt.ac.lk/> > > Blog: http://sanjiva.weerawarana.org/ <http://sanjiva.weerawarana.org/> > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
