By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,218 Members | 1,194 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,218 IT Pros & Developers. It's quick & easy.

calling a dot net web services from unix

P: n/a
Stu
Hi,

I have a web service which returns a record set and works well integrated
with an asp dot net page.
However if I decided to develop a unix app
will i be able to read the dataset as it is
or do i need to write the xml as text from the web service and supply a DTD.
Also any other pitfalls

TIA

Stu
Nov 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Dataset will always pose major problems with interoperablity because
difgramm is unique to .Net framework only. If you cannot do anything to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your dataset
contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when designing a
web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:
Hi,

I have a web service which returns a record set and works well integrated
with an asp dot net page.
However if I decided to develop a unix app
will i be able to read the dataset as it is
or do i need to write the xml as text from the web service and supply a DTD.
Also any other pitfalls

TIA

Stu

Nov 23 '05 #2

P: n/a
I agree that a DataSet is problematic for interoperability. Instead return an
XmlElement. Just use the DataSet WriteXml method to a write the DataSet out
to a stream and get the root element.

Of course, if the DataSet has changed, be sure to call AcceptChanges first.

Chris Rolon

"erymuzuan" wrote:
Dataset will always pose major problems with interoperablity because
difgramm is unique to .Net framework only. If you cannot do anything to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your dataset
contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when designing a
web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:
Hi,

I have a web service which returns a record set and works well integrated
with an asp dot net page.
However if I decided to develop a unix app
will i be able to read the dataset as it is
or do i need to write the xml as text from the web service and supply a DTD.
Also any other pitfalls

TIA

Stu

Nov 23 '05 #3

P: n/a
Erymuzuan's approach allows much better control over the XML
serialization format of the data. Since the original post was about
interoperating with a different platform, that level of control may be
crucial to getting the web services to talk to each other. A DataSet
expressed in XML is still a DataSet ;)

You also already hint on another issue. The DataSet offers a very
convenient programming model that doesn't jive well with
interoperability. You will have to write to code anyway to make that
programming model work for externally exposed Web services. Programming
against serialized objects will also help gearing the code inside the
service more towards interoperability.

Just my toughts.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko
-----Original Message-----
From: Chris Rolon [mailto:Ch********@discussions.microsoft.com]
Posted At: Sunday, January 23, 2005 9:51 AM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

I agree that a DataSet is problematic for interoperability. Instead return an
XmlElement. Just use the DataSet WriteXml method to a write the DataSet out
to a stream and get the root element.

Of course, if the DataSet has changed, be sure to call AcceptChanges
first.

Chris Rolon

"erymuzuan" wrote:
Dataset will always pose major problems with interoperablity because
difgramm is unique to .Net framework only. If you cannot do anything to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your dataset contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when designing a web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:
Hi,

I have a web service which returns a record set and works well
integrated with an asp dot net page.
However if I decided to develop a unix app
will i be able to read the dataset as it is
or do i need to write the xml as text from the web service and
supply a DTD. Also any other pitfalls

TIA

Stu


Nov 23 '05 #4

P: n/a
This sort of problem posted again and again in this newsgroup simply
because some of us thinks that Web Services is just a method with
WebMethod attribute, rather that a set of messages in a document based
mesaging platform. even a simple web method like this can cause
interoperablity problem

[WebMethod]
public Employee[] GetEmployee()
{
Employee[] emps = new Employee[10];
return emps;
}

I think Microsoft is part to blame for making developers thinking that's
how to write web services. everytime you create a new asmx in VS.Net in
give the HelloWord

// WEB SERVICE EXAMPLE
// The HelloWorld() example service returns the string Hello World
// To build, uncomment the following lines then save and build the project
// To test this web service, press F5

// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }

Using tools like XmlSpy (my favorite) or CapeClear WSDL editor certainly
helps to make a better interoperable web services. Christian Weyer's
contract-first tool for web services is a great tool to achieve this as
well, thou' i have it installed never really touch it. One of this
should be the first tool every web service developer should have in
their toolbox after the HelloWorld introduction

regards
erymuzuan
Christoph Schittko [MVP] wrote:
Erymuzuan's approach allows much better control over the XML
serialization format of the data. Since the original post was about
interoperating with a different platform, that level of control may be
crucial to getting the web services to talk to each other. A DataSet
expressed in XML is still a DataSet ;)

You also already hint on another issue. The DataSet offers a very
convenient programming model that doesn't jive well with
interoperability. You will have to write to code anyway to make that
programming model work for externally exposed Web services. Programming
against serialized objects will also help gearing the code inside the
service more towards interoperability.

Just my toughts.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: Chris Rolon [mailto:Ch********@discussions.microsoft.com]
Posted At: Sunday, January 23, 2005 9:51 AM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

I agree that a DataSet is problematic for interoperability. Instead


return
an
XmlElement. Just use the DataSet WriteXml method to a write the


DataSet
out
to a stream and get the root element.

Of course, if the DataSet has changed, be sure to call AcceptChanges
first.

Chris Rolon

"erymuzuan" wrote:

