Topic
Table of Contents



Status

* Some experiment with egs and weberp, starting with debtorsmaster table for integration.
* There is also some activity for integrating POS systems with nusoap interfacing.

Goal

Getting confirmed if this it the right architecture (webservices) and tool for integration other software with WebERP.

Description


Implementation Options


Advantages


Disadvantages


Planning


Discussion developers list

The only thing I've had against Soap was that it was a little bulkier - though also more structured, I believe, than xml-rpc. Essentially, as the last link you sent points out, they are both xml based protocols.

You are correct that if we really intend on allowing interoprability with other systems, Soap is the more standard choice. One thought regarding this is whether we should consider using the least common denominator since it should be easier to make and xml-rpc based system step up to soap (or be wrapped with something like nusoap) than the other way around, or simply say "soap is what we're using, deal with it".

I think we all realize alot of specs, functional requirements, etc need to be ironed out before any of this has any real meaning. It would be ignorant of us to build the foundation without a firm grasp of what it actually will need to support.

good discussion, thanks.


Original Message
nusoap looks really simple. Please study
http://www.zend.com/zend/tut/tutorial-campbell.php

I guess that you are right that xml-rpc is easier to implement but I think
that soap already has the biggest market share to be the standard for now
and the future. When this statement is true, then is soap a better garantee
that we serve more applications which want to be integrated with weberp.

But I would already be glad when one of them will be used to integrate other
applications, because it is much better then mission impossible moving
everything to the same programming language and the same database engine and
write for every case different code.

I guess that your xml-rpc is described at:
http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-soap.html


Original Message

Thanks. Soap actually worries me more than more simple implementations
like xml-rpc. I've had many thoughts on various ways these things can be
useful, but not the time to sit down and really flesh them out. Hopefully I
can do that soon.


Original Message
The wddx and xml is a very interesting subject.

There are plans to setup a demo with nusoap for webERP, EGS, XCRMS and
eventually oscommerce.

The current integrated fork of weberp and egs might be a leading role how to
implement the nusoap solution. That will save us design time for the demo.

For me would be the first step to integrate the debtormasters address data
with the help of nusoap.

The idea is to create one nusoap layer for weberp wich enables to integrate
smoothly a crm application of someones choice without changing the nusoap
layer. In this demo, we should be able to choose between xcrms and egs.

When this is a success, then I guess that it would be very interesting to
integrate oscommerce with weberp and one of the crm applications.

An example of nusoap is:
http://www.zend.com/zend/tut/tutorial-campbell.php

It really looks like very simple.

After the demo we can evaluate it and start any discussion for contributing
the nusoap concept to weberp.

I really think that it is a concept which will saves us lot's of
development and support time for integration with other software
packages.

Or do you have another opinion about this?

Some do not like xml, because it is technically not very efficient but for
me is the development speed also very important when we needs sometime to be
competing with SAP, peoplesoft, ....


Original Message

I have thought about this, my reasoning for going against the wddx for
implimenting database configuration storage is that we are already agreed
that we would like to do some XML data exchange with other applications (at
least thats how it seems to me). To this end we should probably have a
standard for exchanging data (of any part of the system) with at least a Low
and High level api. To make things easier when we get to such a definition
of
api I decided to use standard database tables/fields where possible. This
would allow for any type of api, including working/reporting directly
against
the database. ( I will create some libs for FreePascal and C/C and Python
against that api)

I feel we need to do some planning before we implement the api. I know I
suggested the wddx, because I want to have a easy interface to data, however
in the long run we could probably do more not using wddx in the core where
we
don't have to. I do like wddx as an data exchange medium though, as long as
it's well thought through; Nothing sucks more than a bad xml implementation.

It would still be hard for the user to edit xml (errors could bring the
system
down) and therefore script interfaces to edit the data need to be created,
which I am doing. So why not keep the underlying system in tact and working
the same way the system does now. Almost the same amount of work is required
either way, at least this way we are not preempting the api. I will make a
concession though, I will use xml/wddx for storing the arrays because a hash
list (key/value pair array) is easier to store that way, its a very
readable/editable format (in db directly), but a flag will indicate that it
is stored in that format. I might be wrong in that there might be some
easier
way still. I am trying to limit the hits to the database to just one query
and then storing static type config data in the session to limit the data
being queried. Data that is liked into tables will however reside in
seperate
tables, mostly for refferencial reasons where reporting is concerned.

I think the api stuff should come after version 3 (going on thoughts
previously mentioned here in the list), also I need to think quite a bit
more
on what I want to do with the api and I am sure the whole team has their own
requirements too. The wiki is probably the best place to just get a roadmap
going for what we want in an api, something like a suggestions page for
functionality. And then there is Phil "the voice of reason" (said with
appreciation) who will keep us focused.


Original Message
You are correct that we should be able to un/serialize with any db -
basically all it would do is store text in a db field - that is the same
way wddx would work if that's all we were concerned with.
The advantage of something like wddx would be in passing serialized
versions of data between various programming languages or between
applications/webservices/processes/etc. It goes a step further than XML,
though, in that they are providing an SDK for the functions that are used
to go from wddx to native language data structures and vice-versa, which
would remove some of the complexities that would be involved in doing that
with XML (dom parsers, xsds, xsls, etc. depending on how anal/code
generator dependant the user is - and I'm not taking shots at anyone, I've
done both).
A review of their faq would probably bring out many other things and
explain the things above further: http://www.openwddx.org/faq/.


Original Message
un/serialize & wddx both encode data and both encode it into what are
essentially strings. Since wddx is xml based, it is generally more
readable and probably creates a larger 'data footprint' when it encodes,
though none of that is really applicable. The transport mechanism is
also not wholly important it could be via files in the filesystem, sql
dbs, server-to-server communication, etc.

The real differences here can be realized by looking at how you are able
to work with these strings from various languages. Simply put, unless
someone has built/builds un/serialize functions for several other
languages, those strings are going to be fairly useless in other
languages. On the other hand, wddx has libraries for its functions
available for many popular languages (javascript, php, m$ stuff,
more...). For it's part, un/serialize can handle php objects, which wddx
can not help you with.

In regards to anything we are currently discussing, especially this
config system, I think wddx would be out of place for many reasons
(complexity, db integrity). I see from Danie's recent message that he
has settled on some similar way of approaching wddx and the immediate
task.

Original Message
I have not used serialize or wddx and don't currently have time to dig
into it too far or try a bunch of it out. I think it's great that
wddx takes care of the xml layer for you on the way in and the way
out. However, I'm under the impression that serialize encodes the
data structure in the "same" way wddx would. Maybe that's where the
difference lies. While serialize would use an internal
representation, xml will put it in a form (text really) ready for easy
transport and use in other applications no matter what they are
written in and where they are, using web transportation.

Am I getting it?

parsers, xsds, xsls, etc. depending on how anal/code generator
dependant the user is - and I'm not taking shots at anyone, I've
done both).

A review of their faq would probably bring out many other things
and explain the things above further:
http://www.openwddx.org/faq/.


Original Message
What is the advantage of storing complex variables by wrapping in
xml using wddx as opposed to just using serialize and unserialize?

I think we can store and retrieve arrays, etc. using serialize in
all databases...
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki