Webservice question

[Steven Blair]

Here is my problem:

I need to write web application which can do the following:

View Accounts
Add an Account
Update an Account
Close an Account

My first thought was an ASP.NET pp using a C# dll containing the
functionality. The drawback with this, is the interface is restricted
because of the dll (any additional customers wishing to use the system
would require the dll and connection details).

Should a web service be use for this, and can webservice allow me to add
/ update recrods using XML?

This would allow a customer to create their own interface and then speak
to my webservice without any software from me.

Any help on this matter would be appreciated.

Regards,

Steven

 

[Kevin Spencer]

This would allow a customer to create their own interface and then speak

to my webservice without any software from me.

What are the requirements? Are you supposed to design the business classes
only, or an interface as well? What is the network environment of this app?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
To a tea you esteem
a hurting back as a wallet.

 

[Guest]

Could you open the topic more wide?
What is the account? Where is located? Who is the consumers? What's the
bound of application? And etc.

Here is my problem:
I need to write web application which can do the following:
View Accounts
Add an Account
Update an Account
Close an Account

My first thought was an ASP.NET pp using a C# dll containing the
functionality. The drawback with this, is the interface is restricted
because of the dll (any additional customers wishing to use the system
would require the dll and connection details).

Should a web service be use for this, and can webservice allow me to add
/ update recrods using XML?

This would allow a customer to create their own interface and then speak
to my webservice without any software from me.

Any help on this matter would be appreciated.

Regards,

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Steven Blair]

Sure,

A bit more detail:

The Accounts represent a customer on our existing Database (personal
details are stored here).
Functionality must exists which will allowed Account records to be
updated, added or closed.
As it stands just now, I will be developing a web front end to interface
with a C# dll (the dll will have methods such as Add and Update).
Another requirement which would be exteremly useful would be external
customers being able to use our Add / Update functions. This is what
first got me started thinking about using a webservice.

My API (Add, Update, View & Close) needs to be available over the
internet for other peoples interfaces to access.
Using the dll approach would require each customer to have a copy of the
dll, as well as using .NET.

My small understanding of webservices led me to believe any web front
end could access the service, and call my Update method for example,
without the need for any .NET code.

Obviously, I need to understand if that is possible, and how difficult
it is to perform Updates / Adding records using this technology.

Would Customer A, after adding a Account on their interface send a XML
record to my service, where I would update my Database (I guess bind the
XML to a DataSet).

I hope this answers all your questions.

 

[Guest]

The Accounts represent a customer on our existing Database (personal

details are stored here).
Functionality must exists which will allowed Account records to be
updated, added or closed.
As it stands just now, I will be developing a web front end to interface
with a C# dll (the dll will have methods such as Add and Update).

Aha. You need expose your logic to the business context. This DLL should to
be either COM+ or WebService.

Another requirement which would be exteremly useful would be external
customers being able to use our Add / Update functions. This is what
first got me started thinking about using a webservice.

WS is not obligatory, but recomended

My API (Add, Update, View & Close) needs to be available over the
internet for other peoples interfaces to access.

Moreover, that should be 2 components, one for guest (View, Close) another
to admin (Add, Update)

Using the dll approach would require each customer to have a copy of the
dll, as well as using .NET.

In case of just dll - yes, but if u use WS/COM+ your component will be
hosted in some environment and all functionality will be exposed to customer.

My small understanding of webservices led me to believe any web front
end could access the service, and call my Update method for example,
without the need for any .NET code.
Sure

Obviously, I need to understand if that is possible, and how difficult
it is to perform Updates / Adding records using this technology.

Just to create proxy of your component and call methods (UpdateUserInfo for
example)

Would Customer A, after adding a Account on their interface send a XML
record to my service, where I would update my Database (I guess bind the
XML to a DataSet).

Indeed

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[KBuser]

If the database is SQL Server or mySQL I'd be leaning towards PHP.

 

[Nick Malik [Microsoft]]

Hi Steven,

Sure,

A bit more detail:

The Accounts represent a customer on our existing Database (personal
details are stored here).
Functionality must exists which will allowed Account records to be
updated, added or closed.
As it stands just now, I will be developing a web front end to interface
with a C# dll (the dll will have methods such as Add and Update).
Another requirement which would be exteremly useful would be external
customers being able to use our Add / Update functions. This is what
first got me started thinking about using a webservice.

So create the web service in Visual Studio and have it reference the same C#
dll. This is called a 'service proxy' pattern.

My API (Add, Update, View & Close) needs to be available over the
internet for other peoples interfaces to access.
Using the dll approach would require each customer to have a copy of the
dll, as well as using .NET.

The dll approach doesn't work at all. If you share out the dll, then the
mechanism that your dll uses to access the database would have to be open to
the world. So, if your dll accesses your db using ADO.Net, then you will
have to leave ports open on your SQL Server so that copies of that dll can
access the same SQL Server from a remote machine. Your DB will be infected
within a few minutes. No, this option is not an option at all.

My small understanding of webservices led me to believe any web front
end could access the service, and call my Update method for example,
without the need for any .NET code.

Not sure why you'd want your own web front end to access the web service.
Have the web front end call the C# assembly. Have the web service available
for your customers to use, but don't use it yourself. This is really
inefficient for no good reason.

Obviously, I need to understand if that is possible, and how difficult
it is to perform Updates / Adding records using this technology.

Trivial. If you create a 'web service' project in Visual Studio, you will
get a class that has the needed attributes that denote that it is the
code-behind for a web service. VS will write all the web service proxy code
for you, and will call your class. You code your class to call your C#
assembly and return data just like any other call. You never have to deal
with XML.

Would Customer A, after adding a Account on their interface send a XML
record to my service, where I would update my Database (I guess bind the
XML to a DataSet).

When you author a web service using Visual Studio, you will get a file
encoded in WSDL. You don't have to do anything to make this happen. It is
automatic. When Customer A is developing their client code, they tell
Visual Studio to use your web service. VS will request the WSDL file, which
contains a definition of the XML needed for that client app to make the
call. VS will write the client proxy for your customer. When your customer
wants to call a method on your service, it is just like calling a class on
your object. The code that is written for you deals with all the SOAP
stuff, so you don't have to.

Hope this helps.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--