>>6+ years of VB-based development get a little dull!
Bit rot. It'd be like drinking an American Lager everyday for me. :)
>>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 :)
>>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.
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.
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.
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.
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.
Is anybody else getting any good from this?
kt
-----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.somethingorother";)
...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 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/
