Some good reads on XML & Web Svcs & Enterprise Apps

Post #44,494 by dmarker2 7/4/02 9:13:26 PM 7/5/02 10:05:32 PM Reply	Some good reads on XML & Web Svcs & Enterprise Apps (The 2nd linked-to article below ends with this very cute quote) :- "These are exciting times. If none of this makes your heart beat a little bit faster, you might want to check your pulse because you're probably dead." ************************************************************************** [link\|http://www.infoworld.com/articles/fe/xml/02/07/08/020708fecollab.xml\|Link to Article 1 - excerpt below] THE NEXT GENERATION of enterprise applications is promising to shed traditional shackles, spanning functional silos to link data seamlessly among customer, supplier, financial, and other applications both inside and outside company firewalls. With greater amounts of data exposed as XML and tied together via Web services, enterprises are looking to lash together compenentized business processes to attack business problems with the best parts of existing applications. These emerging collaborative or composite applications will combine functions from multiple application systems to execute a larger, near real-time process that will then be published as a Web service. etc:, etc:, etc:... "Web services is the first real hope for having a transport-agnostic, platform-agnostic, and firewall-agnostic way of doing a component or composite application model," says Suresh Chandrasekaran, director of product management at Vitria in Sunnyvale, Calif. And yet, the Vitrias, Tibcos, and webMethods of the world still contend that the old must coexist with the new, the result of which will be an architectural melange of message-based and service-oriented infrastructures. "Stringing together Web services does not an application make," says Andy Astor, vice president of enterprise Web services at Fairfax, Va.-based webMethods. Astor singles out the missing elements of Web services, including transactionality, security, and management, as hurdles to the adoption of collaborative apps beyond the firewall. "When the components are done, it becomes a matter of integration, business process automation, and workflow," he says. etc:, etc:, etc:... These next-generation enterprise applications will reside in a services architecture that will be driven primarily by business functions and process as opposed to data, according to industry observers. In a services-oriented architecture, an enterprise could call a service to place an online order and execute original logic rather than send data back and forth, explains Mike New, director of integration strategy at WRQ in Seattle. For example, WRQ exposes business functions from SAP or Siebel or legacy systems as discrete components; as a result, a company can literally drag and drop a business function from SAP followed by something from an IBM mainframe without rewriting code, New adds. etc:, etc:, etc:... [link\|http://www.infoworld.com/articles/op/xml/02/01/28/020128opnoise.xml\|Link to Article 2 - excerpt below] WHEN MORE THAN 700 people in this economy show up for a two-day InfoWorld conference on Web services in San Francisco, you know fundamental change is in progress. The question most people want answered is, How will these technologies actually change software applications for the better? People get the idea that Web services are a set of industry-standard protocols based on XML, SOAP (Simple Object Access Protocol), and UDDI (Universal Description, Discovery, and Integration) that will make it easier to integrate applications. What most people still don't understand is that these technologies will also create an entire new category of software known as collaborative applications. The trouble with most software today is that just about every application we use is point-to-point in nature. That means it can effectively reach out to only one data source at a time. All that is about to change -- and it's high time it did. etc:, etc:, etc:... [link\|http://www.infoworld.com/articles/hn/xml/02/01/15/020115hnvitria.xml\|Link to Article 3 - excerpt below] ENTERPRISE APPLICATION INTEGRATION is dead, long live business process integration. So says Vitria CTO Dale Skeen. In an interview with InfoWorld Editor in Chief Michael Vizard and Test Center Director Steve Gillmor, Skeen explains why he thinks Web services will create the perfect scenario for taking Vitria to the next level of business process integration and collaborative applications. etc:, etc:, etc:... InfoWorld: What impact will Web services have on EAI? Skeen: I think traditional EAI [enterprise application integration], which was concerned with messaging middleware and connectivity, is dead. Web services will provide the universal way to connect. What we'd love to see is a world in which the messaging infrastructure and Web services become ubiquitous and transparent, so we don't have to deal with it. etc:, etc:, etc:... InfoWorld: What impact will service-oriented architectures have on applications? Skeen: We are all transitioning to a service-oriented architecture. And that's good, because that helps with the interactions. Today you need both service-oriented and event-oriented, because service-oriented will easily get information in and respond to requests that you make. Event-oriented says that the application has to proactively notify things. We expect more and more to see in the middle of these major apps a collaborative application that you would need to notify instead. We think the killer apps for Web services are collaborative applications. Doug M Edited by dmarker2 July 4, 2002, 11:21:42 PM EDT Edited by dmarker2 July 4, 2002, 11:27:41 PM EDT Edited by dmarker2 July 4, 2002, 11:34:58 PM EDT Edited by dmarker2 July 4, 2002, 11:37:54 PM EDT Edited by dmarker2 July 4, 2002, 11:38:22 PM EDT Edited by dmarker2 July 4, 2002, 11:43:17 PM EDT Edited by dmarker2 July 4, 2002, 11:45:36 PM EDT Edited by dmarker2 July 5, 2002, 09:53:16 PM EDT Edited by dmarker2 July 5, 2002, 09:59:35 PM EDT Edited by dmarker2 July 5, 2002, 10:03:04 PM EDT Edited by dmarker2 July 5, 2002, 10:05:32 PM EDT Expand All History
Post #44,495 by ben_tilly 7/4/02 9:20:16 PM Reply	Stupid question What are they doing about the kind of common problems that resulted in businesses deciding that they needed firewalls in the first place? Ignore the issue now, then buy third-party products later that claim to make them safe? Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #44,515 by dmarker2 7/5/02 3:52:07 AM Reply	Re: A sincere question is rarely stupid. An answer can be Re the Q - yup security is a major component of XML and various forms of security either have been or are being proposed for SOAP messages. An <element></element> in XML can have its contents encrypted and the key can be pointed to or embedded in the XML. Digital signatures are supported in XML for non-repudiation. An entire XML message including element tags, can be encrypted but there are obvious reasons why that can defeat much of the value of XML and its tags. a) If the tags are common knowledge then encrypting them assist crackers in decrypting the element data, b) one of the great benefits of XML is being able to search tags for sepcific content. Once they get encrypted such searching gets killed. Encrypting element data is perfectly adequate - the mechanism has been defined in XML standards. As for virus issues. They shouldn't be part of XML & Web Services unless XML were to contain features that allow for in-line execution of portions of an XML document & thank god that bit of insanity (a la VB script) is not part of XML or Web Services. Cheers Doug
Post #44,526 by ben_tilly 7/5/02 7:13:28 AM Reply	This area seems to have a major confusion... between encryption (making sure that others cannot snoop on my communication) and security (making sure that my system is not readily abusible). The two are not particularly closely related, and definitely are not substitutes for each other. In this brave new world I think we will see a lot of having 2 parties open up a key exchange, and then proceed to communicate back and forth with no other thought to security. Sample mistakes will be that an undue amount of your internals will be available for perusal by the person you are perusing with, and the old web cart mistake of entering a negotiation and then trusting the prices that the client gives you. Cheers, Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #44,591 by dmarker2 7/6/02 4:26:54 AM Reply	Re: Web Services Servers might introduce challenges ... Web Services communicate between servers that listen on specific ports for SOAP messages. Web Servers are peripheral to Web Services. The servers can reside on the same type of box but a web servers servers web pages while a SOAP server recieves & forwards SOAP messages only. The SOAP listener sits on a nominated port (which is published in the WSDL definintion for the service being requested) on a tcp/ip connected server. The SOAP listener examines the request type in the SOAP message to determine which internal task (which will itself be listening on another port) and dipatches the request to the task on that other port. Web Services don't actually need web servers. They tend to though because web servers will typically provide the *.wsdl documents that provide the IDL info for accessing the service. A UDDI server is kind of a cross between a web server and a web services server. They will normally respond to both HTTP & SOAP requests. So the security issues you talk about relate to how to screw a web services server & this is a bit different from stuffing up a web server. Cheers Doug
Post #44,968 by tuberculosis 7/9/02 8:10:00 PM Reply	I don't buy it Any of it. Before I put on my grumpy face - thanks for the links. I appreciate it and this is totaly not directed at you or any readers here. That said - whats different about this hype wave vs B2B exchanges, the semantic web, CORBA, OO code reuse, 4GLs, etc.... The writers act like XML and SOAP (which is an appallingly bad pair of technologies) is suddenly going to make a lot of effort writing code go away. The FACT of the matter is that it takes no less (and with all the UDDI crap and added complexity I'll say it takes a bit more) work to implement a "web service" than it does to implement it as a CORBA service, an RPC, an email message handler, or directly callable interface. Its still going to take work and the directory stuff doesn't help much at all. Its still going to require human relationships and phone calls to make this stuff work reliably. Heck, after spending last year building Cacheon's J2EE application porting workbench, I've found that given two XML documents that are specified off the same standard, stupid little quirks like whether there was a linefeed as the last character or not made interoperability as unrealizable as a wet dream for a eunuch. In fact, of the SOAP implementations out there, precious few work reliably together and many A-B interfaces will require bits of manual tweaking to get them set up. Truly a plug and pray world. Additionally, the only variant of SOAP that doesn't completely suck is SOAP with attachments (which practially nobody implements) - should you disagree, try building a web service which takes an html docment and runs tidy on it and get back to me. Inlining HTML into XML is FUGLY. I could go on and on about how XML is neither a good markup language (what it claims to be) nor a good structured data serialization format (what its mostly used for) or about how SOAP took a perfectly simple idea and obfuscated the hell out of it with weird concepts like soap envelopes, headers, bodies, pluggable serialization schemes when nobody can even get the one working, or about how watching the web services crowd repeat the entire learning process in the zippies that the OMG did in the 90's (next we add security, then transactions, then...) but I think I've said enough. The reason the web services seminar is heavily attended is that everybody in the bay area is out of work, has nothing better to do, and is grasping at straws looking for the next big fad to fuel a new round of VC idiocy. Webservices has been a slow starter though and frankly I think there will be some services created - but its not making my heart beat any faster because I just can't get excited about redoing the 90's in XML. Also, it sure would be great if someone could figure out a better example than the stupid stock quote or trader example. It makes me yawn everytime I see it. The average hunter gatherer works 20 hours a week. The average farmer works 40 hours a week. The average programmer works 60 hours a week. What the hell are we thinking?
Post #44,997 by dmarker2 7/10/02 2:29:15 AM Reply	Re: I don't buy it - My experience is opposite I have all IBM's WS toolkits Web Services Toolkit VisualAge fo Smalltalk Web Services feature WebSphereStudio Developer (Java) with Web Services and I am finding I can do WS demos easier that any previous technology building the same type of function. The Smalltalk WS facility is amazing - it has taken a while to get here but it works and the performance is far better than I had imagined it would be. One simple example - With VA Smalltalk I can create a Web Service in a few hours that accesses a COBOL program reading an ISAM file, and publish it as a web service and demo it. That is effectivel doing EAI. If you are criticising the technologies, I suspect you may not have seen or tried some of the new tools that support it. Give it a go, it is worth it Cheers Doug
Post #45,007 by tuberculosis 7/10/02 4:56:47 AM Reply	Yeah but you're all IBM so far Interop with other SOAP toolkits is going to come dear I think. But we'll see. I have to do some interop with external vendors and I'll certainly define some standard interfaces and give it a go. But I'm not at all optimistic that it will be any better than homegrown message formats over http. The average hunter gatherer works 20 hours a week. The average farmer works 40 hours a week. The average programmer works 60 hours a week. What the hell are we thinking?

Welcome to IWETHEY!