Big-Picture Question (Web Services, RegNow)

[Jonathan Wood]

I was wondering if some of you could advise me on the following issue.

I ported my code that generates shareware licenses to a C# class. I'd like
to get to the point where this is done online (and eventually done
automatically).

What is the best way to expose this functionality on the Web? Are Web
services the answer--I know almost nothing about them?

I'm also wanting to work with RegNow. While they don't seem to currently
support registration via Web services, they might if pushed.

Am I on track here? Does this seem like a reasonable approach? Can anyone
point me to where I could find more information on these issues?

Thanks!

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Mark Rae]

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Webservices are the solution when you are faced with the following two
situations:

1) your code needs to be available over the web (duh!)

2) your code needs to be available in more than one web app

Are you intending to provide some sort of web portal which other
organisations can use to provide on-line licence keys for their apps, or
maybe for online software activation the way Microsoft (and now others)
do...?

Can anyone point me to where I could find more information on these
issues?

There are literally hundreds of examples on the net - just Google...

Writing a webservice really is very simple these days with Visual
Studio.NET - it pretty much isolates the developer from all the SOAP stuff
(though it's still there, of course) - you pretty much just point and click
to add a webservice to an existing site, fill in the code, compile, test and
deploy.

[Laurent Bugnion]

Hi Mark,

Mark Rae wrote:

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Webservices are the solution when you are faced with the following two
situations:

1) your code needs to be available over the web (duh!)

2) your code needs to be available in more than one web app

I see at least one more reason to use web services:

3) You want to transmit (relatively) complex objects without having to
deal with the serialization/deserialization mechanisms.

To me, it's the main reason why I would use SOAP web services over a
simple ASHX custom handler, for example. It's neat to add a web
reference to your application and to have the whole proxy created
automatically for you...

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jonathan Wood]

Thanks for the input. I'm contacting RegNow to see why this is not an
option.

BTW, does anyone know of a way to return multiple fields from a Web service?
I'm only able to see how to return a single field (the function's return
value).

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Mark Rae" <ma**@markNOSPA Mrae.comwrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Webservices are the solution when you are faced with the following two
situations:

1) your code needs to be available over the web (duh!)

2) your code needs to be available in more than one web app

Are you intending to provide some sort of web portal which other
organisations can use to provide on-line licence keys for their apps, or
maybe for online software activation the way Microsoft (and now others)
do...?

>Can anyone point me to where I could find more information on these
issues?

There are literally hundreds of examples on the net - just Google...

Writing a webservice really is very simple these days with Visual
Studio.NET - it pretty much isolates the developer from all the SOAP stuff
(though it's still there, of course) - you pretty much just point and
click to add a webservice to an existing site, fill in the code, compile,
test and deploy.

[Laurent Bugnion]

Hi,

Jonathan Wood wrote:

Thanks for the input. I'm contacting RegNow to see why this is not an
option.

BTW, does anyone know of a way to return multiple fields from a Web service?
I'm only able to see how to return a single field (the function's return
value).

Thanks.

The constraints for web methods are exactly the same as for "normal"
methods: One return value only, but it can be anything including array
(if you have many "fields" of the same type), or an object including
different properties.

All public properties/attributes of the returned object will be
serialized and transmitted.

However, if you can, I recommend to keep it simple. First you'll avoid
serialization problems, and second, remember that web services clients
are not only C#, but could be anything, including JavaScript (it's quite
easy to make a web service call using JavaScript). For example, instead
of transmitting a DateTime object, why not transmit a string
representation of that DateTime... you get the idea.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jonathan Wood]

Laurent,

The constraints for web methods are exactly the same as for "normal"
methods: One return value only, but it can be anything including array (if
you have many "fields" of the same type), or an object including different
properties.

That's interesting. I tried using out parameters but the VS 2005 testing
mechanism for asmx files does not support that. I just tried returning a
string array. This is supported. Unfortunately, there is no way to name each
of the string fields returned.

