"Web services, like all other technical fads before it, do make sense in some situations. No doubt some remote services, such as credit card processing and tax calculation, will do quite well, but that's nowhere close to fulfilling the marketing hype around this concept", writes Object Technology Guru and Mastering EJB II co-author Scott Ambler, in a new article.
Read Web services are the doomed fad of 2001 : Performance is likely to be abysmal if complexity is required
Also, read WebServices.org owner Colin Adam's rebuttal
What do you think?
I agree 100% with Scott... he is absolutely right, and history proves his article.
Web Services will go the way of any hype (C/S, CORBA, n-tier apps, eCommerce, mCommerce, XML, ASP...): They all do/did not live up to the promises, but they definitely get their place in the IT world.
My current favourite is XML: While it can be good in many situations it is a pain in most (it is used in) which causes significant performance problems. Still, people are using it until they are proven it does not work.
Web Services are 1) Not the "brand new thing" they are sold as, but the logical consequence of what has been done 2) Do not make sense in many cases (Scott's article explains this very well).
Note that I didn't mention Java and EJB here, as I think they are not just "hype" but a real step forward (I guess probably the biggest step since OOP, maybe even more important)... and Java lived up to its promises (IMHO).
Client/server a fad? CORBA a fad? ActiveX a fad? Really?
I agree that Web Services is much(over) hyped these days. But this essay is really much ado about nothing.
One point he missed that is big is that a web service is really just one more stateless technology.
Scott lists some over-hyped technologies. How about listing some that met the expectations? Handhelds, Java and WWW, for example.
A couple of years ago one minister of the Swedish government declared the Web to be a passing fad. Some technologies make it, some don't. Place your bets!
My stockbroker has a personalized web site which updates the info automatically every couple of minutes. This is neat, but I'm itching to get to the raw data, so that I can customize even further. I want to blend in other important data of my liking into the same view.
Also, I want my handheld to run an app that shows me if my commuter train is late.
Another item on my wish-list is a personal finance application that shows my expenses *and* my up-to-date account balances, recent credit card transactions and pending bills.
In short, I want to mix data from various sources the way I like. Once I can do that I'm sure I will find new uses for that data. If nothing else I will not have to stare at banner adds while my data is loading.
Web services *is* an interresting candidate, provided that enough data will be available (and at reasonable cost). But the technology is interresting only if the implementation is desirable.
As for security, I choose to trust much of the information on the Web, and I will probably accept a data feed from a known source as well.
When the ligth goes green at the intersection, but cars still keep coming from left and right, I'd rather trust my common sense than the information of the traffic light. In the same manner I will probably sort out the obviously incorrect data. And sure, sometimes I will be a sucker. Today my morning paper didn't arrive, recently my VCR digested a tape and sometimes the data feed will let me down. What's the difference?
It is strange, but... the three things you mentioned IMHO didn't live up to the expectations but were used "by accident". I'm not so sure about handhelds, but with Java: Well, it was created for embedded devices, then as an internet language (remember applets? ;-) and ended up on the (high-end) server... it is slowly getting back to the desktops (I think it is very well cuited for client apps as well) but this will need some time.
Or lets talk about WWW. I guess no one imagined that _this_ would come out... intention was completely different.
Reason why I'm "hyping" Java/J2EE is because I can easily see what I get for using it... with web services, well I have my doubts. Even now, software companies do not like to buy external components because they fear they'll finally not meet their needs/vendor goes bankrupt/... what if I should rely on things that I do not even partially have under control?
I wonder... if I remember correctly Orfali & Harkley already had something like "Web Services" in mind, just the underlying protocol would have been IIOP and the "language" would have been OOP.
I must say I agree with Scott, after seeing too many bleeding edge technology projects not meeting what they promised (or rather what the customer believed them to deliver).
It was also interesting to read the rebuttal. I especially liked "What the customer wants is the best deal. A few seconds won't get in the way of that." as I fail to see how does using a the web service give the best deal as opposed to other approaches. Often the best deal for customer (assuming the customer means the organization that uses the service with its other applications rather than your web click&buy person) involves reasonable response time. I fail to see how for example a big trading house, which would subscribe to a web service providing quotes etc. would be willing to ingnore response time.
Also, the web services (hmm... weren't there a micro-fad with mobile web agents a couple of years ago? It was technical only, no business driven hype though) make a very bold assumption - that vendors will give up customer-locks (special features on their services). Yes, I would love to see such environment, but I doubt I will, given even the incompabilities (i.e. scheduling, bootstraping, blah blah blah) with the current J2EE environment and vendors there are (at least on the outside) trying to put it together!
And J2EE is _technical_ standard - with web services we're talking business standards.
Yes, I can see space where web services will have their use - wherever there are well defined business interoperation standards (strangely enough, financial services again come to mind - although performance as already noted could be major problem there - for example SWIFT, CHIPS etc.).
I agree. I get sick of companies jumping on the "bandwagon of buzzwords" and if you don't know XML they don't hire you regardless of how many years of development experience you have. THis "obsession with the bleeding edge" detracts from getting business done, and wastes alot of people's time and money.
J2EE is all a company needs to do anything these days; forget about all that other crap.
Well, I have to disagree with you and Scott. You say J2EE is all a company needs? Of course, you can do your stuff I J2EE. I am actually a J2EE programmer right now, but still. I had the curiosity to develop the same functionality (a login page with Oracle DB Backend) in both technologies and I have to say there is no comparison whatsoever. It took me 12 hours to build the page using Microsoft's IDE and a Web Service and 3.5 DAYS for the same thing with J2EE. Where can I add that I developed the WS in C# and it was my first brush with that language. See my point? J2EE stands no chance to this competition...
I think there are two different issues here: Internet, and Services. I don't think that the current Internet is reliable or accountable enough to do real business to business, real time transactions - I think that the idea of having a spelling checker as a remote web service is silly.
However, I can see that having standardised interfaces and methods makes sense in a number of situations. For example, parcel tracking. Currently, a number of carriers offer this service via their web sites. As a seller, I don't want to push people from my site to a carriers site to view the progress of a parcel. I'd like to be able to get at the information in a standarised way, and present it with my own branding - possibly linking up shipments sent with different carriers.
The technology isn't the problem here. Web services are funky cgi scripts that understand XML, instead of POSTed forms. The underlying idea is similar to IBM 3270 terminals - the terminal posts a set of data fields when the 'send' button is pressed, and the mainframe sends back another screen. The problem is standardising what the XML means - until all the carriers support the same set of objects and methods, the scenario I described above can't happen. EDI suffers the same problem.
The other issue is the network between the servers. With the current patchwork of ISPs, backbones, private peerings, public peerings, paid transit etc, getting a guarantee of bandwidth between sites is almost impossible. Until the Internet evolves into a network that can offer the same sort of guarantees as current telephone, or Frame/ATM networks, these sort of services will be on the sidelines.
Colin (not speaking for my employer)
Another new fad supporting web services are the "Verticle Service Providers" whose only real prayer is to offer some type of web service commodity like credit card validation, calculations, knowledge base lookup, etc. Little does anyone remember that behind that web service interface is an actual application server (purchased or homegrown) powering the site.
Web services have a neat niche where they belong as a BtoB interface to external parties and for EAI following standards like rosettanet, ebXML, and others, but this concept of using them for everything under the sun and calling them the "next web" doesn't have alot of merit from my perspective either. (That's me agreeing :-) )
Okay, no disrespect to the author and people who are supporting him, but I'm going to play devil's advocate...
the article only pointed out the obvious, was poorly written and not well thought out [which some may say also apply to my comments :-) ]
1. "They never did seem to fulfill their over-hyped promises and I suspect that Web services, this year's technical fad, won't either." Hmmm..over-hyped? Hype is hype, and by definition are exaggerated claims. Technical fad..fads, again by definition, die with time. I don't think any reasonably intelligent person thinks web service is a panacea. Rather, people get excited about new technology/standard/process because they think the new technology/standard/process will let them solve some, not all, exisitng problems better. As pointed out, some things will lend itself nicely to web services, others won't. People need new things to talk about and web services is it...doesn't mean it's the silver bullet...look at wireless..yea, lots of hype around it, but that's natural...nothing new here...
2. The first point, which I assume is the author's strongest point, is what if the vendor goes bust. This is not particular to web services - if your vendor goes belly up you're in trouble.
3. "Internal applications are probably not architected to be refactored into collections of Web services. If they are written that way then the attractiveness of the Web services approach is reduced." True, so don't refactor internal applications into web services. You're in a control environment, you don't need to expose your application as a service, so don't.
4. Arguments on performance, transaction and security are nothing new. In a distributed, heterogenous environment all of these are issues the architect/developer faces, whether the system is a web service or not. The same argument can be made against Enterprise JavaBeans or CORBA, for example. You have to be judicious when to use a particular technology. Of course this judiciousness is not always easy to come about.
5. Scott's last point is right on...especially about how I want to play with new toys.
It's also interesting to note that the same people who agree with Scott are hyping up other things..."J2EE is all a company needs to do anything these days; forget about all that other crap." Hmmm..weren't people doing "fine" without J2EE...isn't J2EE just another "fad," a bunch of marketing "hype" by BEA, Sun et al to sell their stuff?
Of course what Scott said is true, but let's not jump on "web services is doomed" bandwagon.
Sorry for some of the dupplication (didn't read the rebuttal until afterwards).
While I agree somewhat that web services could a current "fad", I believe the concept of doing business on the internet through code reuse is here to stay. Even in the future of increased bandwith, the idea of encapsulated code reuse will not go away. Web services are just the first attempt by the community to say so. Coding speed must increase with the complexity of the software. More and more, developers themselves are shaping the course of how new business software standards are formed and accepted, and I think developers love code reuse.
As an architect (sometime that's more like 'aspiring architect') for a large not-for-profit HMO, I see the potential for web services not so much in the marketplace but as a relatively easily understood (therefore lower barrier to mindshare) technique for transitioning a collection of legacy stovepipe applications into a (minimal) services-oriented architecture.
Add this to the potential for relatively small ISVs to implement at least a subset of web services to their products, thereby achieving the same benefits as EDI at a fraction of the cost, and you have a potent tool that shouldn't care what the platform is. Note that I say 'should', because many of the big players will try to create and exploit product differentiation given the lack of a de facto standard.
It would be sad if J2EE fans felt threatened by web services; all J2EE platfroms will support them if they don't already. There's certainly nothing sacred about using HTML/JSPs and/or a human UI in front of a Java-based application.
Your first paragraph shows the insight that the others, including Scott, seem to have missed. Web Services is about an integration platform, not a J2EE (Java based fine grained component) like competitor.
It won't replace J2EE, it will wrap J2EE components/applications just as it will wrap .Net components and legacy components also. It may give us a coarse component platform that allows applications built with .Net and the various vendor J2EE application servers to be unified from an architectural perspective. That is the point of web services. It's unfortunate that the word web is even present. People think internet straight away. Web means web of components rather than world wide web.
I expect most web services components to be very coarse components almost complete applications to them selves. Web Services platforms will take these components whether they are Cobol/3270 apps, WebLogic, WebSphere etc, and allow them to be put together in to a larger application.
It's a framework that will be used to connect up applications whether they are intranet or over the net. It's not about credit card transactions or marketplaces.
We should see .Net blocks, J2EE blocks and legacy blocks being assembled in to larger corporate applications using Web Services that possibly also link up with partners but I think the biggest market is likely to be intranet rather than extranet.
My two cents.
And still... wasn't this one promise of CORBA? Does this work now? No. And what is defined as "Web Services" today... well, it heavily relies on XML, SOAP etc., quite slow things (as many people experienced the hard way).
Sure, it _will_ happen, earlier or later, but I guess later than earlier. And it is really no technical thing but a business model, with the problems I mentioned (buy components? A joke for most companies).
Basically it's all distibuted technology, and everything has its place.
Client/Server played a very important part at a time when Windows clients needed to be built efficiently, and I still know of many applications around that use it. DCE gave us a nice RPC mechanism, that I remember using to code in a network efficient way. (Definitely Not a fad, in fact essential at the time)
I felt maybe CORBA was trying to be object oriented DCE, though everyone I know used it just like DCE, but it gave us a very good language independent interface.
EJB was the natural progression for Java. Since it was the easiest way to build distributed apps. (Not a Fad)
I've used something similar to Web services already, when we were having trouble deploying client side stubs and Weblogic client code. It allows dynamic discovery and invocation of services without having to deploy code on the client. (Again I think it will have its place)
In reply to "And still... wasn't this one promise of CORBA? Does this work now? No." That's right, CORBA didn't work
out well for what "web services" is now trying to do.
CORBA had several serious technical weaknesses; the new
technology fixes these.
First, CORBA originally didn't define any interoperability
protocol at all! They didn't get around to this until
CORBA 2, much later, and I'm still not clear how well
interoperability is really working for CORBA. Second,
it's synchronous. Third, it's oriented around
two-phase commits, which are not appropriate for most
business-to-business applications. Fourth, it has
nothing to say about multi-step conversations. Fifth,
it's rigid; once you've defined an IDL interface it's
hard to evolve it over time. Sixth, it normally operates
over its own protocol rather than being naturally built
on existing protocols at the level of abstraction of HTTP,
FTP, SMTP, etc.
The motivation behind CORBA was real and is still real.
In the case of business processes, the motivation is
still there, and a lot has been learned.
Well, of course, CORBA had technical weaknesses, but with V2 these were pretty easy to workaround, it would have been possible to use CORBA for the thing called "Web Services" now.
The main problem was (as I think): The companies didn't want to do this. Even now, they do not want to reuse components, although the risk is minimal. Buy a component for $1000, developing it would have cost tens of thousands of dollars, so you're really not risking much, if the vendor goes bust... well, you get the sources in most cases (e.g. ComponentSource Source Escrow Service), and even if not, well, you have the component as it is now... you could wrap it etc.
Still, no one relies on this (well, some, but not the majority of companies) although you could build some applications that are developed buy glueing together some cheap components.
As many pointed out, business needs drive the technology (well, I guess the business needs of IBM, BEA, Oracle etc. *gg*)... where is the business need here? Of yes, we want to collaborate B2B... but the risk seems to be too high for many CEOs, and I can easily understand.
We are far away (and will be in the next 1-2 years) that services are interchangeable. Although Sun is really trying to make J2EE apps portable they are still not fully. In most cases, yes, but not fully. Because the big vendors like to play their own game. Anyone really thinks Microsoft is propagating that you should use other vendor's software as well? Not seriously I guess, no vendor will ver do that.
So, if the service is gone, *your* service is gone (as someone pointed out)... you really do not want this to happen, so guess you better not risk it. And the risk is definitely high because you are relying on an environment which is _known_ to be unstable (the Internet) and you do not have it under control... you can secure your service as good as possible, if a DoS attack takes down a service you are relying on you're gone. You have no control over it.
Okay, still I believe that "web services" are something that will find its way into our IT world... there were many of them long before IBM, BEA, MS etc. talked about them, although not based on SOAP, XML etc. (or not necessarily). But not immediately, it needs a lot of time to mature. to gain trust from others... even more as early adopters will probably fail with using web services.
And what I technically dislike about ws is that we are using SOAP, XML etc. I think this goes into the wrong direction, there could be faster, more reliable etc. protocols to standardize on. I do not see any sense in wrapping remote requests in http to tunnel a firewall... because this is really _tunneling_, now http gets potentially as dangerous as every other protocol. I would have voted on specifying a _best suited_ remote protocol, would have made more sense, because many will use it in the future. But well, Cisco, Sun, IBM etc. need to sell their hardware.
My two cents: IMHO the problems with CORBA were/are:
*) difficulty in travering firewalls (dynamic port allocation); vendor-specific tunneling solutions.
*) lack of a global, interoperable naming service like DNS; how easy is it to make a CORBA naming service truly distributed and global in scope? What happens to the performance of the naming /location service when you get 1000s and 1000s of objects in it?
*) same applies to CORBA services like Notification Service for async events; can you really make them global in scope?
*) complex programming model
*) lack of a common interoperable security services; the web has SSL authentication/encryption based on certs (HTTPS).
CORBA seems best suited for tightly coupled project environments--not for providing interop between technology domains and businesses spread 'round the globe. On the other hand, in a tightly coupled project environment, it can offer significant value (as can J2EE--J2EE significantly more so ;-).
The ebXML/JAXM/SOAP stack offers a lot of promise for global interop. It rides over HTTP(S) supported by DNS. It specifies a common message packaging format (SOAP), the ability to define messaging semantics (JAXM message profiles), both sync and async, built on top of the SOAP exchanges. Finally, ebXML is well aligned with the JAXM/SOAP stack and provides a specific message profile and other concepts to facilitate complex B2B interop. The jury is still out on ebXML in my opinion.
Other related and encouraging developments in the Java world supporting this stack are JAXB (XML to Java Class binding) and JAXR (registry API--for UDDI or ebXML, e.g.) specs.
The notion of yellow page lookups at runtime (e.g., UDDI) has never appealed to me. How could you base a production service on a random component that will be provided by: 'who knows' with 'what really' quality of service? WSDL may provide a nice way to describe services in an IDL like language, but I suspect it will mainly be used at design time, or possibly by client apps (e.g., browsers) who are dynamically attempting to connect to a specific company interfaces (website). These would likely only be mass-market interfaces.
WSDL doesn't support the notion of B2B conversations (or PIPs) which are kicked off by 'anchor documents', so it's really a pretty simple/primitive way of describing an interface. More complex B2B will probably require much more complex company to company interactions and agreements, perhaps along the lines of ebXML or perhaps completely custom. Only time will tell on that one.
From my point of view, "webservices" (not distributed services in common, only that pseudo-new things) is just a hype, fired by Microsoft to push it's .NET strategy, then supported by Sun to push it's own ONE strategy against MS. Actually, it's nothing new, it's no cent better, and for me, I think, it's worse than what we have now. If we want to make our systems working together, we can do this, just by using e. g. DCE, CORBA etc.
Years ago, before the "big" CORBA and DCE times, I developed my own, proprietary middleware. It worked well, was faster and easier to understand than every hyped technology later (including DCE, CORBA and web services), better to support and maintain, as everything that came lateron. Sad but true, in that times I thought that no one needs something like this, since everyone I told about my project, lought at me since no one could imagine what a middleware should be for; well, times changed and now I lough at all this discussion, since it's a discussion between what of two or three re-inventions of the wheel would be that one that rolls best over water: The wheel's problem is that it will sink into water, so you can't make that paradigm better by using rounder, larger, smaller, wider wheels, even if they are promised to be flying (by Microsoft or Sun or IBM or Bea).
So what I do not understand is, why you all are only talking of possible benefits but not of what are really facts, what is really measured out, what is really needed. WHO REALLY NEEDS WEB SERVICES? Me not. Nor my customers. Nor my deliverers. If we WOULD need, we WOULD have it for years, since it's easy to do either with proprietary things, or with DCE, or with CORBA, or, at least, with "web services". The is no global need for this (even there are some solutions that work fine and that would be working even better with web service, but also they would with ANY aggreement of a common tehcnology, not only with web services). Not any technology or paradigm can solve every IT problem, so it definitively is a hype. It cannot make AIDS go away, it cannot let us all live for 200 years, it does not make cars fly (If we would believe Microsoft's marketing, web services, and especially that ones based on .NET, can bring global peace to the earth). It's just another technology and not a religion. So let's all calm down an re-activate our minds: Let's talk of what we really NEED (not what would be nice to have since we can make a lot of money with selling it). Let's talk of REAL benefits and REAL drawbacks.
If anyone feels to be forced to write a reply to this, my wish would be to read a list of real decision points where either technology gets a plus or minus. After that you'll see that either proprietary things, DCE, CORBA, and web services wil have all the same number of plus and minus. So there is no common winner, and with this, web services definitively is a hype.
Ho ho ho! "it's easy to do either with proprietary things, or with DCE, or with CORBA,"
You are a very funny person!
Ha ha ha! This discussion is loads of laughs!
Why would J2EE advocates be worried, there are a number of J2EE companies providing full Web Services implementation
IBM, BEA, Iona, to name a few. I thought the idea behind web services was integration ?
This is a fascinating discussion. I've enjoyed hearing about all of the viewpoints from the technologists in the world. In many cases the tech viewpoint and the business viewpoint contrast when it comes to web services. A couple of interesting pieces of information:
1) The app server vendors love the idea of web services. At BEA, we view web services as a complementary extension to J2EE -- it effectively extends the reach of your existing applications across departmental and corporate boundaries. Integration is a huge task to accomplish and web services are making it easier to do.
2) I know that many of us technies strive to find some "new" infrastructure / technology that is being developed and called web services. I can see how looking at SOAP makes everyone believe that it isn't anything revolutionary and hasn't been done with RPC, DCE, IIOP, RMI, DCOM. But, there are some infrastructure technologies that are being built which have never been built before. I would point you to take a look at the Business Transaction Protocol that is being done as a technical committee of OASIS. The BTP extends the 2PC concept to make transactions long running and loosely coupled without limiting scalability. This is truly a fascinating piece of work. With BTP, you can have a "cohesion" which is a transaction where some portions commit and some portions rollback. It's designed to follow the structure of a real business negotiation. For example, suppose you are getting a quote from 4 suppliers. All of the suppliers need to participate in the same transaction and prepare() themselves to meet the commitment. But, at any time, a supplier can withdraw from the transaction without impacting the whole cohesion. If the buyer withdraws from the transaction (cancels it), then the whole cohesion rollsback.
BTP basically defines a 2PC environment where Isolation is relaxed. It's pretty cool and this is a web services technology that isn't necessarily readily available in another format. Expect BEA, HP, Sun, Choreography, and others to adopt the infrastructure almost immediately.
More information can be found at www.oasis-open.org under Business Transactions. The expert committee is not isolated from the public and you can view their day to day activities in an archive. Additionally, Choreography has a simple demo available and I have an article on BTP coming out in the first issue of Web Services Journal.
Take it easy everyone.
I completely disagree that web services are a fad. The time for such services is slowly, but surely coming. I remember we've been kicking around this idea for many years (ever since we've gotten into OO). We didn't call it 'web services' then, but we did call it 'distributed services'. And it boils down to the same thing.
To base your conviction that a thing like web services is doomed to fail on the mere fact that it's introducing something new (i.e. 'new' automatically equals 'fad'?), is plain stupid. It may work in a 'if it ain't broke, don't fix it' situation, but can anybody convince me that the state of software application backlog today isn't broken? In other words, can we be complacent and claim that everytihng in the software development land is just hunky-dory, and that, no thanks, we don't need any help?
I'd be prepared to argue that we need a fix, and we need it badly. That's why we're frantically searching for it, trying out all the 'fads'. However, web services is not a fad, it is not new, and it is badly needed right now.
If you examine any high quality software application, you will notice that it has been built on the services model. Maybe not on the distributed services model, but definitely on the 'pluggable' services model. Such architecture ensures that things that inevitably change about that application are neatly separated from the things that remain holding through for it throughout its lifetime.
Now, web services are beginning to surface to fulfill the full promise of such model. Anyone who thinks it's just a fad, clearly doesn't understand the basic things about object oriented model.
People point at the volatile nature of such a network of services, stressing that no one will be able to base their business processing upon such a shaky ground. But, that view again reveals the lack of understanding of the underlying model. Here is how the model works:
It is based on the idea of the *best deal*. This means that there may be tons of credit approval services available to the consumer. When the time comes for an application to approve the credit for the customer, it may have to do some preliminary calculations in order to make a decision which service to use. If the customer is a low profile, low risk one (the credit amount is peanuts), the application will most probably opt for the dirt cheap, nothing fancy service. For the high profile, high risk customer, the application will suddenly get to be more picky. It will calculate that it pays to spend some money upfront in order to get a really good evaluation, as the quality of evaluation is what may make (or lose) a lot of money for the business.
So, all these services will be vying for your software's attention. They will be broadcast, and some of them will even have a negotiating module, which will allow your software to engage in negotiating some volume discounts and so on. One can easily imagine that there will be hundreds of credit approval services posted, waiting patiently for enterprise apps to use them.
Now, what if all of those hundreds of vendors go under one day, you ask? Although it is very unlikely, it's not the end of the world. Every prudent software developer would already have a fallback strategy built in -- although your intention is to use the high quality services from a vendor who specializes in those, you will still build your own, stripped down bare bones service. Just in case. If everything else fails, your software will fall back onto the home-grown service.
Isn't that how we already do things today (I mean, everything is home grown anyway)? Web services only add value to our enterprise apps.
Other objections (that it's potentially slow, not secure, etc.) are secondary. When you're evaluating whether to open a line of credit for the customer, you're not too keen on achieving a sub-second response time. You're much more worried about the accuracy of the evaluation. And your customer will understand and appreciate this concern.
Alex, I couldn't agree more. I think people need to get out of the lower level techo views of the world and realise that this is being done for business gain and therefore needs a broader view of things.
As I said in my previous post, this makes a rather bold assumption (at least now) that there won't be any customer locks and that people will be actually willing to "agree on interface, compete on implementation" w/o providing customer-locks (also known as "extended functionality").
Again, we aren't talking technical but business interfaces. There are areas which have well estabilished interoperation interfaces, but majority of them doesn't (hey, even invoices format differs from company to company).
So, I believe unless a) you come up with standards businesses will be willing to accept (at least reasonably big groups of them) and b) businesses will see the cost of re-implementing/wrapping their existing systems as offset well enough by the advantagess, web services will become a fad.
In my experience, a lot of businesses _is_ driven by "if it ani't broke, don't fix it" approach as they try to minimise the risks. That's why I say that if your system is really successfull, it will be in place in 10 years (with some modifications but essentially still the same system).
Granted, you will find groundbreakers, but it's about getting a critical mass of those willing to take risks, so the silent majority would be persuaded that the risk of not jumping on the bandwagon outweighs the risks of doing so.
If you'd come to a CIO saying "we can build your system so that you can use web services blah blah blah.. " few years ago, you'd probably get the money. Now they ask you "Ok, so what web services out there could we use now or within next 6 months?"
I agree with you that systems should be componentized - but that doesn't make web services the silver bulet as it's being presented now, just an another way of doing things.
The componentization is IMNSHO quite different issue.
Re "agreeing on the interface": yes, it is a huge problem. And yes, I recognize these are business, not technical interfaces.
Some seven/eight yeas ago, I was working for a health care facility IT department, building patient care software, and there I've learned that they have had already established a world-wide Master Patient Index. Effectivelly, that index is a standardized interface. What this index is saying is that anyone who wants to participate in the game of delivering patient care software must comply to this interface, period.
Now, they had the ability to establish this world-wide standard because they had the clout of a committee, consisting of world leading experts in the medical industry. In other areas of business, we don't have recognized experts, only pop star like celebrities who make obscene amounts of money. So, getting them to sit down and agree on the Master Customer Index, for instance, will be tough. Gates will want the world to use his Master Customer Interface, Ellison would like to push his own, McNeally his own, and so on. These people have to smarten up soon and to realize that their childish egos are holding the world back on its path to progress.
In the meantime, we don't have to sit on our hands and wait for those childish prima donnas to come to their senses. As somebody already noted here, web services do not necessarily have to imply world wide web. It's just a web of distributed services, for crying out loud! A group of vendors may get together and build their own, mini web services.
The main point is not to focus too much on the web of services itself, but to focus on our applications. How are our applications going to be using various services required for them to run successfully? Obviously, we cannot realistically expect that everyone will build everything inhouse (witness the huge software backlog phenomenon). We must build them in such a way that they are *extendable*. Meaning, we must build business frameworks that can adapt themselves to the abrupt changes in the overall business climate, as well as to the inevitable changes of focus within a given business paradigm. If a better service becomes available, we shouldn't be required to go back and redesign our applications so that they can take advantage of the improved services. This is the bottom line -- business applications should not make any assumptions about the implementation of the services, the only assumptions built into the applications are the assumptions about the interface.
As for the catch 22 you've exposed ("how many web services are out there today or within next 6 months?"), it's nothing new. We've been struggling for years to bring object oriented technology to the corporations. They always ask this same question ("how many business out there are using this?") Eventually, willy-nilly, they all reluctantly joined the OO train (as they did with the relational technology before that). Same thing will happen with web services.
I think we more agree than disagree. My main point was that its business need that drive the technology, not the other way around (now I guess I will start aflame war :) ). As with other things, web services are just another tool. It seems to me that given all the problems (quality, time to market, complexity etc.) in IT, people are desperately looking for a silver bullet and whatever comes is immediately praised as such.
Remember, main driver for OO used to be reusability - you will do OO and your code will be reusable. Did it achieve what it promised? I'd argue it didn't, as people were then thinking about reusability as simple code reusability (mostly).
What it did achieve though was getting people to start about componentization more, making refactoring more easy and a number of other good things.
The same goes for Java(web applets - > server side), J2EE (web application -> core enterprise systems) and lot of other things.
I believe the same will happen with web services. People now are talking how they think web services will be used, how many of them will be there, what they will be.. Most of them are probably wrong.
I think your picture of web services (i.e. not one WWW of web services but rather clusters of businesses than can agree on something regardless of what B-L-S say) is much more probable. And in my opionion what the main achievement of web services will be is more emphasis on componentization of your systems (I say this because people are already doing it. But most of them out there still doesn't know how to do it well).
IMHO Bill Clinton's 1992 campaign had the most meaningful thing to say with regard to Web Services, "It's the economy, silly."
To the extent that Web Services makes people's lives easier, enables them to do things for less time, money and/or effort, etc., it will survive and thrive.
Client/Server ushered distributed computing into the mainstream. J2EE looks like its well on its way in spreading the gospel of objects to corporations.
Web Services certainly holds the promise of liberating – programmatically – untold legions of heretofore-downtrodden knowledge workers. I, for one, wait in truckling obsequiousness.
OK, Vlad, I must say that you do have a valid point. Nobody knows how will this web services thing evolve and morph (your illustration with Java morphing from applets all the way to core enterprise systems was right on the money).
And, similar to Java, this fact that we probably don't know what we're talking about, but can rest assured that the idea will morph into something else, is an indicator of the web services flexibility. Java was flexible enough to take on all those disparate roles, and web services can potentially do the same thing.
Re "business needs driving the technology": look what happened when the roles were reversed (i.e. technology was arguably driving business needs during the past three years or so) -- the economy is in shambles now. Time to go back to the tried and true model (business needs first).
I would be prepared to argue with you that web services is just another tool. I think it's more like a concept, than a tool. But, I may be wrong.
Finally, to comment on your insight on OO being adopted for the reusability reasons -- reusability, as touted by early OO proponents, was merely a Trojan horse. It was a nice buzzword that many execs would buy into, but it never had any true merit. In other words, reusability was, and still is, a croak. I've been developing OO systems for almost 10 years now, and I've never really benefited from reusability. Whenever I was earnestly pushing for reusability, it always felt unnatural, contrived, and counter-productive. OO has other, much more powerful merits, and it's time we give this concept of reusability a decent burrial.
Regarding OO reuse, there are different levels of reusability..straight code reusue ala class libraries don't work that well..higher levels of reusable (frameworks) I think have proven themselves.
Yes, I agree with Scott if he only refers to the current state of affairs.
I think that we are still at the very beginning of the Web services story. History repeats itself one more time in that some vendors fuel the hype, which only leads to frustration with early implementors who expect too much too early.
From a business process management point of view, Web services make a lot of sense. Entire applications and business processes can be exposed as Web services.
However, there are major obstacles to overcome. Most notably, there are the transactions and the security issues. Today, one can only develop non-transactional, security-insensitive Web services when it comes to cross-plattform.
I wonder what Scott has written a few years ago when Java technology was in its early stages. For example, we all know that Java/J2EE takes years to complete and mature and we are not there yet. To me, the Web services technology is no exception.
Some pretty tough technical issues are yet to solve (transactions, security, quality of service and so on). I hope that the technology will be mature enough in 18-24 months from now.
Dieter E. Jenz
Let's take a look at the so-called 'over-hyped technology' thing...
As with most opinions, one camp will say "X is going to solve all your problems and you'll never need anything else." The other camp will say "X is rubbish and doesn't solve anything." The truth is, of course, somewhere in the middle. X, Web Services in this case, will solve some of your problems, not all.
Some specific points to address...
o If a vendor goes bust, software of web services, you are still in trouble.
- Yes... but if you own a piece of software, that software doesn't disappear - you just won't get updates/support etc. If a web service disappears, so does *YOUR* service.
o Use of UDDI/Dynamic discovery
- Is anyone suggesting the a business could/would write software which will dynamically lookup a web service and be able to use it 'out of the box'? This requires the ability to search by interface, which is fine, but if the UDDI server is not quality controlled, you are sending your data (however secure the comms might be) to *ANYBODY*. What are the legal implications with legislation like the Data Protection Act (or equivalent)? You can't just fire data you collect to any old someone and expect not to be sued.
o Infrastructure and Technical Restrictions.
- Web services requires an infrastructure which is simply not in place over the Internet. Fast access, secure comminications via services... these things are not going to be in place for a while.
- The idea that web services might not need to implement two-phase commit (2PC) is laughable. If I take from system A and put to system B, they *BETTER* make sure my data integrity is maintained or I will soon be out of business.
o All you need is J2EE.
- Many of us would like to think so but some companies have this weird idea that platform lock-in may become as bad as vendor/OS lock-in. The fact is, not everyone is going to use J2EE so the systems need to inter-operate. Web services try to help in this.
I could go on forever (as those who know me will testify!!) but to conclude, I think web services are certainly too immature to be used in business today, they might be usable in the future but you will have to use UDDI to discover services, access the quality of that service (perhaps the UDDI server will be quality controlled), and have a business continuity plan which you constantly revise which tells you what to do if the services vanishes instantly. If you want to use web services 'out of the box', I think the legal implications are *HUGE*. Like the yellow pages, you don't just look someone up category and use them. You look for trade association memberships and other signs of quality. How will you do this over UDDI unless you use it to initiate an offline quality assesment of the service?
Think some of you guys should check out ebxml.org
The majority of discussions surrounding web services seem very focused on the RPC side. But i think things like the the ebxmlms and Soap document based messaging stuff are better placed to prevail.
Sun have a free downloadable version of an ebxml registry/repository and JAXM is available as early access.
The ebxml specs are not as sexy at the moment as UDDI, WSDL etc but i think long term they will prove the better bet.
I'd say there are two keys in judging whether or not something is a fad:
- Is there broad vendor support?
In the case of web services, the answer is definitely yes. I can't remember the last time I saw IBM, Microsoft, Sun, BEA and Oracle all on the same boat. There may be differences in their implementations, but these are minor and will be ironed out over time. The same cannot be said of, say CORBA.
- Is it being used?
Many people pointed that web services are not ready for primetime - I disagree. We're using web services, and we have partners who are using web services. We have integrated our customer service partner and another partner using web services.
I know of a number of other people who have also implemented web services.
So, is it a fad? I don't think so - but time will tell. My gut tells me it's not a fad because it really just works on one area: integration. It makes putting together applications like corporate portals a lot easier than it currently is.
Will it change everything? Of course not. It's not designed to.
And why anyone is saying something like "All you need is J2EE" is beyond me - it's not a replacement for J2EE or any other platform. It's a wrapper to ease integration. It makes it easy to integrate that Microsoft COM app with that J2EE app (even in internal, LAN-based situations.)
I'm a believer in the tech, because it's good, simple and makes coding simpler.
You'll probably right when you point the "buzz world of Web services solutions", but, I think Web services aren't a revolution but the normal evolution of Internet communication between heterogenous system.
Most people think that the "Web services" are a new way to consider the web syndication. I mean the aggregation of multiple Web services on a single portal. I'm sure that this is the first pertinent web application targeted until Web service implement some features ( Web services caching, security, ...). Web services utilization will be more efficient and appropriated for B2B interchanges where proprietary middlewares are actually in place.
With or without noise around "Web services", the developers need such a simple, standardized, (and even free) middleware. Where CORBA fails Web services will succeed.
The main problem with Scott's article is that he isn't
specific enough about which marketing hype he's
addressing. Why, for example, does he assume that
the "web services" concept mainly applies to companies
that are identified as "ASP's" (or "WSP's")? For some
of us, "web services" is mainly about business-to-business
online interaction, e.g. Kellog's wants to buy some
pens from Staples, and instead of dealing with paper
purchase orders, faxes, and phone calls, they would
like it to be done electronically over the Internet.
If he sees "web services" as an assertion that nobody
will ever buy or download software any more, then sure,
I don't agree with that either. But that does not seem
to be what Microsoft, IBM, ebXML, Rosettanet, et. al.
are talking about when they say "web services".
Is Web Services the latest fad? Yes, it is. Look at the theme of the JavaOne conference this year - Web Services & Beyond. The people at JDJ have a new journal and a conference that is focused on web services.
Is it a doomed fad?? I beg to disagree to a certain extent with the author. The author is probably correct when he looks at web services from a ASP (hosting) standpoint and where they are deployed over a WAN (either frame relay or Internet based connections). Also, UDDI does not make much sense since companies negotiate contracts with vendors of services and do not programatically search a UDDI like yellow pages directory to find a web service vendor.
Consider the situation of a corporation (let's say in the financial industry). Does a single vendor fulfill all it's software needs? The answer is obviously NO. If there is such a software vendor (and please don't say Oracle or Seibel), buy the Brooklyn Bridge from them too. The reality faced by the CIO is that there will be many software vendors that will have to be engaged to provide many software systems (albeit for different functions and processes). Is there a need for these disparate software solutions to integrate (share data, work together as a part of one process etc.). In most cases, the answer would be a resounding YES. Can we simplify this integration? I think web services can be of help here. If two services (supplied by Vendor A and Vendor B) are web service enabled, the IT department in the corporation can achieve the integration between these two services. Vendor A and Vendor B need not know each other or the services need not be written in the same language or run on the same platform.
Looking at web services in a very simplistic way, invoking a web services is a Remote Procedure Call (I will probably get some hate mail from all web service vendors). Can the RPC signatures be in a standard format so that it is easy to use it? That's what web services enables.
Having tried to justify web services in one scenario, I would also say that it is in a stage of infancy. The author correctly points out that security, payment, and transaction related issues have not been addressed. There is work that is currently being done around using digital certificates for security. Other issues (I hope) will be addressed soon.
Is web services going to be used for other things (BtoC)? I don't know. Bill Coleman (CEO, BEA) presented a scenario during JavaOne, where a driver (or probably the device in the car) detects that the gas is running low and uses web services to request bids for gas from local gas stations. I personally think, that is a stretch.
To conclude, web services certainly have a role and would be very useful unless all the fad factor around it kills it. Is it the 'panacea' that it is touted to be? No
Scott proves why Papa Gates and Hailstorm will be so important to Web services noot being hype. Looks like Mr. Gates is actively correcting all those issues !!!
Scott Ambler's article makes a lot of compelling points to support his skepticism of web services.
In fact, he could be right on every point.
Yet, his ultimate conclusion is, I think, faulty.
(1) He's shooting arrows at the "pie in the sky" hype, but the reality is that web services will first be implemented internally, in environments where the endpoints are known and the business processes can be well-defined. In these environments, the core layers of the web services stack like SOAP will see a lot of use, simply because the are so eminently practical. We all know the Perl programmer's adage that laziness is a virtue. Well, laziness will ensure that the basic technologies behind web services will get a lot of use in internal integration projects. It won't be until these techs have been proven in controlled environments that external, dyanamic integration will become an issue.
(2) From a performance perspective, I suspect that specialization and unbundling of functionality will lead to better performance than what can be developed inside a J2EE-based application server. Today's app servers are huge, bloated beasts. Approaches like the web services model, other peer-to-peer models, and even good old parallel processesing are the ways out of the quagmire. Maybe not today, but I suspect that two years from now, we'll find that the sophistication and performance of web services operating environments will have matured far beyond their performance characteristics today.
P.S. One of my business partners has written a strong article that might be relevant to this discussion: "How Web Services Will Beat the 'New New Thing' Rap
Isn't this Web sevices business just modern day EDI. Supermarkets have been integrating their systems with suppliers sytems for many years now.
Which is easier - remembering success, or remembering failure?
Failure is always followed by "I told you so". "I told you so" is even more powerful if stated before the failure (prediction).
Success is rarely followed by "Gee, I was wrong". Even more rarely in the case where prediction of failure was suggested before the success.
The failure itself will be remembered, but not the predictor of the failure.
With success, the success will feel natural - but the chief advocates of the change will also be remembered. (Booch, Bill Joy)
I know which side I want to be on....
One important feature of Web Services that is often overlooked is the fact that Microsoft and the Java world are for the first time agreeing on a sensible middleware standard which is based on ubiquitous Internet technology (i.e. HTTP and XML).
Web Services are set to succeed where technologies such as CORBA, COM and RMI failed to various degrees.
The new SOAP, WSDL and UDDI standards are certainly a compelling solution for anyone involved in EAI and should not be seen purely for Internet applications.
And as for performance, I remember the same issues around Java a couple of years ago..
It is true that home-grown solutions based on standard XML parsers are likely to provide poor performance, but true Web Services Platforms being built by the likes of Cape Clear, for instance, are being built on newer, more efficient XML technology.
OK, web services aren't new, or a fad, they've been around for years in non-standard fashion. Every time you use an ATM (not from your bank) it uses a service to find your account, etc. This only works because the banks agreed on an interface. Imagine if they said, oh, but you need to use CORBA, COM, J2EE, etc. to use it...Some banks would never be able to implement the ATM. What's the interface? A dedicated network along with some text based protocol.
Same holds for financial services, news feeds, credit services, and a dozen other common services that businesses rely on every day. Main difference is these services are largely on private networks. Why? Security, control, qaulity of service guarantees. Why are the messages in arbitrary formats? Well, there wasn't anything better until now.
Web services supply a standard language to discuss service interfaces, wire-level data (yes, just like IIOP), etc. There are things that these basic protocols don't solve (stateful, long running interactions or callbacks to clients, for example), but hey, its progress, and it WILL change the world because the idea is so simple, and we've been doing it all along. XML, WSDL, SOAP, etc., just give us something new - momentum. I predict it will take about 2 years for the protocols to mature into something really robust, but by then dozens of essential web services will already exist.
Another often overlooked aspect of web services is that they might just be XML messages exchanged privately over a dedicated network using traditional technolgies like message queues. Its not necessarily about the Web, though HTTP and its firewall friendliness will certainly make it a leading transport candidate.
I am amazed; once again we don’t know what we are getting into. This time it is web services last time it was B2B. Ok it is time for some reality check. From software development point of view, doesn’t matter it is SOAP, IIOP, JRMP or any other RPCs call (in case of SOAP if you wanna call it web services it is fine with me) at the end of the day it is nothing but a set of APIs that I will call to develop my application.
Now talk about SOAP (the reason I am just talking about SOAP here is because the concept of WSDL and UDDI is awesome and make sense, but when it comes to SOAP things get really shaky). I remember a very good saying from Java one, “SOAP is not simple and it is not OO either” On top of that SOAP is stateless, no support for pass by refrence, and no support for distributed garbage collection. Hoin, when did the last time some one develop a serious application that doesn’t need stateful calls and pass by refrence semantics?
Some people are predicting that just wait years or two and SOAP will address all the issues (stateful, long running interactions or callbacks to clients, for example). Ironically the day we resolve these issues SOAP would not be so simple any more then. So we come back to square one again. Seocnd why wait two years, why don't we all agree to support a pre-existing mature protocol (my dream for peaceful world, of course big vendors are here to make money),the magic lies in agreement not in protcol itself:)
I still believe that web services will be successful only in the EDI world, where we need to exchange data in a standardized format with one coarse grained stateless call.
CORBA/DCOM failed mainly because of firewall issues and development complexities. But, one major advantage Web Services has is that they run over HTTP, and most of the firewall has Port 80 open.
ALso, in case of XML, majority of the data exchange takes place over HTTP and that is why it is more successful.
HTTP/XML has become the default protocol for data exchange and that is why I think Web Services (SOAP) can deliver their promise in B2B systems. It is not designed to replace Distributed Object Technologies like CORBA/COM+, but, as a wrapper over them for interoperability
WHile I fully agree with the posting I must say the following:
CORBA (IIOP) was (is) able to run over http, see "gatekeeper" in VisiBroker (or Borland AppServer, if you like), it was not standardized however.
But purely _technically_ speaking, SOAP is a very bad joke. We have a come a long way to invent secure environments, and most companies prevent e.g. IIOP from passing because it is considered "risky". Okay, now what if we can tunnel remote calls over http through a firewall???
Besides SOAP over http over IP calls are slower than e.g. IIOP over IP they are also less flexible, but the real joke is now we have an "unsecure" http, but ok, no problem, firewalls can parse all the http coming through and decide what to do.
I just ask myself if it wouldn't have been easier just focussing on IIOP or developing something new, whatever, instead of puttin layer on layer (while I think this is good, e.g. J2EE on JRE, http was meant for something else).
I've been working with Web Services for about 6 months, and I think that the big advantage is that it's an easy way to integrate applications, either extranet or intranet. I don't go along with the examples of hunting for cheaper gas from my car, or hunting for cheaper credit reports from a UDDI broker. But I go along with wrapping up business functionality, and then making a simple interface to it. It may sound like old stuff, but the original bit is the self-describing interface to business functionality, and the complete ease of integration. It makes every technology talk to each other very easily.
I have some questions though that I've been wondering about, and I've seen some references to them before but I haven't seen a good answer.
Question 1. How come everyone seems to associate Web Services with SOAP? Is this absolutely necessary? Is SOAP merely a delivery channel/protocol for Web Services?
Question 2. If SOAP is brilliant because it can pass through a firewall, what do I use if I don't need to go through a firewall? Are Web Services and firewall-passing abilities bound together, and without the binding I'm left with something other than Web Services? Especially for intranet EAI projects.
So I suppose, if I can access a Web Service over RMI or IIOP, does this mean it isn't a web service, but just a wrapped up piece of business functionality?
Scott Ambler writes:
"No doubt some remote services, such as credit card processing and tax calculation, will do quite well, but that's nowhere close to fulfilling the marketing hype around this concept".
Granted nothing could fulfill the marketing hype around the concept which rivals at times the absurdity of the latest MTV video launch, but I sincerely doubt the "killer app" of Web services will be offered tax calculator services. In the b2b space the primary "pain" is IT fragmentation and the associated cost of overcoming it for each and every business partner. Web services technologies begin to address this problem nicely, albeit recognising their relative immaturity.
As the Web services stack further evolves it will be to address more rich business interaction semantics as can be seen through the efforts of the ebXML camp and the evolution of WSFL/BPML etc. The types of services will then be "collaborative" rather than simply "offered", where participants at both sides of the service have good reasons to stay in the game.
Rather than being down and out I'm inclined to think Web services are just getting into the ring.
Scott is missing why web services are going to be important. It's not because any individual invention like SOAP is so great, but because it's all being driven by a growing understanding of a puzzle that has been in the air since 1994 or so:
As Scott points out, corba, dcom, client-server computing - and many other distributed computing approaches - somehow, they never really finished fulfilling their promise. Systems built with these techniques were fragile and could never grow very large.
But the Web itself - the biggest distributed computing experiment of them all - exceeded all expectations. It connects every company to every desktop; it constantly evolves, and it is robust. Why?
Well, there are really three parts to the answer:
(1) The web was all about the data, not the systems.
(2) The web was ground-up designed around asynchrony.
(3) Building a simple website was super easy.
Web services is all about bringing these key things to distributed computing in general, instead of just browsing web sites.
In his article, Scott complains about the inefficiency of parsing XML. In the early days of the web many very smart people complained about the inefficiency of parsing HTML. But if the web had just used some compact binary format, what would have happened? By losing sight of the focus on the data - goal #1, we wouldn't have had a proliferation of different compatible browsers and servers. And by giving up human readability of the data, we would have also lost super easy websites - goal #3. Moore's law guarantees that we have more than enough CPU cycles to parse a few less-than and greater-than symbols. It's a tiny-and-diminishing price to pay for the large-and-increasing benefits.
Scott complains about the lack of transactions over web services. But to demand distributed transactions everywhere, he loses sight of the asynchronous realities of the world, #2. What if Amazon had to involved your a web browser in two-phase-commit everytime you bought a book? Their little bookstore would have long ago been killed by the overhead. The Web works because everything - from client cookies, to multitier server design, to that little red "stop" button - was designed with asynchrony in mind. Traditional transactions should stay inside Amazon's data center. For complete distributed reliability, Amazon does the right thing and relies on asynchronous techniques such as confirmation email (that is a form of reliable queue) and web pages that let you check on the status of your order and cancel it (those are forms of polling and compensation).
The main challenge facing Web Services is to deliver on the long-elusive goals of distributed computing without losing sight of the key values that will make it possible.
An interesting trail and obviously a hot topic at the moment. My own personal veiw is that Web Services will become permissive where other distributed paradigms have not. This is due to the end points being technology neutral i.e. CORBA needed orb-to-orb, Java needed RMI-to-RMI, Microsoft technologies aka DCOM, DNA etc needed Windows-to-Windows whereas with Web Services the underlying technology is abstracted. Alright I know you can get around some of the above issues with bridges, but it still needs a more complex infrastructure and jeopardises real collabaration.
Web Services is obviously still relatively immature and I personally have seen it being used internally for low volume EAI transactions, and am already seeing it a natural abstraction of a Service Oriented Architecture in many B2B and B2Bi scenarios.
Of much more interest to me rather than the simple web services that we often see expoused in articles, are composite web services wrapped around business process, and also the client-side of technolgies such as Web Services that tools such as Cape Clear are now starting to address.
There is still a lot of work to do in terms of handling transactional failure, state, security, scalability etc, but you have to admit tis is a very interesting space.
As for performance of XML, isn't this what we were saying about Java a few years ago........
Yes and it s still true ;
Java takes the second place just after Basic in terms of performance,
Who doesnot agree with that assertion must do benchmarks
and then convice himself
Vive C++, Delphi and C#
This may come as a surprise to you, but did you know that the performance of C, C++ and Delphi code sucks in comparison to the performance of assembler code?
So, if you're so hung on sheer performance, why don't you code in assembler?
I personally think that with the increase in performance of hardware and the increasing speed of the Java platform itself with the iterations of JDK and JVM's that are occurring that this is becoming less of an issue. The below link gives an adequate overview of the pro's and cons in comparing Java performance to C++.
As usual it all depends on what your requirements are as to what technology choices are made. I have used Delphi for quite a while and happen to be most impressed with version 6.
I think it is important not to be the first one to jump on hottest tech in market. It is really important to assess new technology.
It would be really nice to have tech gurus not only talk about new technology but also list problems associated with it. This will direction to industry. Having said that site like this one (http://www.theserverside.com
) helps developer
to inveil the hype off.
I don't think many people understand what Web services (WS) are about. This is especially illustrated in the issue where Scott says "What if the vendor goes bust?". A kernel value of WS that folks like HP's Gupta saw and developed in E-Speak was that you can use and invoke services in a fuzzy sort of way using XML schemas. So if I need a service that can handle a certain format of customer data, I can discover this service from the registry using the schema as query criteria. The provider doesn't need to matter. I could be using one provider today and a completely different one tomorrow. So if one vendor goes bust today, another one providing the same schema can register and become available tomorrow. This is incredibly powerful. Check out what is still available at http://www.e-speak.net
There is definitely major value-add in WS, it's not just some other way of doing J2EE.