needing help - constructor overloading

[alberto.decaro]

Hello everybody,
I'm developing a XML web service in VB, and I'd like to overload the
constructor to customize the service:

[...]
Private _tblParameters As datatable

'the default constructor
Public Sub New()
MyBase.New()
InitializeComponent()
End Sub

'the overloaded constructor
Public Sub New(parTable as datatable)
Me.New()
_tblParameters = parTable
End Sub
[...]

The project compiles correctly and I can add the web reference in the
test application. But when I create an object from the service class,
the overloaded constructor is not accepted.
Any clue? Thanks a lot.

 

[Brock Allen]

Constructors are an aspect of object oriented programming environments. Web
services are not about objects. The fact that there's an object to host the
web service message handling should not taint your view of them -- it's just
an implementation detail. Web Services are about XML messages passed to an
endpoint that is going to do something with the message and perhaps hand
you a message back. Once you adjust your thinking to that model, then you'll
be in a better design position.

 

[alberto.decaro]

Thanks for your reply.
So the only way to set the service is to pass parameter to any
webmethod the service expose? :-(
Something like this:

[...]
Private Sub InitService(parTable as datatable)
'initialize private members
End Sub

<webMethod()> Public Function AnyMethod(parDs as dataset) as String
'initializing the service
InitService(parDs.tables("parameters"))

'webmethod implementation
'...

End Function
[...]

Still OO thinking!!

 

[Brock Allen]

So the idea of service oriented is that each invocation of an operation is
independant from another -- so no objects So if each invocation is independant,
then you'll have to pass whatever data for the operation to do its job.

Now, if you do want OO semantics, you should consider .NET Remoting. This
is a way to get distributed OO semantics.

Web Services is about distributed systems that interop with any technology
platform. .NET remoting is about distributed .NET to .NET communication.

 

[Dave Anderson]

Yes maybe in a better design position to think about Web Services. But this
is a major setback in terms of application and systems design. Web Services
take us back to functional programming days and for me that is pre 1981!

Do we really have to start from scratch with a textual definition of a
remote procedure call?

Dave
Smalltalker

Constructors are an aspect of object oriented programming environments.
Web services are not about objects. The fact that there's an object to
host the web service message handling should not taint your view of
them -- it's just an implementation detail. Web Services are about XML
messages passed to an endpoint that is going to do something with the
message and perhaps hand you a message back. Once you adjust your thinking
to that model, then you'll be in a better design position.

Hello everybody,
I'm developing a XML web service in VB, and I'd like to overload the
constructor to customize the service:
[...]
Private _tblParameters As datatable
'the default constructor
Public Sub New()
MyBase.New()
InitializeComponent()
End Sub
'the overloaded constructor
Public Sub New(parTable as datatable)
Me.New()
_tblParameters = parTable
End Sub
[...]

The project compiles correctly and I can add the web reference in the
test application. But when I create an object from the service class,
the overloaded constructor is not accepted.
Any clue? Thanks a lot.

 

[Brock Allen]

Do we really have to start from scratch with a textual definition of a

remote procedure call?

Well, think of it this way -- Web Services are about interop. This interop
is done with XML, SOAP, XSD, WSDL and a bunch of other specs... but these
I listed are the basic ones. So, those specs give us the ability to express
the coupling point for the applications. Thus, that's the contract. So what
we can do in web services is limited by what those specs allow us to do.
There is not always a one-to-one mapping from those specs to an OO programming
environment, like .NET.

Now, you don't have to work at the WSDL level (though some people think you
do to get it 100% correct, and there's *some* virtue to that), but as long
as you understand the underlying fundamentals, then you'll know what you
can and can't do in your toolkit (VS.NET WebServices). The toolkit hides
many of these realities and lets you do bad things. That's good that it hides
the details since that XML stuff can be hard and time consuming, but it's
bad that it lets you do bad/incorrect things.

So go ahead and use the toolkit, but don't forget that at the end of the
day what you're expressing with your toolkit must be legal and interoperable
with other programming environments (Java, Perl, whatever running on Mac,
Linux, whatever). The big no-no is thinking in terms of objects and passing
back .NET-specific types that have no meaning in other programming environments
(these two points are related).