Dataset will always pose major problems with interoperablity because
difgramm is unique to .Net framework only. If you cannot do anything
to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your
dataset
contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when designing
a
web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:

Hi,

I have a web service which returns a record set and works well


integrated
with an asp dot net page.
However if I decided to develop a unix app
will i be able to read the dataset as it is
or do i need to write the xml as text from the web service and


supply
a DTD.
Also any other pitfalls

TIA

Stu

Nov 23 '05 #5

P: n/a
Stu
Thanks for all your response on this
I like the dataset model cuase its very quick and convenient.

So ill probably end up putting some method overrides so u can choose dataset
or xml

Stu

"erymuzuan" wrote:
This sort of problem posted again and again in this newsgroup simply
because some of us thinks that Web Services is just a method with
WebMethod attribute, rather that a set of messages in a document based
mesaging platform. even a simple web method like this can cause
interoperablity problem

[WebMethod]
public Employee[] GetEmployee()
{
Employee[] emps = new Employee[10];
return emps;
}

I think Microsoft is part to blame for making developers thinking that's
how to write web services. everytime you create a new asmx in VS.Net in
give the HelloWord

// WEB SERVICE EXAMPLE
// The HelloWorld() example service returns the string Hello World
// To build, uncomment the following lines then save and build the project
// To test this web service, press F5

// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }

Using tools like XmlSpy (my favorite) or CapeClear WSDL editor certainly
helps to make a better interoperable web services. Christian Weyer's
contract-first tool for web services is a great tool to achieve this as
well, thou' i have it installed never really touch it. One of this
should be the first tool every web service developer should have in
their toolbox after the HelloWorld introduction

regards
erymuzuan
Christoph Schittko [MVP] wrote:
Erymuzuan's approach allows much better control over the XML
serialization format of the data. Since the original post was about
interoperating with a different platform, that level of control may be
crucial to getting the web services to talk to each other. A DataSet
expressed in XML is still a DataSet ;)

You also already hint on another issue. The DataSet offers a very
convenient programming model that doesn't jive well with
interoperability. You will have to write to code anyway to make that
programming model work for externally exposed Web services. Programming
against serialized objects will also help gearing the code inside the
service more towards interoperability.

Just my toughts.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: Chris Rolon [mailto:Ch********@discussions.microsoft.com]
Posted At: Sunday, January 23, 2005 9:51 AM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

I agree that a DataSet is problematic for interoperability. Instead


return
an
XmlElement. Just use the DataSet WriteXml method to a write the


DataSet
out
to a stream and get the root element.

Of course, if the DataSet has changed, be sure to call AcceptChanges
first.

Chris Rolon

"erymuzuan" wrote:
Dataset will always pose major problems with interoperablity because
difgramm is unique to .Net framework only. If you cannot do anything


to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your


dataset
contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when designing


a
web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:

>Hi,
>
>I have a web service which returns a record set and works well

integrated

>with an asp dot net page.
>However if I decided to develop a unix app
>will i be able to read the dataset as it is
>or do i need to write the xml as text from the web service and


supply
a DTD.

>Also any other pitfalls
>
>TIA
>
>Stu

Nov 23 '05 #6

P: n/a
I agree with all of that ;)

Glad to hear you like wscf. Have you taken a look at release 0.4
(released last December) with the new WSDL wizard? We'd love to hear
what you think.

Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: erymuzuan [mailto:er*******@yahoo.com]
Posted At: Sunday, January 23, 2005 6:22 PM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

This sort of problem posted again and again in this newsgroup simply
because some of us thinks that Web Services is just a method with
WebMethod attribute, rather that a set of messages in a document based
mesaging platform. even a simple web method like this can cause
interoperablity problem

[WebMethod]
public Employee[] GetEmployee()
{
Employee[] emps = new Employee[10];
return emps;
}

I think Microsoft is part to blame for making developers thinking that's how to write web services. everytime you create a new asmx in VS.Net in give the HelloWord

// WEB SERVICE EXAMPLE
// The HelloWorld() example service returns the string Hello World
// To build, uncomment the following lines then save and build the project // To test this web service, press F5

// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }

Using tools like XmlSpy (my favorite) or CapeClear WSDL editor certainly helps to make a better interoperable web services. Christian Weyer's
contract-first tool for web services is a great tool to achieve this as well, thou' i have it installed never really touch it. One of this
should be the first tool every web service developer should have in
their toolbox after the HelloWorld introduction

regards
erymuzuan
Christoph Schittko [MVP] wrote:
Erymuzuan's approach allows much better control over the XML
serialization format of the data. Since the original post was about
interoperating with a different platform, that level of control may be crucial to getting the web services to talk to each other. A DataSet
expressed in XML is still a DataSet ;)

You also already hint on another issue. The DataSet offers a very
convenient programming model that doesn't jive well with
interoperability. You will have to write to code anyway to make that
programming model work for externally exposed Web services. Programming against serialized objects will also help gearing the code inside the service more towards interoperability.

Just my toughts.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: Chris Rolon [mailto:Ch********@discussions.microsoft.com]
Posted At: Sunday, January 23, 2005 9:51 AM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

