News: Adobe Products Redesigned for J2EE and Web Services Standards
Adobe is widening and deepening its presence in the electronic forms market by moving to a single, Java-based platform.
- Posted by: Dion Almaer
- Posted on: June 09 2004 18:42 EDT
The company hopes to offer a single way to connect to all the different data sources in an enterprise, allowing companies to use Adobe's document services products with Java APIs and Web services protocols that allow them to be tied to different data sources within the same enterprise, such as its CRM and ERP systems.
Read more at: Adobe Products Redesigned for J2EE and XML Web Services Standards
- Adobe Products Redesigned for J2EE and Web Services Standards by John Davies on June 11 2004 04:54 EDT
- Adobe Products Redesigned for J2EE and Web Services Standards by Mark N on June 11 2004 07:33 EDT
- why don't you use, by Rolf Tollerud on June 11 2004 13:03 EDT
why don't you use, by John Davies on June 12 2004 07:07 EDT
OS2 was not so smart by Rolf Tollerud on June 12 2004 09:26 EDT
OS2 was not so smart by John Davies on June 12 2004 11:11 EDT
pride and honour by Rolf Tollerud on June 12 2004 06:08 EDT
pride and honour by John Davies on June 12 2004 07:35 EDT
to be able to use Java and .NET libraries together by Rolf Tollerud on June 12 2004 10:39 EDT
- to be able to use Java and .NET libraries together by Rolf Tollerud on June 13 2004 12:20 EDT
to be able to use Java and .NET libraries together by Robert Dean on June 13 2004 10:26 EDT
rtmono by Rolf Tollerud on June 13 2004 01:04 EDT
- rtmono by John Davies on June 13 2004 04:09 EDT
- rtmono by Rolf Tollerud on June 13 2004 01:04 EDT
- to be able to use Java and .NET libraries together by Rolf Tollerud on June 12 2004 10:39 EDT
- pride and honour by John Davies on June 12 2004 07:35 EDT
- pride and honour by Rolf Tollerud on June 12 2004 06:08 EDT
- OS2 was not so smart -- not talking about OS2 by Robert Dean on June 13 2004 10:13 EDT
- OS2 was not so smart by John Davies on June 12 2004 11:11 EDT
- OS2 was not so smart by Rolf Tollerud on June 12 2004 09:26 EDT
- why don't you use, by John Davies on June 12 2004 07:07 EDT
Ignoring the marketing hype that always follows these types of announcement this is great news for Java and bad news for Microsoft.
I've had a unfortunate displeasure of having to re-architect several document systems in banks. A lot of them have made the wrong choice of using Microsoft Word, frequently along side packages like Documentum. There wouldn't be enough space on this forum to list the problems and horrors I've seen as a consequence, even Documentum themselves have acknowledged the errors of their ways, their honesty moved them up greatly in my estimations, it great to meet a vendor who admits they made a mistake.
In a nutshell, you have traders entering deals in one system and at the same time confirming the orders with a fax or email (trade confirmation). These then have to be handled as they're received by the corresponding banks and then matched and reconciled with the original trade entered in the trading system and a new confirmation printed with enriched information.
The problem comes when you start to ramp up the volume, with an "normal" architecture you simply run on bigger hardware, increase the number of parallel threads and distribute it, normally not a problem. Try this with MS Word though, firstly you can't use a decent OS, you're stuck with Windows which doesn't go down well in most banks where the servers are generally UNIX based. Secondly have you ever tried to run several version of Word on the same machine? This means that even with a nice but 4 CPU box with 4 GBytes of RAM you're now bottlenecked with Word. We did manage to get several versions running on one box but if just one copy of Word dies (which it always does) the whole damn machine's got to be re-booted. I've seen exactly the same scenario at several different banks, most simply reboot the machines every few hours or every night. This of course does nothing to promote the [stability of Windows] to the UNIX guys running the large systems. You even need dedicated printer servers, the normal ones are UNIX and they don't work with Windows. Basically Word does not integrate with large systems, as with everything in the Microsoft world, it is designed to be run on a desktop, not at the enterprise level.
Now, enter Java, XML, XSL-FO and Adobe, you can do real mutlithreading, distribute it, and there are loads of decent tools for merging, processing, printing, transformation, signing, integration and persistence. In every bank (using Word) this was deemed to be the ultimate solution. We knocked up a prototype once that ran over 20 times faster on a single desktop machine than the Word version running on 2x4CPU boxes.
With Adobe moving their tool set towards Java and J2EE this is be a serious blow to Microsoft, Adobe has always been a good solution but now that they have committed marketing too we can expect an easier sell to the otherwise Microsoft-centric business managers.
Good news guys, welcome to the Java world!
I've had similar experiences, just not on the same scale. I've tried to use Word, Excel, Powerpoint and Outlook as APIs and, believe me, it wasn't fun. The APIs seem to be designed as an after thought and the UIs expose more than the APIs (Try telling the customer why you can't access what he can see). Alot of my stuff was/is deployed to a desktop or one instance on a server and it still was a nightmare.
I had seen that Adobe had purchased a "Java Company" recently and had hoped this would be the result. Hopefully they will continue to move in a "good" direction.
C#, XML, XSL-FO and Adobe, with real multithreading, and distribute it with decent tools for merging, processing, printing, transformation, signing, integration and persistence.
Then you got an equal solution if not better.
Word is a quite right a desktop application, as you point out.
As for Adobe, we will see what will happen in the future, the pdf features is embedded in Longhorn XAML.
I think C#'s a great language but in reality almost every bank on the planet uses UNIX and AS/400s etc. behind the desktops. Document processing is usually a server side process, while they do need to be frequently delivered to a C#/VB/C++/Office desktop apps most of the nitty-gritty goes on on the servers.
This is why Adobe have added WebServices to the offering as well as Java/J2EE. .NET has a strong place in banks but predominately on the desktop and front-office dealing rooms where you will find "small" applications running Excel around .NET servers. Talk to someone who works in Bonds or Credit/Equity/Cash Derivatives and their view of the IT will probably be largely MS/.NET (C#, VB, Java and J2EE), talk to someone in the back office and they'll be running Windows NT4 with a terminal session full of RGP. There are of course exception to this but I'm not in a position to mention individual bank's preferences.
Again C# would be great if it could integrate as well as Java and run on existing hardware (as Java does). Microsoft's wish is of course that everything thing runs on .NET and there's no need to integrate anything. Integration is the key in this case, since Microsoft never really recognised CORBA and JMS they've excluded themselves from the integration market place.
I have no doubt a .NET solution would work, it might even be faster given the 27 latest service packs, personally I doubt it would scale very well either but that's just my personal opinion. Anyway it would work in this scenario but it would also create more problems that you're trying to solve when it comes to integration with the rest of the bank's $2billion worth of UNIX/IBM etc. hardware. For the very few banks that are slightly more MS centric it is often a solution they consider.
It may very well be as you say, but when you compare you can not compare with technique from 1995. You are right in that the banks are Java's last stronghold. According to a study by Forrester, on the question of "Which one platform will be used for the majority of your development work in 2004?" 56% of finance and insurance enterprises answered J2EE and only 44% .NET, that is exactly opposite to the overall result.
Forrester Study may 5, 2004
in reality almost every bank on the planet uses UNIX and AS/400s etcIt is Java that is under siege, not .NET.
Marketing Rolf, all marketing. Partly true, some distorted facts, some simply false. It's also US based and therefore rather limited in scope, it's got some pretty graphics but I would take most of it with a pinch of salt.
I can't comment with authority on other industries, I work in wholesale banking and that's mostly Java/J2EE. I come across Microsoft based systems but mostly just on the desktop, MS have a good desktop and office suite but that's it.
Strangely I feel less "under siege" now than I did 2-3 years ago.
How do you explain Adobe's move to Java/J2EE etc. it's ovbiously not just for the banking/telco market place.
Stop fighting the evelotion. Look, in only 12 lines all jakarta-commons is converted to CLI code:
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-logging.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-attributes-api-SNAPSHOT.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-attributes-compiler-SNAPSHOT.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-beanutils.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-collections.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll commons-pool.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:sax2.dll -reference:commons-pool.dll commons-dbcp.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:commons-collections.dll -reference:sax2.dll commons-digester.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:commons-logging.dll commons-discovery.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:commons-logging.dll commons-fileupload.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:commons-logging.dll commons-lang.jar
mono ikvmc.exe -target:library -reference:IKVM.GNU.Classpath.dll -reference:commons-logging.dll commons-validator.jar
Just reference the IKVM.GNU.Classpath.dll in Visual Studio.NET and you can use all libraries in .NET, having the combined power of both Java, the real Java not J# and C#. Both on Windows and Unix/Linux.
But thanks to and politics and rivalry you can not do that with more complex libraries as for instance Hibernate. That is because the GNU Classpath is not finished yet done as it is by part time workers and without any funding. If Sun had buried their grievances for MS for long time ago this would have been reality today.
No, Sun does not allow to compile the rt.jar into CLI, neither will they open source Java, they have the whole word as hostages as huge amount of money and resources is wasted every day only because of pride and honor- nothing can help Sun to stop going out of business anyway.
You really are one in a million, I really don't give a toss whether Jakarta-commons compiles and runs in CLI or not, well, perhaps it's good news that it does but I really don't care.
Sun hasn't open sourced Java, great, I'd rather they didn't, Microsoft certainly wouldn't and they've done no better with any of their languages either.
The point is, and was, that Java is still a better language to use on existing hardware and also a better language for integration with legacy systems. If I wanted to write an app to integrate with Microsoft products only then I may well choose C#, I have spent quite a bit of time using it and I like it as a pure language. I do not however like the idea of working on an OS that is supported by just one vendor. Over the 25 plus years of working in IT it has taught me to reduce risk by increasing options.
Rolf, you obviously like the MS world, I'm not a huge fan, this is about Adobe moving to Java and J2EE, again I ask you the question, why do you think they moved?
I really don't give a toss whether Jakarta-commons compiles and runs in CLI or not, well, perhaps it's good news that it does but I really don't care.Jakarta-commons was just an example. If it wasn't for Sun, Hibenate, Spring, Tomcat, etc - all would compile to IL and run with CLR. You do not want that because you see C#/.NET as a threat, not a possibility. But of course it doesnt matter it will happen anyway.
Microsoft is about to deprecate Adobe's pdf format. Therefore Adobe looks to Java and J2EE for a "safe" heaven.
"pdf format". I meant Adobe's products..
You do not want that because you see C#/.NET as a threat, not a possibility. But of course it doesnt matter it will happen anyway.C#/.net is neither a threat nor a possibility. It won't run on non-Windows systems and businesses run a lot of their core operations on non-Windows systems, so it's not even an option. Don't even try to say mono or dotGNU are options because you well know Microsoft's antipathy towards open source under GPL. If Mono or dotGNU ever looked like it would take business away from Windows, they would pull out their patent arsenal and mire it in a legal battle, the same way they're allegedly doing by their SCO proxy.
Microsoft is about to deprecate Adobe's pdf format.Just a few Rolf msgs back you said PDF was going to be included in XAML. Which is it, Rolf?
Therefore Adobe looks to Java and J2EE for a "safe" heaven.No, Adobe looks to Java and J2EE because it doesn't lock them into running on Windows.
If Mono or dotGNU ever looked like it would take business away from Windows, they would pull out their patent arsenal and mire it in a legal battleExcuse me. I am just marking this thread so I can search it out in a year or two!
Excuse me. I am just marking this thread so I can search it out in a year or two!RegardsRolf TollerudMake sure you note it down on some paper Rolf because I doubt your browser will last that long. Two years is a lot of viruses and service packs!
It's been fun. :-)
My computer is always on 24/7. Once every other month I download OS updates and run the antivirus protection. In all this time I never once have seen any "blue screen" and never had had any virus problem. The (Norton) firewall I disconnected long ago as it served no useful purpose and interfered with my Skype.
This is the third year now going on forth. The only problem I ever had was the SQL Server "Slammer" attack, which did no harm and was fixed on 5 min. And may I add, I use Outlook for all my mail.
So keep on, maybe some weak-minded will believe you. BTW in May last year, 19,208 successful breaches were recorded against Linux based systems, compared to 3,801 against MS Windows based systems. http://www.theinquirer.net/?article=9845
And, maybe can you answer,
How many times has Microsoft initiated a patent infringement lawsuit in the past? Were any of these lawsuits instrumental in eliminating a competitor?
Daniel H Steinberg:
What surprised me most was how the topic of Java, even among and between perfect strangers, always returned not to the technological flaws of our platform, but to the "jerk" attitudes of our developers.http://weblogs.java.net/pub/wlg/1343
"The best argument against Java is a five-minute conversation with the average Java zealot."
You can quote me on that one.
"The best argument against Java is a five-minute conversation with the average Java zealot."You can quote me on that one.RegardsRolf TollerudI will, only to say that the same can be said for .NET. Really the same can be said of anything. Zealots are zealots. Always too overbearing and twisting facts to get the result they want.
<q> ... and never had had any virus problem </q>
On my previous job a few years ago the company lost about 70,000 documents (Word, Excel) due to a virus. We (4000 employees) could not use computers for almost 2 days...
<q>It's been fun, yes </q>
An angry troll's post is a funny thing to read indeed! :) Like a machine-gun! Hope he's feeling better now!!! :)
.Net inherits all of the VB, C++, C and other Windows desktop apps. If the overall result is *only* 56% .net, 44% Java, then that is good news for Java.