axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject IGNORE Previous SOAP question
Date Thu, 07 Oct 2004 10:57:32 GMT




Please Ignore that I've just found the documentation !

John Hawkins




                                                                           
             John                                                          
             Hawkins/UK/IBM@IB                                             
             MGB                                                        To 
                                       axis-c-dev@ws.apache.org            
             07/10/2004 11:52                                           cc 
                                                                           
                                                                   Subject 
             Please respond to         Re: Fw: Re:failure notice           
              "Apache AXIS C                                               
             Developers List"                                              
                                                                           
                                                                           
                                                                           
                                                                           








I've been looking into faultcodes in quite some detail due to these notes
and I need to know what SOAP level we are supporting before I comment on
the note from Damitha,
So, do we support both 1.1 and 1.2?


John Hawkins





             damitha kumarage
             <damitha@opensour
             ce.lk>                                                     To
                                       Apache AXIS C User List
             05/10/2004 10:52          <axis-c-user@ws.apache.org>
                                                                        cc

             Please respond to                                     Subject
              "Apache AXIS C           Re: Fw: Re:failure notice
                User List"









Hi,
Since now we are going to make axis engine more of c++ I suggest
following fault handling.

Derive all complex faults defined in wsdl from a base type. Say
AxisFault.
This base type has methods to serialize, deserialize.

When engine identify that the message in the wire is soap fault
1) If that fault is not a service generated one(generated by
   the axis engine itself) then it throw a FaultException which
   has accessors for fault code, fault string, fault actor and
   fault detail which is a simple string in this case.

2) If that fault is service generated one it throw a
   FaultException which  has accessors for fault code, fault string,
   fault actor but fault detail empty. Since the knowledge to
deserializing
   the complex fault detail is with the wsdl generated types which is
   with the client, when we receive the FaultException the
   fault detail is null. Client need to get the fault detail name
   and then create the corresponding fault detail.
   Following snippets will explain further.


    In the deserializer
...
    FaultException* pFaultExceptin = new FaultException(this);//Pass
this deserializer into constructor
    pFaultException->setFaultCode(faultcode);
    pFaultException->setFaultString(faultcode);
    pFaultException->setFaultActor(faultcode);
    pcDetail = getElementAsString("detail", 0);
    if(pcDetail)
        pFaultException->setFaultDetail(pcDetail);
    throw pFaultException;
...

Now In client code
...
   catch(FaultException& e)
   {
       String sFaultCode = e.getFaultCode();
       String sFaultString = e.getFaultString();
       String sFaultActor = e.getFaultActor();
       String sFaultDetail = e.getFaultDetail();
       if(0 == sFaultDetail.length())//The fault is a service thrown one
       {
           if(e.getDetailName().compare("DivByZeroType"))
           {
               DivByZeroType* pDivByZero = new DivByZeroType();
               sFaultDetail = e.getFaultDetail(pDivByZero);
           }
       }
    }
...

  So in FaultException we have a method
...
  String getFaultDetail(BaseFaultType* faultType)
  {
     return pDZ->getFaultDetail(faultType);
  }
...
  So in SoapDeserializer we have
...
  String getFaultDetail(BaseFaultType* faultType)
  {
      return faultType->deserialize();
  }
...

I think this approach is simple. What do you think?
On Fri, 2004-10-01 at 18:41, John Hawkins wrote:

thanks
damitha
>
>
> >From Fred preston ->
>
>
>
>
>
> Hi Adrian.
>       I've started looking at the fault object model and it is in a bit
of
> a mess.  Currently, faults come back as exceptions from the stub as a
> <ServiceName>_AxisClientException.  The actual exception is wrapped
inside
> the exception object.  You then have to unwrap the exception to find what
> the real exception was. i.e.
>
> catch( ServiceName_AxisClientException e)
> {
>   ISoapFault * pFault = (ISoapFault *) e.getFault(); // NB: You will
> probably need
>                                                      // to download
latest
> axis code
>                                                      // to get this
method.
>   string       faultDetail = pFault->getSimpleFaultDetail();
>   string       faultClassName = "<none>";
>   int          iExceptionCode = e.getExceptionCode();
>   string       sExceptionString = e.getMessage( iExceptionCode);
>
>   if( faultDetail.length() == 0)
>   {
>     if( !pFault->getCmplxFaultObjectName().compare( "ExceptionName"))
>     {
>       faultClassName = pFault->getCmplxFaultObjectName();
>
>       ExceptionNameType* pENT = (ExceptionNameType*)
> pFault->getCmplxFaultObject();
>
>       if( pENT)
>       {
>         faultDetail = pENT->....;
>       }
>       else
>       {
>         faultDetail = "Unknown type:" + faultClassName;
>       }
>     }
>   }
> }
>
> What I'm proposing is that we have the following model
>
>                +---------------------+
>                | AxisClientException |
>                +---------------------+
>                   |               |
> +-----------------------+   +----------------+
> | ServiceName_Exception |   | FaultException |
> +-----------------------+   +----------------+
>
> Where you can catch either a Fault or Service exception directly or catch
> the generic AxisClientException and then unwrap.  This removes the need
for
> catching the generic exception (and then unwrapping) if you know what
> faults to expect.  A fault exception is identical to the fault reply in
the
> WSDL and a ServiceName_Exeception is only ever used for a system fault
(for
> example, if there is a connection problem).    An example of a fault
> exception is shown below:-
>
> If you have the following WSDL...
>
> Service            Binding           Port Type       Message       Name
> Type
>
------------------+-----------------+---------------+-------------+----------+-------------------------------


