Very valid points from the Daves. I can swallow this explanation much easier than "COM is dead". But it leaves me with the hanging question:
What do I do if I can't abandon MS products? I mean even XP has COM under the hood. So far, Office 11 is going to be the first to try a native web service approach. (btw. Won't this cause security issues for home users?) So, until a whole new wave of MS products come out, what is the work around? I could setup another server running .NET and communicate via web services, but it doesn't seem to make much sense. Surely not a very scalable solution either. Not too mention, I'm now splitting my systems between two architectures. My confliction is that Office is a huge product. More than not, companies have Office installed on all of their workstations. We're seeing Corel kick up a bit more competition from their deal with Gateway and Compaq, but I don't think it's going to have much gain on Dell/Office hold on the business place. Now saying that J2EE cannot interact with Office is a big detractor. Every company that wants to move to a J2EE solution will still need to keep some NT boxes around. There just has to be some workaround in java. Has anyone come up with some .class files for manipulating office documents? Do you think it would be more stable to write the office interaction in c#, and use the CRL to compile into java classes? Technically, I'd still be at the same scenario of having java talk to COM, but maybe MS's java will reduce the complications. Although the CRL for Java was not very good the last time I used it. Has anyone tried this? Adam Wayne Lehman Web Systems Developer Johns Hopkins Bloomberg School of Public Health Distance Education Division -----Original Message----- From: Dave Watts [mailto:dwatts@;figleaf.com] Sent: Wednesday, November 06, 2002 5:24 PM To: CF-Talk Subject: RE: ActivePDF (web grabber) and CFMX. (long) > COM is NOT being abandoned by MS. Dave and Steve failed to > back that statement up in the last thread. > > Ok. So even is MS comes up with a replacement for COM, you > basically jumping on the bandwagon of a technology isn't > even in public beta yet! Waiting for office 11 is not a > realistic solution for anyone. Upgrading to Office 11 isn't > either. > > Gee upgrade your entire corporation to Office 11, or just > move you web systems to .NET and continue to use COM. Again, > if MM doesn't fix this critical issue, they will eventually > lose the market. > > Again, with no proof of COM being axed on MS.com, I have to > say that your facts have been skewed by MM and Fig Leaf. While you may disagree with my statements, I think I provided enough information to back them up. Nevertheless, I'll respond to this. First, Fig Leaf doesn't have a "COM agenda". I stated my own viewpoint previously, and I don't claim to speak for Fig Leaf as a company about COM. I'd be perfectly happy if MS continued to support COM, and provide new COM stuff, and if all the COM stuff would work fine in the distant future with every new product and platform. I don't like rewriting code any more than anyone else does. But the hard fact remains that COM doesn't seem like it has much of a future, as far as I can see. Second, if you follow Microsoft technologies, you'll be hard-pressed to come to any other conclusion than MS is distancing itself from COM. Every month, I read MSDN Magazine, and I follow new MS product releases, and guess what? No COM in sight! Now, a year or so ago, there were plenty of articles on COM, MTS, COM+, and so on. Third, it's worth noting that the vast majority of COM component providers (Mabry, SoftArtisans, etc) are working on .NET versions of their products. If you want to know the future of a platform, look to the people who make their money directly from that platform, and you'll get a good idea which way the wind is blowing. Fourth, I suspect that the issue of COM support in CFMX just isn't all that important to MM, in the big picture. I think that they decided it was more important to have CF run on top of Java than to have backward compatibility with COM. I think they were right to make that decision (assuming they did). Fifth, Microsoft has a historical record of "obsoleting" their own software. I can't remember all of the times they've done this. The most recent example is that you won't be able to run Office 11 on Windows 95/98/ME. Sure, you'll be able to run your existing COM stuff on your existing platforms, but that's not much of a future. Finally, CF 5 isn't all that good a COM client, either, and while you can do stuff with individual, discrete COM objects like ActivePDF, it doesn't work well with COM hierarchies, or heavy usage of COM objects (typical middle-tier COM like you'd use with a well-architected ASP application). So it's not like we've lost all that much. > Well CF5 didn't have COM issues. It was very easy to > leverage to power of COM through Cold Fusion, and as > a result, many of us have integrated COM into our > solutions. Now, if our COM solutions don't work... > they we cant upgrade. Plain and simple. Although it > may be a JAVA issue, it's still a feature that CF lost. > That MM promised. As I mentioned above, I would argue that CF 5 does have serious COM issues. If I had a dime for every time I cursed at CF 5's COM support, well, let's just say I'd have a lot of dimes. Once, I worked with a COM vendor briefly to figure out why their objects wouldn't work well in CF 5 - the server would end up crashing, essentially, because CF didn't release the objects appropriately. Oops! And with CFMX, the fact is that some COM stuff works, and other COM stuff doesn't - just like with CF 5, except the things that don't work now may have worked before, and vice versa. So, there's COM support, and MM has met their obligation in a very real sense. Did you expect them to test their COM library against every COM object you're using? Did you test your code during the beta? I'll freely admit that COM doesn't work as well in CFMX as in CF 5, but that's not saying much, in my opinion. > I'd like to know where you read that MS said they were not > using COM again. I don't think there's been a headline on MSDN Magazine that says that. It's more a matter of what isn't said. Microsoft likes to push their technologies to developers, and lately, there's been very little mention of COM in that push (the sole exceptions being stuff like "how to work with your legacy COM in .NET". Draw your own conclusions. > I know office 11 will have native web services built it, but > web services are NOT an acceptable replacement. > > COM ----> Web Services ----> Applications > > I use COM objects to create web services. Taking out the > foundation of the architecture doesn't help at all. COM is an interface. SOAP is an interface. I don't really see any difference between what you can do with one, versus the other. COM is supported by Microsoft. SOAP is supported by everybody and their brother. COM isn't the "foundation of an architecture" any more than any other interface is. Just because it's a binary interface, and SOAP isn't, doesn't make one more "foundational" than the other. > Are you assuming that MS will design a web service > for every possible office interaction? That's > impossible. Say you wrote an app using COM to open > a word document and add the line "COM rules" to the > third and eighth page of the document. MS will not > have a native web service to do this for me. I will > still need to access the application architecture > to do this... and that is what COM does. It gives > us access to that architecture, web services can > only serve to buffer between COM and and you > applications. Again, COM and SOAP are just interfaces. MS can write its software to expose itself via whatever interface they choose. I can't say I know how they plan to do this, since I'm not currently participating in the Office 11 beta, but I think you're seeing a fundamental difference where none exists. You wouldn't need a separate SOAP interface for every possible Office interaction, just like you don't need a separate COM object for every interaction. Now, whether these will be "web services" in the currently accepted meaning of the term - SOAP over HTTP - is an open question. SOAP is transport-independent; you could send SOAP messages using interprocess communication (named pipes) or any other way. Or, maybe, they won't use SOAP at all - these things might be exposed through the .NET interface mechanisms, whatever you call them. But the fact remains that there's no technical impediment to using SOAP for this kind of stuff, just like COM is used now. > So is it activePDFs fault for believing MM when they > said they would have COM support in CFMX? You act like > MM said a year ago to stop using COM, that it would no > longer be supported. No, it's not ActivePDF's "fault". It is their problem, though. First, again, there is COM support in CFMX. You might not be happy with its performance, but it's there. Second, if ActivePDF cares about selling its product to CFMX users, they might want to expend some effort to make sure it works - that's what beta cycles are for. Personally, I suspect that few enough CF people use their product, and they just don't care enough to expend the necessary effort (which could be significant), but I want to stress that this is pure speculation on my part. > The bottom line is that the majority of software is > written on MS standards and C. The best way to utilize > these technologies is COM. If you want Java to grow in > popularity, it needs to at least be able to handle COM. > Mostly for integrating with the millions of corporation > who use MS solutions. (Exchange, Office, etc.) This just goes to show how much one's own situation affects what one sees. Java seems to be growing in popularity pretty well without COM support, actually. I'd venture a guess that the majority of enterprise systems aren't written on MS standards (or C, for that matter). I think that if CF is going to survive, it'll have to work well with these enterprise systems, and moving in the direction of Java certainly makes that more likely, in my opinion. And to reinforce a previous point, have you ever tried to work against Exchange with CF 5? I don't recommend it, really. Exchange functionality is accessed through the Collaborative Data Objects library (CDO), which requires account impersonation and exposes itself as an object hierarchy. In conclusion, I'm not trying to sell you anything, and if you're happy using COM, good for you. I just think that your expectations are a bit unrealistic, if you think that Macromedia can do a whole lot for you with this. If you depend on COM that much, you may need to stick with CF 5 for those solutions. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
