Woah. erm.
/me drinks glass of water. ok... (comments inline) > -----Original Message----- > From: ktegels [mailto:[EMAIL PROTECTED]] > Sent: 17 January 2003 15:40 > To: dotnet > Subject: RE: c#, xml, SOAP, etc > > > >>6+ years of VB-based development get a little dull! > Bit rot. It'd be like drinking an American Lager everyday for me. :) Hey, it pays the bills! > >>basic database interigation to get to grips with c#. > Well, if I might promote some of my own work then. We have a > great C# Data Access book out :) If I need a book to get connected to a database then there is something seriously wrong with the language :) > >>Hang on, I thought WebServices were just COMponents living > >>independently > on a server that could be requested like: > > Eh, not exactly. I'm going constrain this answer to > .NET Web Services (so my Unixish friends won't disChOwn > me...) I'm also framing this in the IIS5 server environment. > IIS6 (Windows.NOT Server) changes the rules a bit. .NET on W2K is our platform, thankfully. > WebServices (.asmx files) are a really ASP.NET pages > with different plumbing. When a WebService class is compiled, > the class is cached and hangs around someplace in memory, but > not in COM+ services (typically.) The IIS Web Service > instance that's hosting the WebService pages does register as > a distinct COM+ service if you set it up as "highly > isolated." Otherwise, it runs in the COM+ process for IIS. By > default, the class doesn't expose itself for use by COM in > this context. Ergo, you CreateObject on it and don't call its > methods via COM or DCOM. Hmm, so do I write .asmx files instead of building COM DLL's, or do I do both and call functions in my COM DLL's from the .asmx files? > You do call its methods by SOAP transports or HTTP. The > methods and properties are exposed for reference via > WSDL-formatted DISCO documents. In Visual Studio.NET, you > really don't care about this part a lot of the time. You > already know where the services live, so you just add a "web > reference" to your application and start using the Web > Service as if it's local object. So within the code it is just another object, but it lives on another server... and the server does the work? > VS.NET automatically > generates what's best described as a "stub proxy." > > The stub proxy is a little bit of magic that does all > the hard work. It digests the SOAP messages that are > exchanged between the client and the server so that to you, > they look like you directly using the methods of class that > running in the WebService on the server side. Frankly, that's > what's really neat about .NET. Since it writes that stub for > you, developing can't get much easier. It's also the problem. > The more you need/want to tweak the stub classes, the harder > it gets. So while they look like COMponents, and one uses > them like COMponents, they aren't. It's just superficial, > there's a lot of stuff going on under the covers. I am a bit lost but I'll take your word for it. :) > Your call syntax is 90%+ correct. That call makes the > stub send a SOAP message (media is XML, medium is probably > HTTP) to the Web Service. The web service sends back a SOAP > message to the stub and stub digests it into primitive data > types for you to use. Yes, you can make a Web Service/Proxy > pair return XML document fragments that aren't so digested -- > the stub just extract the payload from the SOAP message. > Digestion, if you will, is driven by the types express on the methods. So, the 'stub' extracts the data I want from the real 'message' that is sent back, less all the padding, as XML? > Is anybody else getting any good from this? > kt It's riviting stuff!!!! .b > -----Original Message----- > From: Ben Joyce [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 17, 2003 8:41 AM > To: dotnet > Subject: RE: c#, xml, SOAP, etc > > > Hi Kent, comments inline... > > > -----Original Message----- > > From: kent tegels [mailto:[EMAIL PROTECTED]] > > Sent: 17 January 2003 13:28 > > To: dotnet > > Subject: RE: c#, xml, SOAP, etc > > > > > > Chant the mantra with me: > > > > Good language is worth a dime. > > Good technology is worth a quarter. > > Good design is worth a dollar. > > Makes sense! > > > (Conversion to local currency as suitable :) ) > > > > In a similar situation, I probably start out by figure out > how to use > > interop to wrap the existing COM+ objects up as Web Services... > > We intend to re-write all our existing COM DLL's in c# (if we > can?) so that each one of us can work on them if needed, not > just the ones who know Delphi. > > > Then would have moved on writing the > > "pre-client" as an ASP.NET application that did any other > > processing need and transformation of the data to HTML for > > the client. > > Yeah, start off with something small and lightweight just to > test the stuff out with. > > > Then redo the components. Then, understanding how > > the system works, you can rewrite it as needed. > > > > In this scenario, C#, VB or Delphi could be used. Ideally, > the choice > > of language is more about being comfortable with being "best." > > Again, I hopefully with us all using c# we should be able to > maximise our time. We're all keen to learn something new > anyway, 6+ years of VB-based development get a little dull! > > > Using the wrong technology won't kill you, but > > it can either make things easier or more difficult. Having a > > bad architecture or a bad design can easily kill you with a > > project like this. > > > > Having done project like this: let me offer this. It's best > to start > > with small bites when trying to eat an elephant. Do the > simple stuff > > worth to get familiar with using the tools. > > Agreed. I'm of course aiming to start with basic database > interigation to get to grips with c#. > > > A lot of your excitiment (good and bad) is likely to come from > > learning the new stuff rather than from what you already know. > > > > I'd definitely recommend Alex and Dave's "ASP.NET Distributed Data > > Applications" too! > > Cheers; I'll make a note of that. > > > You're correct, more or less, about having COM objects > serve up SOAP > > messages. But interfacing to COM directly can be messy if your not > > using an MS platform if you have a firewall between the > parts. That's > > why I'd go to web services instead. Web Services use SOAP > to do their > > work. Your other assumptions seem right on the money. > > Hang on, I thought WebServices were just COMponents living > independently on a server that could be requested like: > > Dim strData > strData = > getCustomerList("http://webservices.xxx.com/customers.somethin > gorother") > > ...and the data sent back is XML? > > Have I got it wrong? > > > XSLT is really the cadalyst in converting XML to HTML (or > just about > > anything else.) You can apply an XSLT to a SOAP to format > data if you > > like. Using .NET, you don't have to bother. It will break down the > > messages into more directly usable things -- much like yest breaks > > down sugar in brewing beer. > > > > Helpful? > > kt > > Very! Hoping you don't mind more questions! > > Cheers, > > .ben > > > -----Original Message----- > > From: Ben Joyce [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 16, 2003 4:50 PM > > To: dotnet > > Subject: RE: c#, xml, SOAP, etc > > > > > > Hi Kent. > > > > The project is very real and very big. There are three developers > > working on in, myself and two others. The other two chaps > are from a > > strong Delphi background, and as I mentioned I am primarily > a VB/ASP > > man. We've decided to start writing any new modules for our CRM > > product in C# with view to do a complete re-write. > > > > It makes sense for us all to learn this together so we can > work more > > efficiently. Currently all the COM libraries are written > in Delphi so > > there is a certain element of waiting for those bits to be > completed > > before progressing. > > > > My understanding in that the data can be served up by COM objects > > (written in C#) to a variety of clients via SOAP. Am I right in > > thinking that we can ship all the real processing and data > collection > > to the server, leaving us with very lightweight clients? > > > > I'm not quite sure where XSLT fits in; is this something to do with > > automating the production of HTML pages using XML as the > datasource, > > something like that? > > > > I appreciate any advice you can offer to a .net newbie and his > > collegues > > :) > > > > Cheers, > > > > .ben > > > > -- > > ben joyce // [EMAIL PROTECTED] // +44 (0)7958 933718 // > > http://www.babelfish.co.uk > > > > > -----Original Message----- > > > From: ktegels [mailto:[EMAIL PROTECTED]] > > > Sent: 16 January 2003 18:47 > > > To: dotnet > > > Subject: RE: c#, xml, SOAP, etc > > > > > > > > > Ben, > > > > > > Thanks for the props about Wrox books! > > > > > > C# is worth getting a book on if you'd not done classic C or > > > C++ before. If > > > you've done C or Perl, C# is pretty much cake. > > > You really need two XML books in my mind. First is any > > basic primer on > > > XML. Second is Tennison's "Beginning XSLT." No doubt that Dr. T > > > knows her stuff and she's great writer. > > > Web services is different horse. If you're going to write > > > them with an MS > > > tool, I really like our beginning web services books. If your > > > going to use > > > some other platform (say Java) be prepared for a lot of work > > > and reading. I > > > agree that Web Services really aren't hard to write, there's > > > just a million > > > ways to botch it up. :) > > > > > > The best thing to do IMHO is to do. Find something you want > > to write a > > > web service for and go for it. MS makes it easy, fast, > and harder to > > > customer. Other tools -- IMHO-- make it harder, slower but more > > > rewarding. > > > > > > Kent Tegels > > > Contributing Author, Wrox Press > > > > > > > > > -----Original Message----- > > > From: Ben Joyce [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, January 16, 2003 11:54 AM > > > To: dotnet > > > Subject: RE: c#, xml, SOAP, etc > > > > > > > > > Yeah, Wrox are usually pretty good. > > > > > > As work is paying for it I'm thinking of getting this: > > > http://www.wrox.com/books/1861007329.htm > > > > > > I'm from a strong ASP/VB/COM/SQL background (5 years) and have > > > recently started using PHP, hopefully the jump to C# > > shouldn't be too > > > tricky. The Web > > > Services stuff sounds funky, I'm dying to have a go. > > > > > > Cheers! > > > > > > .ben > > > > > > > -----Original Message----- > > > > From: Travis D. Falls [mailto:[EMAIL PROTECTED]] > > > > Sent: 16 January 2003 17:50 > > > > To: dotnet > > > > Subject: RE: c#, xml, SOAP, etc > > > > > > > > > > > > Ben, > > > > Before you buy a book check out the web for soap and xml > > tutorials. > > > > Soap is just a protocol/standard that you format you xml > > in. Once > > > > you understand basic xml (it isn't that complicated it > is just a > > > > standard way to mark up plain text) you will can just > read up on > > > > soap on the web. They you can buy or find a book on C# > is should > > > > have a section on xml and touch on soap. The wrox (big > > red books) > > > > should have a good section. I have done soap and xml > before, and > > > > accessed then via java and vb.net. I am sure C# is the same. > > > > > > > > travis > > > > > > > > -----Original Message----- > > > > From: ben joyce [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, January 16, 2003 12:20 PM > > > > To: dotnet > > > > Subject: c#, xml, SOAP, etc > > > > > > > > hi all. > > > > > > > > just wondering if anyone can recommend a good book for > > learning how > > > > to build & use SOAP objects in c#/xml. My idea is that my > > > > app/website (plan to write both) will request data via > SOAP. c# > > > > will talk to the database and return data in XML back to > > the calling > > > > > > code, where is is displayed. > > > > > > > > I've never used c#, very little XML and not touched > SOAP so a good > > > > book is needed! > > > > > > > > suggestions appreciated! > > > > > > > > Cheers, > > > > > > > > .ben > > > > > > > > --- > > > > You are currently subscribed to dotnet as: > > > > [EMAIL PROTECTED] To unsubscribe send a > blank email to > > > > %%email.unsub%% > > > > > > > > --------- > > > > Administrated by 15 Seconds : http://www.15Seconds.com List > > > > Archives/Search : http://local.15Seconds.com/search > Subscription > > > > Information : http://www.15seconds.com/listserv.htm > > > > Advertising Information: http://www.internet.com/mediakit/ > > > > > > > > > > > > --- > > > > You are currently subscribed to dotnet as: > [EMAIL PROTECTED] To > > > > unsubscribe send a blank email to %%email.unsub%% > > > > > > > > --------- > > > > Administrated by 15 Seconds : http://www.15Seconds.com List > > > > Archives/Search : http://local.15Seconds.com/search > Subscription > > > > Information : http://www.15seconds.com/listserv.htm > > > > Advertising Information: http://www.internet.com/mediakit/ > > > > > > > > > > > > > > > > > --- > > > You are currently subscribed to dotnet as: [EMAIL PROTECTED] To > > > unsubscribe send a blank email to %%email.unsub%% > > > > > > --------- > > > Administrated by 15 Seconds : http://www.15Seconds.com > > > List Archives/Search : http://local.15Seconds.com/search > > Subscription > > > Information : http://www.15seconds.com/listserv.htm > > > Advertising Information: http://www.internet.com/mediakit/ > > > > > > --- > > > You are currently subscribed to dotnet as: [EMAIL PROTECTED] To > > > unsubscribe send a blank email to %%email.unsub%% > > > > > > --------- > > > Administrated by 15 Seconds : http://www.15Seconds.com > > > List Archives/Search : http://local.15Seconds.com/search > > Subscription > > > Information : http://www.15seconds.com/listserv.htm > > > Advertising Information: http://www.internet.com/mediakit/ > > > > > > > > > > > > --- > > You are currently subscribed to dotnet as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > > %%email.unsub%% > > > > --------- > > Administrated by 15 Seconds : http://www.15Seconds.com > > List Archives/Search : http://local.15Seconds.com/search > Subscription > > Information : http://www.15seconds.com/listserv.htm > > Advertising Information: http://www.internet.com/mediakit/ > > > > --- > > You are currently subscribed to dotnet as: [EMAIL PROTECTED] To > > unsubscribe send a blank email to %%email.unsub%% > > > > --------- > > Administrated by 15 Seconds : http://www.15Seconds.com > > List Archives/Search : http://local.15Seconds.com/search > Subscription > > Information : http://www.15seconds.com/listserv.htm > > Advertising Information: http://www.internet.com/mediakit/ > > > > > > > --- > You are currently subscribed to dotnet as: [EMAIL PROTECTED] > To unsubscribe send a blank email to %%email.unsub%% > > --------- > Administrated by 15 Seconds : http://www.15Seconds.com > List Archives/Search : http://local.15Seconds.com/search > Subscription Information : http://www.15seconds.com/listserv.htm > Advertising Information: http://www.internet.com/mediakit/ > > --- > You are currently subscribed to dotnet as: > [EMAIL PROTECTED] To unsubscribe send a blank email to > %%email.unsub%% > > --------- > Administrated by 15 Seconds : http://www.15Seconds.com > List Archives/Search : http://local.15Seconds.com/search > Subscription Information : http://www.15seconds.com/listserv.htm > Advertising Information: http://www.internet.com/mediakit/ > > --- You are currently subscribed to dotnet as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------- Administrated by 15 Seconds : http://www.15Seconds.com List Archives/Search : http://local.15Seconds.com/search Subscription Information : http://www.15seconds.com/listserv.htm Advertising Information: http://www.internet.com/mediakit/