>
> myTestServ ------> myTestBind        myTestPT
>                      mTest             mTest
>                      i: -------------> i: ---------> myTestIn      mIn
> xsd:string
>                      o: -------------> o: ---------> myTestOut     mOut
> xsd:int
>                      f: -------------> f: ---------> myTestFault   mFault
> {Info xsd:string, Code xsd:int}
>
> Then the client will be coded as follows:-
>
> try
> {
>   myTestServ * myService = new myTestServ( "someUri");
>
>   string text = "Hello";
>
>   int iRetValue = myService->mTest( text);
>
>   cout << text << " has " << iRetValue << " e's" << endl;
> }
> catch( myTestFaultType f)
> {
>   cout << "Error info " << f.Info << endl;
>   cout << "Error code " << f.Code << endl;
> }
>
> Thus the client now catches the exception type as described in the WSDL.
>
> If the client application uses more than one service or method within a
> service then the calls may have to be separated by individual try catch
> blocks (depending on the uniqueness of the expected exceptions) to ensure
> that the code knows where or when an exception occurred.
>
> Does anyone have any comments on this proposed update?
>
> Regards,
>
> Fred Preston.
>
>
>              <adrian.p.smith@b
>              t.com>
>
To
>              30/09/2004 13:48          <axis-c-user@ws.apache.org>
>
cc
>
>              Please respond to
Subject
>               "Apache AXIS C           RE: failure notice
>                 User List"
>
>
>
>
>
>
>
>
>
> Better SOAP:Fault handling - i.e. be able to access the fields within the
> SOAP:Fault from a client.
>
>
>
> -----Original Message-----
> From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> Sent: 30 September 2004 13:34
> To: axis-c-user@ws.apache.org
> Subject: Re: failure notice
>
>
>
>
>
>
> Hi Folks,
>
> Big note coming up !
>
> I would like to propose some features that we should put into 1.4. I
would
> like to know what everyone is thinking is useful to have in the 1.4
release
> and this small list should act as a starter.
>
>
>
> C support -
>       firstly define feasibility of making a 100% C++ engine and design,
> then (if feasible) implement.
>       We will temporarily remove C support in 1.4 to be replaced in 1.5
> with new wrapper.
>
> Apache Builds -
>       This item is all about getting a daily build. We must also create
all
> the relevant web pages so it's usable.
>       We will build the client first then the server.
>
> Refactor WSDL2WS -
>       As it says ! This is a pretty much open-ended item so we do as much
> as we can. Remember - at this point we have no C support so anything we
can
> do here to make that easier to reimplement C in 1.5 is good !
>
> Test documentation -
>       document the handler mechanism and other test related stuff we
have.
>
>
> AND - A Quick overview of 1.5 work
> 1.5
> C support -
>       put back into WSDL2 WS C wrappers for the new 100% C++ engine
>
> Purify and fix -
>       As it says - run Rational purify and tackle issues that come out of
> it.
>
> Improve HTTP Support.
>       Fix outstanding issues with HTTP support in the new transport
layer.
> There is a lot we can do here and we haven't really defined what it
highest
> priority.
>
> Documentation
>       User documentation and CVS based documentation. including sample
can
> be improved
>
>
>
> With the resource that we have here - we can contain all the above 1.4
> items within a 24th November Time-schedule. I would like to propose that
we
> try to maintain this shorter time-line for releases. That way we keep new
> function to a minimum and therefore maintain stability within builds.
>
> I would also like to propose that we move away from our current waterfall
> model of code then test. When we have daily builds we can see immediately
> what has broken and this will help us tremedously. The more we automate
our
> testing the better. The one issue with this is that the daily builds will
> only cover certain compilation options (as discussed in previous mails).
> The test-cycle now appears to consist of running the same tests on
> different configurations - is this true? In which case I would ask that
> someone find the time to automate those configurations and run them daily
> as well?
>
> Please can you feedback your thoughts and ideas on what we should put
into
> 1.4 and what you would like to see in 1.4 We can then make a judgement as
> to what the final goal is to be.
>
>
> many thanks,
> John.
>
>
>






Mime
View raw message