However, if you can, I recommend to keep it simple. First you'll avoid
serialization problems, and second, remember that web services clients are
not only C#, but could be anything, including JavaScript (it's quite easy
to make a web service call using JavaScript). For example, instead of
transmitting a DateTime object, why not transmit a string representation
of that DateTime... you get the idea.

Yes, and I agree wholeheartedly. However, I'm writing a service that
provides a registration code for my software. It seems like it would be more
straightforward (and more standard?) to include two return values: One that
indicate success or failure, and another that provides the registration code
(or error message on failure).

I don't want to do anything that is out of the ordinary but it seems like
this would be a good, simple approach, one for which XML is well suited. If
this is not at all standard, I could include a pass/fail string at the start
of my return string. But only seems like it would be harder for the consumer
of my Web service to deal with.

Thanks!

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Laurent Bugnion]

Hi,

Jonathan Wood wrote:

Laurent,

>The constraints for web methods are exactly the same as for "normal"
methods: One return value only, but it can be anything including array (if
you have many "fields" of the same type), or an object including different
properties.

That's interesting. I tried using out parameters but the VS 2005 testing
mechanism for asmx files does not support that. I just tried returning a
string array. This is supported. Unfortunately, there is no way to name each
of the string fields returned.

An array's fields are not named. Once again, it's the same as for a
normal method.

>However, if you can, I recommend to keep it simple. First you'll avoid
serializatio n problems, and second, remember that web services clients are
not only C#, but could be anything, including JavaScript (it's quite easy
to make a web service call using JavaScript). For example, instead of
transmitting a DateTime object, why not transmit a string representation
of that DateTime... you get the idea.

Yes, and I agree wholeheartedly. However, I'm writing a service that
provides a registration code for my software. It seems like it would be more
straightforward (and more standard?) to include two return values: One that
indicate success or failure, and another that provides the registration code
(or error message on failure).

That's easy to do. Create a class:

public class ReturnValue
{
public bool success = false;
public string registrationCod e = "";
}

then, in your web method, declare:

[WebMethod]
public ReturnValue GetRegistration Code()
{
ReturnValue returnValue = new ReturnValue();
returnValue.suc cess = true;
returnValue.reg istrationCode = "1234";
return returnValue;
}

As easy as that.

I don't want to do anything that is out of the ordinary but it seems like
this would be a good, simple approach, one for which XML is well suited. If
this is not at all standard, I could include a pass/fail string at the start
of my return string. But only seems like it would be harder for the consumer
of my Web service to deal with.

Thanks!

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jonathan Wood]

Laurent,

That's easy to do. Create a class:

public class ReturnValue
{
public bool success = false;
public string registrationCod e = "";
}

then, in your web method, declare:

[WebMethod]
public ReturnValue GetRegistration Code()
{
ReturnValue returnValue = new ReturnValue();
returnValue.suc cess = true;
returnValue.reg istrationCode = "1234";
return returnValue;
}

As easy as that.

Cool! That gives me all the control I need. The book I'm reading said it was
better to stick with basic types but I didn't realize that a class that
contained only public basic types would work as well! That gives me complete
flexibility on the results!

For giggles, I also tried accepting a class as the argument (since I have
quite a few input args). That would be cool also. Unfortunately, the VS Web
service test mechanism did not support this, which makes me think others
might not support it either, so I'll avoid that.

BTW, can you tell me the effect of initializing class variables as you did?
That would seem to bypass the constructor somewhat. I didn't realize you
could do that.

Thanks!

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Laurent Bugnion]

Hi,

Jonathan Wood wrote:

Laurent,

Cool! That gives me all the control I need. The book I'm reading said it was
better to stick with basic types but I didn't realize that a class that
contained only public basic types would work as well! That gives me complete
flexibility on the results!

For giggles, I also tried accepting a class as the argument (since I have
quite a few input args). That would be cool also. Unfortunately, the VS Web
service test mechanism did not support this, which makes me think others
might not support it either, so I'll avoid that.

Show the code. Accepting custom types as parameters should also be
supported.