I agree that a DataSet is problematic for interoperability. Instead


return
an
XmlElement. Just use the DataSet WriteXml method to a write the


DataSet
out
to a stream and get the root element.

Of course, if the DataSet has changed, be sure to call AcceptChanges
first.

Chris Rolon

"erymuzuan" wrote:
Dataset will always pose major problems with interoperablity becausedifgramm is unique to .Net framework only. If you cannot do
anything
to
change the web services, then you'll have to process the dataset as
XmlDocument on other platforms. and this could be tricky if your


dataset
contains lot of diffgram information.

The best way is avoid dataset, try to think in schema when
designing
a
web services. all you have to do is create a schema first then use
xsd.exe to generate .net code that can be used in web services.

regards
erymuzuan

Stu wrote:

>Hi,
>
>I have a web service which returns a record set and works well

integrated

>with an asp dot net page.
>However if I decided to develop a unix app
>will i be able to read the dataset as it is
>or do i need to write the xml as text from the web service and


supply
a DTD.

>Also any other pitfalls
>
>TIA
>
>Stu


Nov 23 '05 #7

P: n/a
Stu
One final question
Forgive my ignorance on the Unix Side of but if i have an ms web service say
function xyz(a,b,c,d) will they be able to use the proxy and call the web
service or do I need to process xml soap streams ?
Any good resources for dev MS web services for unix
"Christoph Schittko [MVP]" wrote:
I agree with all of that ;)

Glad to hear you like wscf. Have you taken a look at release 0.4
(released last December) with the new WSDL wizard? We'd love to hear
what you think.

Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

-----Original Message-----
From: erymuzuan [mailto:er*******@yahoo.com]
Posted At: Sunday, January 23, 2005 6:22 PM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: calling a dot net web services from unix
Subject: Re: calling a dot net web services from unix

This sort of problem posted again and again in this newsgroup simply
because some of us thinks that Web Services is just a method with
WebMethod attribute, rather that a set of messages in a document based
mesaging platform. even a simple web method like this can cause
interoperablity problem

[WebMethod]
public Employee[] GetEmployee()
{
Employee[] emps = new Employee[10];
return emps;
}

I think Microsoft is part to blame for making developers thinking

that's
how to write web services. everytime you create a new asmx in VS.Net

in
give the HelloWord

// WEB SERVICE EXAMPLE
// The HelloWorld() example service returns the string Hello World
// To build, uncomment the following lines then save and build the

project
// To test this web service, press F5

// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }

Using tools like XmlSpy (my favorite) or CapeClear WSDL editor

certainly
helps to make a better interoperable web services. Christian Weyer's
contract-first tool for web services is a great tool to achieve this

as
well, thou' i have it installed never really touch it. One of this
should be the first tool every web service developer should have in
their toolbox after the HelloWorld introduction

regards
erymuzuan
Christoph Schittko [MVP] wrote:
Erymuzuan's approach allows much better control over the XML
serialization format of the data. Since the original post was about
interoperating with a different platform, that level of control may be crucial to getting the web services to talk to each other. A DataSet
expressed in XML is still a DataSet ;)

You also already hint on another issue. The DataSet offers a very
convenient programming model that doesn't jive well with
interoperability. You will have to write to code anyway to make that
programming model work for externally exposed Web services. Programming against serialized objects will also help gearing the code inside the service more towards interoperability.

Just my toughts.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko


>-----Original Message-----
>From: Chris Rolon [mailto:Ch********@discussions.microsoft.com]
>Posted At: Sunday, January 23, 2005 9:51 AM
>Posted To: microsoft.public.dotnet.framework.webservices
>Conversation: calling a dot net web services from unix
>Subject: Re: calling a dot net web services from unix
>
>I agree that a DataSet is problematic for interoperability. Instead

return

>an
>XmlElement. Just use the DataSet WriteXml method to a write the

DataSet

>out
>to a stream and get the root element.
>
>Of course, if the DataSet has changed, be sure to call AcceptChanges
>first.
>
>Chris Rolon
>
>"erymuzuan" wrote:
>
>
>>Dataset will always pose major problems with interoperablity because>>difgramm is unique to .Net framework only. If you cannot do anything
to

>>change the web services, then you'll have to process the dataset as
>>XmlDocument on other platforms. and this could be tricky if your

dataset

>>contains lot of diffgram information.
>>
>>The best way is avoid dataset, try to think in schema when designing
a

>>web services. all you have to do is create a schema first then use
>>xsd.exe to generate .net code that can be used in web services.
>>
>>regards
>>erymuzuan
>>
>>Stu wrote:
>>
>>>Hi,
>>>
>>>I have a web service which returns a record set and works well
>
>integrated
>
>>>with an asp dot net page.
>>>However if I decided to develop a unix app
>>>will i be able to read the dataset as it is
>>>or do i need to write the xml as text from the web service and

supply

>a DTD.
>
>>>Also any other pitfalls
>>>
>>>TIA
>>>
>>>Stu
>>


Nov 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.