axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <mark_whitl...@uk.ibm.com>
Subject Fw: C and C++ support
Date Thu, 30 Sep 2004 15:55:12 GMT




Hi,
I agree. Convert the engine to pure C++, fix memory leaks and remove C
support for 1.4 and in 1.5 put C support back in as a wrapper layer.

Before the C support gets disabled in 1.4, it would be good to understand
what the C support should look like in 1.5. We should support
generated C stubs, and C services. I think we should continue support the
"dynamic" client API, whereby applications can construct their own Call
object to invoke a service, without using generated stubs. I propose we
don't add in C support for handlers, unless anyone raises a requirement.

Most of this C support for the "dynamic" client API is currently in header
files, but that which is source files could be separated out into separate
source files so as to distinguish the C bindings from the engine. The C
bindings in the header files could be split out into separate header files,
.hpp files for C++ and .h files for C. So a C++ application would include
Call.hpp and a C application would include Call.h. But that would mean
all existing C++ applications changing. Also the C binding source files
could be linked into a separate dll/shared library. How far do people think
the C bindings should be separated out from the C++ engine?

Using this "dynamic" client API today from C is awkward since applications
would have write code such as ...

Call *pCall = (Call*)getStubObject(APTHTTP, uri);
pCall->_functions->setTransportProperty(pCall->_object, SOAPACTION_HEADER,
"Calculator#add");
pCall->_functions->setOperation(pCall->_object, "add",
"http://localhost/axis/Calculator);
pCall->_functions->addParameter(pCall->_object, &i1, "in0",XSD_INT);
pCall->_functions->addParameter(pCall->_object, &i2, "in1",XSD_INT);
pCall->_functions->invoke(pCall->_object);

which is the kind of code that wsdl2ws generates now. A more natural
programming model for C would be ...

Call *pCall = axiscGetStubObject(APTHTTP, uri);
axiscSetTransportProperty(pCall,SOAPACTION_HEADER, "Calculator#add");
axiscSetOperation(pCall, "add", "http://localhost/axis/Calculator);
axiscAddParameter(pCall, &i1, "in0",XSD_INT);
axiscAddParameter(pCall, &i2, "in1",XSD_INT);
axiscInvoke(pCall);

Wsdl2ws could generate C stubs on top of the "dynamic" client API C
bindings or it could generate a C binding on top of the
generated C++ stubs. Either way, currently the generated C stubs contain
functions called by the operation name. So the
Calculator sample generates a C function called int add(void* pStub, int
value0, int value1). Such functions could easily nameclash,
so I propose the generated C function names should be
<portname>_<operationname>. So the Calculator sample would
generate C functions like int Calculator_add(void* pStub, int value0, int
value1).

As an aside, I should investigate whether wsdl2ws uses the servicename or
the portname for the generated C++ class. I think
the portname should be used here since the soap:address is burnt into the
stub so the generated stub is port-specific not
service-specific.

It would be good to agree what direction we are going in with the C
bindings, before the existing C bindings get removed/disabled
for 1.4, since then we will know how much needs completely removing and
rewriting and how much could be disabled and
reenabled in 1.5.

Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 30/09/2004 15:41 -----
                                                                           
             John                                                          
             Hawkins/UK/IBM@IB                                             
             MGB                                                        To 
                                                                           
             30/09/2004 12:09                                           cc 
                                       axis-c-dev@ws.apache.org, Apache    
                                       AXIS C User List                    
             Please respond to         <axis-c-user@ws.apache.org>         
              "Apache AXIS C                                       Subject 
                User List"             Re: C and C++ support               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








Yep - we thought of that already :-)

We're going to set up some server tests to ensure that we don't screw it
up.


John Hawkins





             Samisa Abeysinghe
             <samisa_abeysingh
             e@yahoo.com>                                               To
                                       Apache AXIS C User List
             30/09/2004 11:10          <axis-c-user@ws.apache.org>,
                                       axis-c-dev@ws.apache.org
                                                                        cc
             Please respond to
              "Apache AXIS C                                       Subject
             Developers List"          Re: C and C++ support










Hi All,
   One of the possible problems of converting the engine to pure C++ is
that, one would have to
keep an eye on both the client side as well as the server side, while the
refactoring is going on.
So it would be necessary to have both client side as well as server side
test cases in place
before we start on this task. (a typical refactoring scenario) I think we
can manage with whatever
tests we have at the moment.
   As long as we keep on testing client and server in parallel, we would be
able to achieve
success with this task.

Thanks,
Samisa...

--- John Hawkins <HAWKINSJ@uk.ibm.com> wrote:

>
>
>
>
> Hi Folks,
>
> Throughout the last year we have come across many problems related to our
> continued commitment to supporting both C and C++ stubs. The design of
the
> engine code has been greatly affected by this and has caused quite a few
> problems particularly with regard to memory management. Please see here
> http://marc.theaimsgroup.com/?l=axis-c-dev&m=109461822722177&w=2 and here
> http://nagoya.apache.org/jira/browse/AXISCPP-149 for some of the issues
we
> have recently uncovered.
>
> The reasoning behind supporting C is clear - to support legacy
> applications. We have had the debate about using C internally for
> performance reasons and I think we have concluded that we need to get the
> code stable and then consider performance. The intermingling of C and C++
> in the core code has created more problems than it would appear to have
> solved (Current performance charts show azis C looking very bad).
>
> In order to improve and stabilise the code I would like to propose that
we
> remove C structures, memory allocation etc. such that we have a 100% C++
> engine. If we did this we can then enhance WSDL2WS such that it creates C
> wrappers for the pure C++ code. There is, in my opinion,  no question
that
> this will improve the quality of the code - particularly memory
management.
>
> If this is agreed upon then I would like to propose that we take a two
> staged approach in the management of this change. I would like us to
> withdraw C support for the NEXT RELEASE ONLY (1.4). In 1.4 we can work on
> making the engine 100% C++. I would then like us to reintroduce the C
> support in the post 1.4 timeframe (1.5) by making the changes to WSDL2WS.
>
> This approach enables us to concentrate on improving the core engine code
> in the first instance without worrying about updating the C support in
> WSDL2WS - code that will get changed in the next release. Once we have
> proven that we have a stable 100% C++ engine we can then concentrate
> entirely on C support - i.e. by producing the nicely encapsulated
> wrappering layer.
>
>
> I hope that we, as a community, can work through this problem quickly so
> that we can make the core code more stable and C support of a much higher
> quality. I look forward to your responses.
>
> (This is copied to both the dev and user community for response.)
>
>
> John.
>
>
>
>
> John Hawkins
>
>
>
>




_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com




Mime
View raw message