Harbour evolution and WebServices.
marek.h...@interia.pl
Harbour is a good tool for writing server applications.
One of the technologies used on the server side are WebServices.
I believe that such technology in the Harbour should be developed or adapted.
Question to the knowledgeable licensed, whether the product gSOAP whose license is:
http://www.cs.fsu.edu/~engelen/soap.html
suitable for adopting the Harbor (like eg OCILIB or CAIRO), notwithstanding the licensing terms?
Does anyone know this product or carers about him?
(sorry for my "google" english)
Regards,
Marek Horodyski
----------------------------------------------------------------
Znajdz samochod idealny dla siebie!
Szukaj >> http://linkint.pl/f29e2
Massimo Belgrano
Hello.
Harbour is a good tool for writing server applications.
One of the technologies used on the server side are WebServices.
(sorry for my "google" english)
Regards,
Marek Horodyski
----------------------------------------------------------------
Znajdz samochod idealny dla siebie!
Szukaj >> http://linkint.pl/f29e2
--
Massimo Belgrano
Mel_the_Snowbird
All three of my web site servers are written *purely* in
xHarbour.
I've been thinking of changing them to Harbour, but the foot print
of the Harbour executable is almost twice as big as the xHarbour
version.
On Jul 25, 7:03 am, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Hi Marek
>
> 2011/7/25 <marek.horody...@interia.pl>
> > Hello.
> > Harbour is a good tool for writing server applications.
> > One of the technologies used on the server side are WebServices.
>
Mel_the_Snowbird
On Jul 25, 9:44 am, Mel_the_Snowbird <medsyn...@aol.com> wrote:
> Marek & Massimo:
>
> All three of my web site servers are written *purely* in
> xHarbour.
>
> I've been thinking of changing them to Harbour, but the foot print
> of the Harbour executable is almost twice as big as the xHarbour
> version.
'Send' Button. Its hard to break the habit.
Anyway, because I may have 50 simultaneous visitors, and my server
only has 2 gig of memory, I have to be a 'bit' careful of the server
executable size.
BUT, I'd like to re-compile my www.whosaway.com web server in
Harbour and get a comparably-sized executable that is just as fast or
faster than my xHarbour versions. Perhaps I'll try again ...
About a month ago, Victor (and Przemek) tried to help me in this
task, but I failed :((
So, I use *only* the Harbour language in implementing my Apache
Server CGI. Everyone who comes to my site gets a page sent to them
that is built, filled-in, copied, etc, etc by the exe. Client input
is received by my CGI exe, and is parsed, chewed on, databases
examined,, pages built, etc, and the result is sent back by the CGI
app to my Apache Server and then back to the client. I also use
XmlHttpRequests for quick response tasks on another of my sites
(usually < 1 second for a reponse including a local Comix database
look up).
Finally, I know nothing of PHP or Perl, etc, and rely only on the
Harbour language for CGI apps.
-Mel (the dummy)
Massimo Belgrano
You prefer size of executable or speed of application because CGI executables are loaded at each request
dynload (all harbour lib dynamically in one or more dll)
will be usefull for all harbour user that want use cgi
and we have a common reference for test
--
Massimo Belgrano
Angel Pais
How about using Harbour as THE HTTP SERVER ????
Mindaugas had published a nice one.
Anybody using it on production ?
Mindaugas ? Have you performance stadistics ?
A client from the USA have asked me to translate my Xbase++ http/soap
server to a Harbour based one.
I have Mindaugas expample for the http partm, but i'll have to study all
the SOAP RFC document to implemente the other and I don't konw if I will
suceed.
Well, time will tell. For now I'm focussed on the http and scripting part.
regards
Angel
Mel_the_Snowbird
:
On Jul 25, 10:31 am, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Hi Mel
> You prefer size of executable or speed of application because CGI
> executables are loaded at each request
But, I'm guessing that *loading* the nearly double-sized Harbour
CGI exe (maybe 50 or more of them simultaneously) may well taken a lot
more time.
> Using harbour you can use bcc or
> dynload (all harbour lib dynamically in one or more dll)
> Require recompilation with hb_build_contrib_dyn and is untested feature
> afaik
>
> Can you post as example same/all part of http://www.whosaway.com/?
> will be usefull for all harbour user that want use cgi
> and we have a common reference for test
>
really am., but I'll think of creating some pseudo-code relating to my
CGI app for use here.
Also, I have a lot of private hard-coded stuff in my CGI app
(passwords, etc) that I wish to keep hidden.
-Mel
Klas Engwall
> Harbour is a good tool for writing server applications.
> One of the technologies used on the server side are WebServices.
> I believe that such technology in the Harbour should be developed or adapted.
> Question to the knowledgeable licensed, whether the product gSOAP whose license is:
>
> http://www.cs.fsu.edu/~engelen/soap.html
>
> suitable for adopting the Harbor (like eg OCILIB or CAIRO), notwithstanding the
> licensing terms?
> Does anyone know this product or carers about him?
I use gSOAP with xHarbour since 2006, but only on the client side (I
have made no attempts at all to try and use it as a SOAP server). It
works quite well for me although I am not a C programmer and needed some
help to get started.
I use it for sending orders to a warehouse. In xHarbour I set up C
structs for order head and order lines "on the prg side" and pass those
to gSOAP's C functions using a little wrapper that someone helped me
create. But if I understood Przemek correctly the C struct handling in
xHarbour is not (and cannot be?) stable and will not be implemented in
Harbour. And I had some problems myself using structs in pcode dlls and
had to link everything into the main exe instead after some changes that
were implemented in xHarbour in 2008 or 2009. Maybe there are better
ways to pass that kind of data to the C level, but I don't know how to
do it.
There are three different license versions for gSOAP: GPL v2, their own
gSOAP license (based on the Mozilla license) and a commercial license.
The problem there is that two of the key components, the wsdl2h utility
(getting the service description from the server) and the soapcpp2
utility (converting the output of wsdl2h to source code) plus even the
resulting source code, need the commercial license for any use in a
non-GPL environment. So unfortunately I see no way to integrate gSOAP
with (x)Harbour except getting a commercial license for each developer.
A better wrapper layer for (x)Harbour that takes care of the interface
problems I stumbled on would be nice to have, but each developer will
have to decide whether to publish his own source code according to the
GPL license or turn to the commercial license.
Regards,
Klas
Bacco
endpoints. Also, SOAP is basic enough that you can resolve 100% in prg
code without relying in 3rd party work. If you use it frequently, it
really worth a try.
Jorge Aldo G. de F. Junior
another aplication (A object pascal one).
My intent was to write a webserver that could execute harbour bytecode
internally, instead of as a CGI.
I wrote a webserver in freepascal (lightwebserver) that is
multithreaded and supports HTTPS.
But running harbour as cgi ends up being as slow as running object
pascal apps in cgi form.
End result : i write everything in pascal as server extensions (instead of CGI).
Harbour would be better suited for the database/logic than pascal
(while i think pascal is more suited for socket programming, https
etc).
No one answered how to embed harbour into other binaries... (you can
give me a C header, i can work with that in Pascal).
2011/7/25 Bacco <carlo...@gmail.com>:
Klas Engwall
> You can roll your own simplified protocol if you write for both
> endpoints. Also, SOAP is basic enough that you can resolve 100% in prg
> code without relying in 3rd party work. If you use it frequently, it
> really worth a try.
I am sure one can do that :-)
But in my case I had to connect to a public server and use the full SOAP
protocol that was already implemented by the server owner. No cheating
allowed :-). So the 200 USD (or something like that) that I paid saved
me a lot of work and time. And I can use it frequently too if I want to :-)
Regards,
Klas
marek.h...@interia.pl
"Mel_the_Snowbird" <meds...@aol.com> pisze:
>
>
> On Jul 25, 9:44 am, Mel_the_Snowbird wrote:
> > Marek & Massimo:
> >
> > All three of my web site servers are written *purely* in
> > xHarbour.
> >
> > I've been thinking of changing them to Harbour, but the foot print
> > of the Harbour executable is almost twice as big as the xHarbour
> > version.
>
> AGAIN, I inadvertently hit the key while focused on the
> 'Send' Button. Its hard to break the habit.
>
Mel,
the size of the EXE file may have significance when it is called by Apache.
In the standard application speed is more important.
Some 20 years ago I wrote in Clipper scripting language.
After compiling him in Harbour, this language often executes scripts faster than clean EXE in xHarbour.
In Harbour is an example of a web server, which unfortunately is not finished and is not optimized.
But this is a VERY GOOD example of how to effectively write a web application. And this solution is faster than the duet Apache and CGI.
Unfortunately, with such applications on the current development of Harbour is still a lot of work.
I thought two times, and gave up. But with us it is a proverb: "three strikes" - so that everything before me.
I work at a large company, and the technology webserwices is fairly intensively developed.
Here, the application workload is smaller. Allows you to create an efficient and modern solutions.
Harbour to this is ideal. The next step will probably be a web interface.
Regards,
Marek Horodyski
----------------------------------------------------------------
Najwieksza baza samochodow nowych i uzywanych
Sprawdz >> http://linkint.pl/f29e3
marek.h...@interia.pl
"Angel Pais" <amig...@adinet.com.uy> pisze:
> Mel:
>
> How about using Harbour as THE HTTP SERVER ????
> Mindaugas had published a nice one.
> Anybody using it on production ?
> Mindaugas ? Have you performance stadistics ?
> A client from the USA have asked me to translate my Xbase++ http/soap
> server to a Harbour based one.
Hi,
SOAP server is not good to write standalone applications, but it is a good tool for application integration.
Better than it was to use gSOAP, use MIniXML. But I have not seen on www page such adaption.
I'm not sure if my translations are well understood. However, I need to use this technology with Harbour.
It has each server, even database servers. Harbour is suitable for writing server applications.
I see here a natural consequence of growth/development.
marek.h...@interia.pl
"Klas Engwall" <har...@engwall.com> pisze:
> Hi Marek,
>
> > Harbour is a good tool for writing server applications.
> > One of the technologies used on the server side are WebServices.
> > I believe that such technology in the Harbour should be developed or adapted.
> > Question to the knowledgeable licensed, whether the product gSOAP whose license is:
> >
> > http://www.cs.fsu.edu/~engelen/soap.html
> >
> > suitable for adopting the Harbor (like eg OCILIB or CAIRO), notwithstanding the
> > licensing terms?
> > Does anyone know this product or carers about him?
>
> I use gSOAP with xHarbour since 2006, but only on the client side (I
> have made no attempts at all to try and use it as a SOAP server). It
> works quite well for me although I am not a C programmer and needed some
> help to get started.
Probably time to start :)
I personally do not know how to write in C.
But somehow the time to help Przemek, Mindaugas, Thomas or Viktor.
They are tired, they want to stuff their children at home - let them independence.
So to end I do not believe that the mother abandoned her children :). Must rest.
From your experience, I see that the license is not a problem, and the integration of gSoap.
It seems to me that having MINIXML should be fairly easy to send him on site.
There was no problem to convert the structures C <-> PRG.
Unfortunately, I have no experience here.
marek.h...@interia.pl
"Bacco" <carlo...@gmail.com> pisze:
> You can roll your own simplified protocol if you write for both
> endpoints. Also, SOAP is basic enough that you can resolve 100% in prg
> code without relying in 3rd party work. If you use it frequently, it
> really worth a try.
>
Sounds promising.
However, "own" protocol is a bad idea.
Participate in the exchange of information applications in Java, Oracle, and other "technologies".
Missing here Harbour aplications :)
marek.h...@interia.pl
> i once asked on how to embed the harbour bytecode interpreter on
> another aplication (A object pascal one).
SOAP is used to exchange information and not the code.
> My intent was to write a webserver that could execute harbour bytecode
> internally, instead of as a CGI.
See examples of HTTP serwers in HARBOUR\COTRIB.
> I wrote a webserver in freepascal (lightwebserver) that is
> multithreaded and supports HTTPS.
As in the Harbour.
> But running harbour as cgi ends up being as slow as running object
> pascal apps in cgi form.
CGI is the unknown. It's a dead end.
> End result : i write everything in pascal as server extensions (instead of CGI).
Harbour, like Clipper, has a very flexible tool for application development.
See, for example in HBRUN.
> Harbour would be better suited for the database/logic than pascal
> (while i think pascal is more suited for socket programming, https
> etc).
Not only. This is a good and powerful programming language for applications in many areas.
Regards,
Marek Horodyski
----------------------------------------------------------------
Dziesiatki tysiecy ofert domow i mieszkan!
Ogladaj >> http://linkint.pl/f29e4
Gerald Drouillard
>
> But this is a VERY GOOD example of how to effectively write a web application. And this solution is faster than the duet Apache and CGI.
applications that open 40+ dbfs and return results in less than a second
(.01 secs for a "hello world" request/response) in xharbour/apache
combo. I often wondered if removing the apache part would significantly
improve response time but it has not been a high priority because we
have decent performance.
Also the size of the exe may not be directly related to speed,
especially if the exe is compressed. We find the exe is cached in
memory on windows/apache servers with the exe on a network drive. For
instance if the exe is updated, the new exe only starts working after
all the old exe's are finished running on the server. As long as there
is one old exe process running the old exe (in memory) is handling all
the new incoming requests.
--
Regards
--------------------------------------
Gerald Drouillard
Technology Architect
Drouillard& Associates, Inc.
http://www.Drouillard.biz
Klas Engwall
> From your experience, I see that the license is not a problem,
Under the commercial license, I could do whatever I needed. And it is
reasonably priced for all the things it can do.
> and the integration of gSoap.
This was in my xHarbour/BCC days, and I had a couple of minor problems
regarding variable initialization that BCC complained about. Those were
easily fixed by just reading the error messages properly and moving a
couple of lines in the gSOAP source code. After getting some help
writing the wrapper (50 lines or so) everything went smoothly. Much more
smoothly than I had expected, actually. gSOAP even has a tracelog mode
that is very educational. I am quite happy with it.
> It seems to me that having MINIXML should be fairly easy to send
> him on site.
I just spent a few minutes reading up on MINIXML. License-wise it should
be no problem at all since the MINIXML license is GPL with an exception
similar to the Harbour exception. But feature-wise it seems to be
limited to reading/writing/coding/decoding XML files locally. gSOAP also
includes the communication with the SOAP server and a couple of
utilities to get the service description from the server and convert it
to C code (as I mentioned yesterday).
> There was no problem to convert the structures C<-> PRG.
> Unfortunately, I have no experience here.
Was this a question? :-) As always, documentation is the weak point of
the (x)Harbour tool families (Note: I am not complaining :-) ). A couple
of examples were posted by Ron Pinkas in the xHarbour newsgroup, and I
used those as a basis for my implementation although I really had no
idea what I was doing :-). After some initial problems with numeric
conversions (my fault, of course) it has been working for five years now.
After som changes that were made in xHarbour around 2008/2009 I got a
GPF after each order that was successfully transferred to the SOAP
server. It turned out to be a combination of the gSOUP library being
linked to a pcode DLL and (as far as I understand) something that had
changed the execution order of init procedures between xHarbour
versions. As I mentioned yesterday, the workaround was to link
everything into the main exe instead. Not what I wanted to do, but what
the heck :-)
In Harbour, C structs are inplemented in the xhb lib, not in Harbour
itself. There was a thread in harbour-devel about using C structs in a
Harbour application almost exactly one year ago. Search for a thread
with subject "CStructures - Error executing an application", started by
Pritpal on July 28, 2010.
Regards,
Klas
Gerald Drouillard
> "Jorge Aldo G. de F. Junior"<jag...@gmail.com> pisze:
>> i once asked on how to embed the harbour bytecode interpreter on
>> another aplication (A object pascal one).
> SOAP is used to exchange information and not the code.
>
>
>> My intent was to write a webserver that could execute harbour bytecode
>> internally, instead of as a CGI.
> See examples of HTTP serwers in HARBOUR\COTRIB.
>
>
>> I wrote a webserver in freepascal (lightwebserver) that is
>> multithreaded and supports HTTPS.
> As in the Harbour.
>
>> But running harbour as cgi ends up being as slow as running object
>> pascal apps in cgi form.
> CGI is the unknown. It's a dead end.
disagree. We have many very complex applications including soap, ajax
lookups, complex tables with server side sorting, and interfaces with
java libraries like http://yuilibrary.com/ and
http://jquerymobile.com/. We use a compiled application for cgi, not
scripting.
We have been doing clipper/xharbour with IIS and apache for many years
and don't see any sign of it slowing down.
marek.h...@interia.pl
[...]
> http://jquerymobile.com/. We use a compiled application for cgi, not
> scripting.
>
> We have been doing clipper/xharbour with IIS and apache for many years
> and don't see any sign of it slowing down.
How many users ? 1, 2, 3, 4 thousand ?
Gerald Drouillard
> "Gerald Drouillard"<gerr...@drouillard.ca> pisze:
>> On 7/26/2011 5:11 AM, marek.h...@interia.pl wrote:
>>> "Jorge Aldo G. de F. Junior" pisze:
> [...]
>
>> http://jquerymobile.com/. We use a compiled application for cgi, not
>> scripting.
>>
>> We have been doing clipper/xharbour with IIS and apache for many years
>> and don't see any sign of it slowing down.
> How many users ? 1, 2, 3, 4 thousand ?
with the average transaction of less than 1sec, at any point in time
translates to maybe 5 concurrent transactions on average during busy
times. I have seen 15 concurrent transactions without an issue. I
never have felt the need to find the upper limit as we don't have any
sluggishness signs except when someone inhouse is running a killer
report on production data with databases over 3.4 million records using
rmdbfcdx.
Przemysław Czerpak
Hi Mel,
> But, I'm guessing that *loading* the nearly double-sized Harbour
> CGI exe (maybe 50 or more of them simultaneously) may well taken a lot
> more time.
I think you are wrong.
Such basic functionality like cloning (sharing between processes) memory
pages of program code when it's executed in next instances or retrieving
them from the cache existed in *nixes over 20 years ago. If MS-Windows
still cannot do that that it's time to forget about this system.
Personally I do not believe in it so code size should not cause any
speed differences. If you do not compress executable file using UPX
or sth like that then all program instances should share memory pages
with mapped application code.
Anyhow if you want to reduce code size then you can quite easy reach
it if you use MinGW though with some speed cost.
First you should disable -gc3 in HBRTL code by:
SET HB_USER_PRGFLAGS=-gc0
it should reduce size of statically linked applications without
significant performance lost. How much depends on your code and
how many PRG functions from HBRTL you are using. Rebuild cleanly
whole Harbour code and check. This trick works with all C compilers.
Simple test with
? "Hello world"
shows that Harbour creates smaller binaries then xHarbour so it's
possible that it will cause that your applications will be smaller.
And always remember to strip final binaries, i.e. using -strip hbmk2
option. By default MinGW attaches information for GDB (GNU debugger)
which is often few time larger then the application.
With MinGW you can use -Os C compiler switch. It disables optimizations
which increase final code size. So it will also reduce application
performance but final binaries will be smaller - similar to the one
produced by BCC but still faster. To check it use:
SET HB_USER_CFLAGS=-Os
and then rebuild cleanly whole Harbour code.
And remember to create statically linked applications. harbour-*.dll
contains all core functions and each of them has to be registered in
HVM what consumes time. In static applications only functions you are
using (directly or indirectly by some internal bindings) plus some
small set of standard DBASE functions are linked.
I hope that now you are ready to create Harbour binaries optimal for
you and make speed tests with your real application.
best regards,
Przemek
marek.h...@interia.pl
> On Mon, 25 Jul 2011, Mel_the_Snowbird wrote:
>
> Hi Mel,
>
> still cannot do that that it's time to forget about this system.
It's not that simple :)
[...]
> And always remember to strip final binaries, i.e. using -strip hbmk2
O ! App is less about 600 kb :)
Question about this thread - as you think - when in harbor is xml and http, how difficult is merge it to soap ?
Is not it so :
http + xml= soap // ?
Regards,
Marek Horodyski
----------------------------------------------------------------
Gerald Drouillard
> "Przemysław Czerpak"<dru...@acn.waw.pl> pisze:
>> On Mon, 25 Jul 2011, Mel_the_Snowbird wrote:
>>
>> Hi Mel,
>>
> [...]
>> still cannot do that that it's time to forget about this system.
> It's not that simple :)
>
> [...]
>> And always remember to strip final binaries, i.e. using -strip hbmk2
> O ! App is less about 600 kb :)
>
> Question about this thread - as you think - when in harbor is xml and http, how difficult is merge it to soap ?
> Is not it so :
> http + xml= soap // ?
just about it. Some soap servers need the content length header to be
set also.
Viktor Szakáts
IMO the main point of a SOAP implementation is to take a
WSDL file and convert it automatically to .prg OOP code that
deals with converting the method call to XML request and
parsing the response XML and converting it to return value.
Assembling XML by itself is easy without any extra libs,
for parsing we have hbexpat (and hbmxml), for HTTPS
send/receive hbcurl can be used (hbtip doesn't have serious
HTTPS support so it cannot be used for SOAP, except for
toy services which work via plain HTTP).
Such .wsdl to .prg converter can then be embedded into
a hbmk2 plugin thus making the whole process seamless.
This is for client side, I don't know much about SOAP server
side, but I assume main portions are similar to the above,
plus it needs an HTTP server which we already have in
hbhttpd lib. hbhttps will need HTTPS support for anything
serious, so it will have to be rewritten to use hbcurl or hbtip
extended with proper HTTPS support, hbcurl seems the
better way.
Viktor
Maurício Ventura Faria
Here in Brazil, more and more government repartitions are using secure web
services to interact with people and companies using digital certification.
And everytime I need to do such a work I have to use other tools.
If we could do it in Harbour it would be wonderful.
For now, if client side functionality could be implemented it would be a
great step forward.
Maurício Ventura Faria
Fernando Athayde
cXML := STRTRAN( cXML, '<?xml version="1.0" encoding="ISO-8859-1"?>', '' )
cXML := STRTRAN( cXML, "<", "<" )
cXML := STRTRAN( cXML, ">", ">" )
Load DOMDocument
xmldom = win_oleCREATEOBJECT("MSXML2.DOMDocument.5.0")
xmldom:async = .T.
xmldom:validateOnParse = .T.
xmldom:resolveExternals := .T.
xmldom:preserveWhiteSpace = .T.
Load XMLHTTP
xmldoc = win_oleCREATEOBJECT("MSXML2.XMLHTTP.6.0")
url := "http://189.1.164.238:8080/issonline/servlet/anfse"
xmldoc:setrequestheader("Content-Type","application/x-www-form-urlencoded")
xmldoc:setRequestHeader("SOAPAction", "nfseaction/ANFSE.Execute" )
Making XML for WebService
Texto := '<?xml version="1.0" encoding="ISO-8859-1"?>'
Texto += '<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"';
+ ' xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="nfse" xmlns:wsdlns="nfse" xmlns:tns1="ISS">'
Texto += '<SOAP-ENV:Body>'
Texto += '<wsdlns:Nfse.Execute xmlns:wsdlns="nfse">'
Texto += '<wsdlns:Operacao>1</wsdlns:Operacao>'
Texto += '<wsdlns:Usuario>21312</wsdlns:Usuario>' //
Texto += '<wsdlns:Senha>321321321321</wsdlns:Senha>'
Texto += '<wsdlns:Webxml>'+cXML+''
Texto += '</wsdlns:Webxml>'
Texto += '</wsdlns:Nfse.Execute>'
Texto += '</SOAP-ENV:Body>'
Texto += '</SOAP-ENV:Envelope>'
xmldom:LoadXML(Texto)
IF xmldom:parseError:errorCode = 0
//"XML Load"
ELSE
lcErrorMsg = "Não foi possível carregar o documento pois ele não corresponde ao seu Schema"
lcErrorMsg = lcErrorMsg + " Linha: " + STR(xmldom:parseError:line)
lcErrorMsg = lcErrorMsg + " Caractere na linha: " + STR(xmldom:parseError:linepos)
lcErrorMsg = lcErrorMsg + " Causa do erro: " + xmldom:parseError:reason;
+"code: "+STR(xmldom:parseError:errorCode)
msginfo(lcErrorMsg)
ENDIF
De: Maurício Ventura Faria <con...@gmail.com>
Para: harbou...@googlegroups.com
Enviadas: Quarta-feira, 27 de Julho de 2011 10:07
Assunto: Re: [harbour] Re: Harbour evolution and WebServices.
Viktor Szakáts
and it's also Windows version and installation dependent. It also has
bugs not fixed since many years by MS. It also uses now abandoned
INET backend if I recall correctly. (f.e. it issues each requests
_twice_, visible when viewed via TCP/IP traffic sniffer)
As another consequence, support for some essential INET features
are hard to configure or not configurable in stable/automatic way, f.e.
proxy support, handling custom root certificates (this was a problem
with .NET/Mono too BTW), etc.
In practice this method turned unusable for me personally.
For many years I've been using middleware written in C#, now it's
rewritten in native Harbour (hbcurl and hbexpat), which works beautifully,
but the XML translations are done fully manually, which is not
a maintenance dream if the SOAP interface (.wsdl) changes.
Viktor
Gerald Drouillard
> Hi,
>
> IMO the main point of a SOAP implementation is to take a
> WSDL file and convert it automatically to .prg OOP code that
> deals with converting the method call to XML request and
> parsing the response XML and converting it to return value.
>
> Assembling XML by itself is easy without any extra libs,
> for parsing we have hbexpat (and hbmxml), for HTTPS
> send/receive hbcurl can be used (hbtip doesn't have serious
> HTTPS support so it cannot be used for SOAP, except for
> toy services which work via plain HTTP).
>
> Such .wsdl to .prg converter can then be embedded into
> a hbmk2 plugin thus making the whole process seamless.
>
> This is for client side, I don't know much about SOAP server
> side, but I assume main portions are similar to the above,
> plus it needs an HTTP server which we already have in
> hbhttpd lib. hbhttps will need HTTPS support for anything
> serious, so it will have to be rewritten to use hbcurl or hbtip
> extended with proper HTTPS support, hbcurl seems the
> better way.
handle the http/https stuff. Just haven't had the time to test
harbour's native support yet. I am sure there are pro's and con's of
using/not using apache. You have to evaluate them for your situation.
Curl is you friend for harbour being the client. It works great. Your
can even use the curl.exe command line for quick testing in some cases.
This doesn't apply for soap, but the only time we have not been able to
use curl is when the site is IE only with asp pages with scripting. In
that case we have to remote control a IE instance.
I have not looked at (x)harbour's xml support in awhile, but back a
couple of years ago we decide to write our own xml object class due to
various issues.
Mel_the_Snowbird
Thanks for your guidance above.
I'll work this week in trying to creat a Harbour version of my CGI
app, and I'll let you know
Currently, my www.whosaway.com CGI app size is 1,090,560 bytes. Of
course this contains a *lot* of old extra code that was used in its
former life (as a golf-related app). I have not removed that, and its
still there consuming space.
But, I'll work on that this week as you noted above, and try
converting it to Harbour.
(Going golfing for the day now)
Thnaks for the guidance.
-Mel
Viktor Szakáts
>> This is for client side, I don't know much about SOAP server
>> side, but I assume main portions are similar to the above,
>> plus it needs an HTTP server which we already have in
>> hbhttpd lib. hbhttps will need HTTPS support for anything
>> serious, so it will have to be rewritten to use hbcurl or hbtip
>> extended with proper HTTPS support, hbcurl seems the
>> better way.
>
> For (x)harbour being a soap server, we have always used apache/IIS to handle
> the http/https stuff. Just haven't had the time to test harbour's native
> support yet. I am sure there are pro's and con's of using/not using apache.
> You have to evaluate them for your situation.
I'd certainly welcome an apache solution. This seems to be
great deal of work though to add support for running .prg code
as mod_harbour, if the goal is to handle SOAP server side
using native .prg.
> I have not looked at (x)harbour's xml support in awhile, but back a couple
> of years ago we decide to write our own xml object class due to various
> issues.
Understandably. The legacy xhb XML handling code currently
present in xhb lib has many issues just by glancing to its source
code. Doesn't seem suitable for more serious tasks or anything
server side.
hbexpat (SAX parser) is stable, thin and fast, so it's very good as
a base. I use it to build a hash/array structure in memory. Here
it would help if Harbour hashes could have attributes attached.
Probably hbmxml is worth checking too, it has some unfixed
side issues, but it should provide a richer XML parser once the
interface is understood.
Viktor
Gerald Drouillard
> Hi Gerald,
>
>>> This is for client side, I don't know much about SOAP server
>>> side, but I assume main portions are similar to the above,
>>> plus it needs an HTTP server which we already have in
>>> hbhttpd lib. hbhttps will need HTTPS support for anything
>>> serious, so it will have to be rewritten to use hbcurl or hbtip
>>> extended with proper HTTPS support, hbcurl seems the
>>> better way.
>> For (x)harbour being a soap server, we have always used apache/IIS to handle
>> the http/https stuff. Just haven't had the time to test harbour's native
>> support yet. I am sure there are pro's and con's of using/not using apache.
>> You have to evaluate them for your situation.
> I'd certainly welcome an apache solution. This seems to be
> great deal of work though to add support for running .prg code
> as mod_harbour, if the goal is to handle SOAP server side
> using native .prg.
that comes into play is if you use a 3rd party to host your web site and
what they will allow you to install/run.
>
>> I have not looked at (x)harbour's xml support in awhile, but back a couple
>> of years ago we decide to write our own xml object class due to various
>> issues.
> Understandably. The legacy xhb XML handling code currently
> present in xhb lib has many issues just by glancing to its source
> code. Doesn't seem suitable for more serious tasks or anything
> server side.
>
> hbexpat (SAX parser) is stable, thin and fast, so it's very good as
> a base. I use it to build a hash/array structure in memory. Here
> it would help if Harbour hashes could have attributes attached.
>
> Probably hbmxml is worth checking too, it has some unfixed
> side issues, but it should provide a richer XML parser once the
> interface is understood.
>
> Viktor
Bacco
> for parsing we have hbexpat (and hbmxml), for HTTPS
> send/receive hbcurl can be used (hbtip doesn't have serious
> HTTPS support so it cannot be used for SOAP, except for
> toy services which work via plain HTTP).
I'm using one of these toys with https, written in harbour with no
problem. It's not SOAP, but somewhat similar (xml to access foreign
APIs). Also, twitter oauth over https works very well. Maybe you mean
it can't be used with client certificates? I'm interested in this
subject, as I will need to use client certificates very soon.
Regards,
Bacco
Raul Almeida
I did some work trying to integrate Harbour and gSoap.
I created a tool that takes Harbour annotated code and generates C++
also annotated code. gSoap has a tool that takes this C++ annotated
code and generates wsdl file.
You have to compile your harbour code to lib, the generated C++ code
to another lib and link both to your WebServer.
A exemple of harbour annotation is like this:
//hbcc std::string ClientName( int nClientId )
Function ClientName( nClientId )
LOCAL cClientName := ''
If clientdb->(DbSeek(StrZero(nClientId,7)))
cClientName := clientdb->name
EndIf
Return cClientName
The annotations are necessary to library know what are function return
type and arguments types.
If you became interested you can download it at http://sourceforge.net/projects/hbcppapi/
It's unfinished work but can give you an idea to go on.
On Jul 25, 9:30 am, marek.horody...@interia.pl wrote:
> Hello.
> One of the technologies used on the server side are WebServices.
> I believe that such technology in the Harbour should be developed or adapted.
> Question to the knowledgeable licensed, whether the product gSOAP whose license is:
>
> http://www.cs.fsu.edu/~engelen/soap.html
>
> suitable for adopting the Harbor (like eg OCILIB or CAIRO), notwithstanding the licensing terms?
> Does anyone know this product or carers about him?
>
Viktor Szakáts
I meant "toy service" as a web service which doesn't require HTTPS.
I think any serious B2B or B2G applications will require authentication,
and thus HTTPS and thus a valid root certificate. Without these, we
can still talk about SOAP support, but it will be unusable except for
some unauthenticated, plain HTTP ("toy") applications.
Viktor
Bacco
> and thus HTTPS and thus a valid root certificate. Without these, we
> can still talk about SOAP support, but it will be unusable except for
> some unauthenticated, plain HTTP ("toy") applications.
I had no problem with the APIs that doesn't require my own
certificate, but use HTTPS with the provider certificate. I really
need to experiment with client certificates. Also, I believe it's a
matter of implementing the missing methods in HBSSL, am I right? I'm
looking into this subject in the last days.
Viktor Szakáts
Plus many businesses are using web proxies (sometimes authenticated),
so support for them is also important for complete SOAP support.
All of the above is handled well by libcurl + hbcurl, so if its used as a
backend, one needs to focus on XML translation only.
Viktor
Viktor Szakáts
Client certificate is a form of authentication, so if you're thinking
about HBTIP, it needs to be implemented there, with the help of
HBSSL. If HBSSL is missing any bits required for that, it should
also be extended. For me this seems waste of large amount of
energy and time, so I stick with hbcurl which has all of these out
of the box.
Viktor
Bacco
> about HBTIP, it needs to be implemented there, with the help of
> HBSSL. If HBSSL is missing any bits required for that, it should
> also be extended. For me this seems waste of large amount of
> energy and time, so I stick with hbcurl which has all of these out
> of the box.
I will dig deeper and report any "findings". I'm looking beyond HTTPS,
XML and SOAP, and thinking about other kind of encripted networking
with ssl, including semi-permanent connections. Also, I'll take a
better look in hbcurl.
Thanks,
Bacco
Gerald Drouillard
server. Curl can handle ssl when we are talking about client process.
Viktor Szakáts
> side, but I assume main portions are similar to the above,
> plus it needs an HTTP server which we already have in
> hbhttpd lib. hbhttps will need HTTPS support for anything
> serious, so it will have to be rewritten to use hbcurl or hbtip
> extended with proper HTTPS support, hbcurl seems the
> better way.
I have to correct this, of course hbcurl cannot be used on
the server as some folks pointed out well, so on the server
side the only solution is to keep using core Socket API
plus HBSSL lib (or similar). Or alternatively to use existing
web servers as a base.
First it seems reasonable to focus on SOAP client functionality
as this is more typical and widespread usage.
Viktor
marek.h...@interia.pl
"Fernando Athayde" <fernando...@yahoo.com.br> pisze:
But, we can use WebServicesI use for government and for my citysee
a example for send a xml with many invoices
*---
This is a client-side.
Have you example on server-side?
Mel_the_Snowbird
> I think you are wrong.
> Such basic functionality like cloning (sharing between processes) memory
> pages of program code when it's executed in next instances or retrieving
> them from the cache existed in *nixes over 20 years ago. If MS-Windows
> still cannot do that that it's time to forget about this system.
> Personally I do not believe in it so code size should not cause any
> speed differences. If you do not compress executable file using UPX
> or sth like that then all program instances should share memory pages
> with mapped application code.
> Anyhow if you want to reduce code size then you can quite easy reach
> it if you use MinGW though with some speed cost.
> First you should disable -gc3 in HBRTL code by:
> SET HB_USER_PRGFLAGS=-gc0
> it should reduce size of statically linked applications without
> significant performance lost. How much depends on your code and
> how many PRG functions from HBRTL you are using. Rebuild cleanly
> whole Harbour code and check. This trick works with all C compilers.
> Simple test with
> ? "Hello world"
> shows that Harbour creates smaller binaries then xHarbour so it's
> possible that it will cause that your applications will be smaller.
I then built the Harbour\tests\hello.prg program. Size: 1,134,080
bytes
I then built the xHarbout\tests\hello.prg (exactly same as
above)). Size: 800,768 bytes
> And always remember to strip final binaries, i.e. using -strip hbmk2
> option. By default MinGW attaches information for GDB (GNU debugger)
> which is often few time larger then the application.
> With MinGW you can use -Os C compiler switch.
And remember to create statically linked applications. harbour-*.dll
> contains all core functions and each of them has to be registered in
> HVM what consumes time. In static applications only functions you are
> using (directly or indirectly by some internal bindings) plus some
> small set of standard DBASE functions are linked.
statically built.
btw, I (finally) got my (more complex) CGI app to compile and link
correctly this morning. Its size was 1,651,712 bytes. My old,
standard, BCC CGI app is 1,090,560.
another btw: I placed the new harbour executable on my server for
a few minutes and tested it: When entering the 'HB' password, it
failed to accept it. I have not determined why it failed but will
investigate in the next day or so.
Thanks for your suggestions.
-Mel
Przemysław Czerpak
Hi Mel,
> > First you should disable -gc3 in HBRTL code by:
> > SET HB_USER_PRGFLAGS=-gc0
> > it should reduce size of statically linked applications without
> > significant performance lost. How much depends on your code and
> > how many PRG functions from HBRTL you are using. Rebuild cleanly
> > whole Harbour code and check. This trick works with all C compilers.
> > Simple test with
> > ? "Hello world"
> > shows that Harbour creates smaller binaries then xHarbour so it's
> > possible that it will cause that your applications will be smaller.
> I rebuilt completely Harbour 3.1.0 using -gc0
> I then built the Harbour\tests\hello.prg program. Size: 1,134,080
> bytes
Please read more carefully my messages. I know that my English is
fatal but if I aks you to strip final binaries then please do that.
Above result is size of standard unstripped harbour build.
Here are results for 32bit MinGW build (GCC4.6):
2011-05-07 13:33 147 hello.prg
2011-07-28 23:37 1˙136˙693 hello-32-std.exe
2011-07-29 00:28 1˙126˙171 hello-32-std-gc0.exe
2011-07-29 00:50 863˙284 hello-32-std-gc0-Os.exe
2011-07-28 23:37 863˙744 hello-32-strip.exe
2011-07-29 00:28 852˙992 hello-32-strip-gc0.exe
2011-07-29 00:51 585˙728 hello-32-strip-gc0-Os.exe
So your results suggests that you used standard Harbour build and you
created unstripped binaries and we are again at the beginning of this
discussion.
So please start your tests from -strip hbmk2 command and try:
hbmk2 hello.prg -strip
and check the size of hellow.exe. As you can see above it should be
close to 863˙744 bytes (hello-32-strip.exe) - some small diffeences
can appear du to different MinGW/GCC distributions.
Then you can try to rebuild Harbour with switches I was talking about.
In hello.prg -gc0 does not give significant size reduction because only
small part of HBRTL is linked with this code.
> I then built the xHarbout\tests\hello.prg (exactly same as
> above)). Size: 800,768 bytes
Not exactly if you have such results.
I've just downloaded current xHarbour and created new xHarbour MinGW
binaries. I had to set:
SET C_USR=-O3
because in xHarbour GNU make build system it's not enabled by default.
Here are results:
2011-07-29 01:15 1˙251˙503 hello-xhb-std.exe
2011-07-29 01:15 1˙026˙048 hello-xhb-strip.exe
I'm very interested how you are creating your xHarbour binaries and which
MinGW version you are using because still xHarbour binaries are bigger
when the same C compiler with the same switches is used and nothing
has changed here in last 8 years.
Of course if you link all Harbour binaries with final application then
it will be bigger because Harbour has much more libraries then xHarbour.
But simple hello.prg should be smaller if both compilers uses the same
switches.
In my opinion in you are linked your xHarbour application differently,
i.e. your build scripts uses NULRDD or sth like that when you are
linking xHarbour binaries because your results are much smaller then
from standard build. I'm leaving to you to check what exactly you are
doing. If you want to link NULRDD with Harbour binaries then it's enough
to use -nulrdd switch in HBMK2, i.e.:
hbmk2 -nulrdd -strip hello.prg
> > And always remember to strip final binaries, i.e. using -strip hbmk2
> > option. By default MinGW attaches information for GDB (GNU debugger)
> > which is often few time larger then the application.
> > With MinGW you can use -Os C compiler switch.
> Where/how do we use this -Os C Compiler switch ???
I'm really confused. I aksed you to set:
SET HB_USER_PRGFLAGS=-gc0
and rebuild Harbour core code. THen I asked you to set:
SET HB_USER_CFLAGS=-Os
and rebuild Harbour core code once again but now you are asking me
were it should be set. Is this second envvar name too complicated? ;-)
Or maybe
> And remember to create statically linked applications. harbour-*.dll
> > contains all core functions and each of them has to be registered in
> > HVM what consumes time. In static applications only functions you are
> > using (directly or indirectly by some internal bindings) plus some
> > small set of standard DBASE functions are linked.
> Yes, I do not compress my executable and my apps are all
> statically built.
>
> btw, I (finally) got my (more complex) CGI app to compile and link
> correctly this morning. Its size was 1,651,712 bytes. My old,
> standard, BCC CGI app is 1,090,560.
Sorry but I cannot say it's good or not because so far I have no
idea what you exactly you are doing when you are rebuilding Harbour
and then you applications.
> another btw: I placed the new harbour executable on my server for
> a few minutes and tested it: When entering the 'HB' password, it
> failed to accept it. I have not determined why it failed but will
> investigate in the next day or so.
If you will have some more precise questions then maybe I can help you.
best regards,
Przemek
Przemysław Czerpak
Hi Marek,
> > And always remember to strip final binaries, i.e. using -strip hbmk2
> O ! App is less about 600 kb :)
In some cases it can be much more.
> Question about this thread - as you think - when in harbor is xml and http, how difficult is merge it to soap ?
> Is not it so :
> http + xml= soap // ?
We do not have any libraries which gives such support directly but
usually it's not big problem to create necessary code using existing
Harbour libraries.
Anyhow I do not have big practice experience here so I'm not good
person to answer.
In some spare time I plan to create mod_hb for Apache HTTP server.
Now I have very basic code created with Mindaugas which adds to
Harbour Active Script engine (HbScript) so it can be used in Windows
with IIS, IE, Windows Script or with any other language which support
OLE. Recently I made first tests with real MS-Windows and resolved few
problems I was not able to fix without real tests or using WINE anyhow
this code still needs more time to create version which can be public.
The main problem for me is documentation. No source code and very basic
docs provided by MS causes that I have to make runtime tests to find
answers for some important questions. I hope that some Windows users
here can continue work on HbScript when we make it public.
BTW does anyone here has some experience in this subject?
best regards,
Przemek
marek.h...@interia.pl
"Przemysław Czerpak" <dru...@acn.waw.pl> pisze:
> [środa, 27 lipiec 2011], marek.h...@interia.pl napisał(a):
>
> Hi Marek,
>
> > > And always remember to strip final binaries, i.e. using -strip hbmk2
> > O ! App is less about 600 kb :)
>
> In some cases it can be much more.
>
> > Question about this thread - as you think - when in harbor is xml and http, how difficult is merge it to soap ?
> > Is not it so :
> > http + xml= soap // ?
>
> We do not have any libraries which gives such support directly but
> usually it's not big problem to create necessary code using existing
> Harbour libraries.
> Anyhow I do not have big practice experience here so I'm not good
> person to answer.
> In some spare time I plan to create mod_hb for Apache HTTP server.
Now I have some work "in workl" but then try to transform/rewrite Mindaugas
HTTP serwer from cotrib to SOAP serwer.
I do not know whether it will succeed - but theoretically it should.
SOAP - it is send xml via http protocol.