Re: design question

2003-06-20 Thread Scott Nichol
> Thanks Simon. If interoperability is still an issue, I think that Web Service isn't > yet ready for enterprise-class deployment. The promise and power it brings would > fall apart.. TCP/IP has been around for, what, more than 3 decades, and there have been interop quirks as recent as a year a

Re: design question

2003-06-20 Thread Vishal Shah
Thanks Simon. If interoperability is still an issue, I think that Web Service isn't yet ready for enterprise-class deployment. The promise and power it brings would fall apart..   Simon Fell <[EMAIL PROTECTED]> wrote: different tools support different parts of the XSD spec, so yougenerate your WSDL

Re: design question

2003-06-20 Thread Anne Thomas Manes
than MS SOAP Toolkit.   Anne - Original Message - From: Vishal Shah To: [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 7:49 PM Subject: Re: design question Thanks Anne.. My original service was of an RPC/Literal style (it returned a DOM element) and worked f

Re: design question

2003-06-19 Thread Simon Fell
different tools support different parts of the XSD spec, so you generate your WSDL with tool A, but tool B can't process it. Typical sticking points include choice, derivation by restriction, model groups. In addition many tools still generate invalid schemas, lack of required import statements whe

Re: design question

2003-06-19 Thread Vishal Shah
Thanks Anne.. My original service was of an RPC/Literal style (it returned a DOM element) and worked fine within Java environment...Then came a requirement to consume it from a VB 6 client and all sort of interoperability issues started cropping up... Since, I'm stuck with infrastructure limitation

Re: design question

2003-06-19 Thread Vishal Shah
Simon,   What kind of practical problems with doc/lit are there ? I would like to know..   thanks Simon Fell <[EMAIL PROTECTED]> wrote: On Wed, 18 Jun 2003 23:17:24 -0400, in soap you wrote:>Doc/lit doesn't define type mappings, but it definitively specifies the>structure of the message via XML Sch

Re: design question

2003-06-19 Thread ymchatty
That was the problem. I restarted my web & appservers and it worked.   So these freshly deployed soap services are no specail than usual modules deployed under iplanet. They get cached.   Thanks for the suggestion again.   Scott Nichol <[EMAIL PROTECTED]> wrote: Are you sure that the service code

Re: design question

2003-06-19 Thread Scott Nichol
Are you sure that the service code you show below corresponds to the class being loaded on the server? Did you have a previous version that you copied over? If so, did you restart the webapp or servlet container? On 19 Jun 2003 at 12:19, ymchatty wrote: > > Here is the client code that sets

RE: design question

2003-06-19 Thread Wei Li
I saw that your Qname is different than your TargetObjectUrl, could that be the reason?   -- wei -Original Message-From: ymchatty [mailto:[EMAIL PROTECTED]Sent: Thursday, June 19, 2003 3:19 PMTo: [EMAIL PROTECTED]Subject: Re: design question Here is the client code that

Re: design question

2003-06-19 Thread ymchatty
Here is the client code that sets the params --    params.addElement(new Parameter("nameToLookup", String.class,   nameToLookup, null));   call.setParams(params);    // Invoke the call.   Response resp;    try   {re

Re: design question

2003-06-19 Thread Scott Nichol
; WSDL messages differently. (With RPC style you must define your s > using the type= attribute, while Document style requires the element= > attribute.) This situation reduces the reusability of a . > > Anne > > - Original Message - > From: "Scott Nichol" &l

Re: design question

2003-06-19 Thread Scott Nichol
What is your client code that creates the Vector of parameters? From the exception, it looks as though the Vector has a single parameter of type String. The service class, however, does not have a sayHello method that takes a string. Given that you are providing a mapping for the Hello class

Re: design question

2003-06-19 Thread ymchatty
I am getting the following exception, as I verified that I specified the correct method name and type in both the client program and as well in the descriptor. Pls let me know what I am missing. Here is the client code: --    // Map the types.   smr.mapTypes(

Re: design question

2003-06-19 Thread Vishal Shah
e, while Document style requires the element=attribute.) This situation reduces the reusability of a .Anne- Original Message -From: "Scott Nichol" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Thursday, June 19, 2003 12:32 PMSubject: Re: design question> Are you t

Re: design question

2003-06-19 Thread Anne Thomas Manes
- From: "Scott Nichol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 12:32 PM Subject: Re: design question > Are you talking about rpc/encoded messages in the absence of WSDL? > If there is WSDL for the service, are there still ambiguities? My

Re: design question

2003-06-19 Thread Scott Nichol
> Perhaps -- but with SOAP Section 5 we encountered interoperability issues > with types as simple as booleans. I know at least one implementation that does not handle booleans well, NuSOAP. And guess what: it still has problems with booleans using doc/lit. It was not Section 5 that caused the

Re: design question

2003-06-19 Thread Scott Nichol
uot;Scott Nichol" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 18, 2003 3:18 PM > Subject: Re: design question > > > > In what way does doc/lit define language type mappings? I've never > > really understood why doc/lit is

Re: design question

2003-06-19 Thread Anne Thomas Manes
h doc/literal unless we use some of the more advanced constructs, such as groups. Anne - Original Message - From: "Simon Fell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 1:22 AM Subject: Re: design question On Wed, 18 Jun 2003 23:17:

Re: design question

2003-06-18 Thread Simon Fell
On Wed, 18 Jun 2003 23:17:24 -0400, in soap you wrote: >Doc/lit doesn't define type mappings, but it definitively specifies the >structure of the message via XML Schema. Because the two applications know >in advance exactly what the message structure is, the details of how the >SOAP message proces

Re: design question

2003-06-18 Thread Anne Thomas Manes
the SOAP platform in your WAS 403 system. I'm pretty sure that GLUE can run in WAS 403. Anne - Original Message - From: Vishal Shah To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 3:01 PM Subject: Re: design question Pl see my response below.. Anne Thomas Manes <[EMAIL PROT

Re: design question

2003-06-18 Thread Anne Thomas Manes
of the message. The interoperability issues arise when two different SOAP message procesors interpret SOAP Section 5 slightly differently. Anne - Original Message - From: "Scott Nichol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 18, 2003 3:18 PM Subject

Re: design question

2003-06-18 Thread Scott Nichol
One more comment. I consider it out of the ordinary for the code implementing a service method to manipulate XML in any way. As such, your method that returns a DOM element seems quite odd to me. One typically uses constructs more native to the implementation language, such as a class instan

Re: design question

2003-06-18 Thread Scott Nichol
validation (sometimes just by declaring a deployment option). > > Anne > - Original Message - > From: Vishal Shah > To: [EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 10:58 AM > Subject: Re: design question > > > Thanks Anne for elucidating. I

Re: design question

2003-06-18 Thread Scott Nichol
> I don't concur with you on thing you mentioned below in the first paragraph. If you > factor interoperability & infrastructure issues in, your design would be definitely > affected accordingly. If your service is going to be consumed by a VB6 client or > .net client (or any non-java consumer)

Re: design question

2003-06-18 Thread Vishal Shah
iginal Message - From: Vishal Shah To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:58 AM Subject: Re: design question Thanks Anne for elucidating. I'm stuck with the legacy system and infrastructure that supports it.. I need to find a clumsy way to get around to make things wor

Re: design question

2003-06-18 Thread Anne Thomas Manes
ke it simple to request validation (sometimes just by declaring a deployment option).   Anne - Original Message - From: Vishal Shah To: [EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:58 AM Subject: Re: design question Thanks Anne for elucidating. I

Re: design question

2003-06-18 Thread Vishal Shah
Thanks Anne for elucidating. I'm stuck with the legacy system and infrastructure that supports it.. I need to find a clumsy way to get around to make things work..   I don't concur with you on thing you mentioned below in the first paragraph. If you factor interoperability & infrastructure issues

Re: design question

2003-06-17 Thread Anne Thomas Manes
Vishal,   A SOAP runtime system should provide a layer of abstraction between your message format and the application that implements the service. Hence the format of the message (Doc/literal vs RPC/encoded) shouldn't really impact the design of your service. The SOAP runtime system should be

Re: design question

2003-06-17 Thread Vishal Shah
Thanks Scott. Do you happen to have a code snippet that uses a validating parser to parse and validate a document pulled out from a SOAP body ? I don't want to interrogate body entries vector, get each element pulled out from the vector and then perform coarse-grained validation...   VSScott Nichol

Re: design question

2003-06-17 Thread Scott Nichol
Always report exceptions using the SOAP Fault mechanism. Whether the document is validated against a schema is up to you. There is no requirement that this be done. On 17 Jun 2003 at 7:59, Vishal Shah wrote: > Hi, > > I've a couple of design questions...I've a Doc/literal style service.. >