However, note that there are all kind of clients able to send a request
to a web service. The given client is responsible for serializing (i.e.
transforming into XML) the given parameters, and for deserialiazing
(i.e. transforming from XML) the returned value.

If your client is a .NET application, you don't have to worry too much
about it, because the serialization/deserialization mechanism is
automatically provided (by the web reference, also called web service
proxy).

BTW, can you tell me the effect of initializing class variables as you did?
That would seem to bypass the constructor somewhat. I didn't realize you
could do that.

What I did, for simplification, was provide public attributes in the
class. It is not recommended in normal cases, because anyone could
modify the attributes at any time. However, for simple "packing" when
using a web service, that might be sufficient.

When an attribute is public, you can set and get its value without using
properties. Normally, the usual way is rather to create private
attributes, and to provide public get and set accessors, named
properties. In that case, you can choose to initialize the variables
using the constructor.

The following 2 examples are stictly equivalent as for the result of the
operation.

Example 1:

public class Test1
{
public int attrib1 = 0;
}

Test1 test1 = new Test1();
test1.attrib1 = 5;

Example 2:

public class Test2
{
private int attrib2 = 0;
public int Attrib2
{
get { return attrib2; }
set { attrib2 = value; }
}
}

Test2 test2 = new Test2();
test2.Attrib2 = 5;

Example 3:

public class Test3
{
private int attrib3 = 0;
public int Attrib3
{
get { return attrib3; }
set { attrib3 = value; }
}

public Test3( int param3 )
{
attrib3 = param3;
}
}

The differences are:

In the case 2 and 3, you can introduce additional checks in the "set"
property. For example, you may throw an exception if the value is
smaller than 0.

In the case 3, you make sure that the attributes are always initialized.
There is no default constructor. (The examples 1 and 2 also don't have
an explicit default constructor, but the compiler provides one when no
constructor is defined.)

Note that this has nothing to do with web services, it's basic C#. Don't
hesitate to ask more if something is not clear.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jonathan Wood]

Laurent,

Show the code. Accepting custom types as parameters should also be
supported.

However, note that there are all kind of clients able to send a request to
a web service. The given client is responsible for serializing (i.e.
transforming into XML) the given parameters, and for deserialiazing (i.e.
transforming from XML) the returned value.

If your client is a .NET application, you don't have to worry too much
about it, because the serialization/deserialization mechanism is
automatically provided (by the web reference, also called web service
proxy).

My code is like what is shown below but while it may be supported by some
clients, Visual Studio won't run it for me. If I change the arguments to be
the members of RegArgs, then VS has no trouble with it. Note that while I
may want to access this service from a .NET application, I certainly want it
available to clients using different platforms as well.

[WebService(Name space = "https://www.mydomain.co m/")]
[WebServiceBindi ng(ConformsTo = WsiProfiles.Bas icProfile1_1)]
public class ProductRegistra tion : System.Web.Serv ices.WebService
{
public class RegArgs
{
public string name = "";
public string password = "";
public int productId = 0;
public int cpus = 1;
public string custName = "";
public string custCompany = "";
public string custAddress1 = "";
public string custAddress2 = "";
public string custCountry = "";
public string custPhone = "";
public string custEmail = "";
}

[WebMethod(Descr iption = "Returns registration information for a
product.")]
public string RegisterProduct (RegArgs args)
{
return "BlahBlahBl ah";
}
}

In the case 3, you make sure that the attributes are always initialized.
There is no default constructor. (The examples 1 and 2 also don't have an
explicit default constructor, but the compiler provides one when no
constructor is defined.)

I understood the part about making variables private and exposing them
through properties, and also why that might be beneficial.

I just wasn't used to initializing member variables in place rather than in
the constructor. As you probably know, you cannot initialize a member
variable like that in a C++ class. I wasn't aware you could do it that way
in a C# class. I'm assuming the effect of this is the same as initializing
the variable in a constructor: i.e. the variable is initialized to the
specified value when an instance is created.

Thanks!

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com