[Devel] web interface development

[Arek Bekiersz]

Hello Mike,


Thanks for productive discussion.
Please see my answers inline:

----- Original Message -----
From: "Mike Williams" <mwilliams at ETC1.net>
To: <arek at perceval.net>
Sent: Wednesday, January 25, 2006 6:42 PM
Subject: RE: [Devel] web interface development


> I do envision a SOAP/XML interface in the future. However, I do not think
 > that XML to HTML transformations are necessary; to me it seems to be
 > best that multiple points of entry and exit be defined. For instance,
 > user canbrowse to index.php, which sets the output and input engines
 > toXHTML kind.

AB: Well, there is a lot to discuss about... System is made in PHP5 and
some code in C in SER . It is centered around Web Services, build with
standards like SOAP, WSDL and UDDI. A good primer to all of this "Web
Service" stuff are O'Reilly books "Web Services essentials" and "SOAP".

1. SOAP usage:
System can be seen on attached drawing. Well, there isn't much more. No
extreme programming, no complicated modeling.. It is only a bunch of XML
documents flying one way and the other and a solid yet simple
XSLT portal build in PHP5. Basis of this are Web Services, divided into:
subscriber management, gateway management, terminal management, billing
(based on IPDR standard from ipdr.com).

An added value from having Web Services runing in core of the system is
that they can also be exposed to partners or cooperants, wanting to
build their own Web portals. They only connect to our Web Services and
voila - they do what they want, provided that access rights are OK. They
just need to talk to me using SOAP.


2. Databases
As user profiles, preferences, user groups as well as gateway and system
information is stored in Ldap, SER uses Ldap. MySQL is used only as
simple location register and temporary accounting.
Web Services engines need also to access LDAP, to create new users,
handle profiles and so on. They communicate with LDAP either directly
via Ldap (using PHP5 native Ldap functions modified to be more
effective) or via DSML language I tried to implement DSML 2.0 here to
talk with LDAP backend.

But due to lack of good DSML 2.0 support I decided otherwise. I use DSML
1.0 access to Ldap, with some additional PHP-native Ldap functions.
DSML 2.0 woudl allow for more free modification of Ldap dbase, but only
few implementations (libraries) for DSML 2.0 exist. There is some by
Netscape (http://www.mozilla.org/directory/), but I lost interest in
this right now as I use DSML 1.0.

This was for "middleware" SOAP layer.


3. Presentation layer.
In the contrary, there is huge support for DSML 1.0, for example in
Java. In fact I use DSML 1.0 tools not only in backend, but in view
layer as well. This layer is responsive for creating dynamic forms for
Web Services methods (from WSD ) as well as displaying results of Web
Services. It also displays menus, search bars, etc - all using DSML and
XSLT.

The resulting HTML code is rendered *directly* from WSDL or SOAP using
XSLT transformations. After applying CSS2 it is displayed in user
browser. You can catch the glimpse of this idea by checking following
addresses:

http://www.soapware.org/bdg
http://www.brics.dk/~amoeller/XML/
http://www.vordel.com/news/articles/02-03-08.html
http://www.w3.org/Signature/
http://www.w3.org/Encryption/2001/
http://www.aleksey.com/xmlsec/xmldsig.html
http://www.xtradyne.com/products/ws-dbc/soap-security-intro.htm
http://nwalsh.com/docs/tutorials/xsl/xsl/slides.html
http://www.brics.dk/~amoeller/XML/transformation/index.html
http://www.scottnichol.com/soap.htm
http://www.devarticles.com/c/a/PHP/Building-XML-Web-Services-with-PHP-NuSOAP
http://sourceforge.net/projects/nusoap/
http://www.nonplus.net/geek/000752.php
http://xml.coverpages.org/
http://www.oasis.org
http://www.xslt.com/
http://www.jenitennison.com/
http://xmethods.net/ve2/ViewTutorials.po
http://xmethods.net/ve2/ViewImplementations.po

There are also working examples of similar portals as mine, built
entirely in XSLT. I have bookmarks on my office's computer. In addition
to this I can also send you some example screenshots of our system tomorrow.


 > From what I understand of SOAP (which is not very much), it is
 > messaging system.

AB: Well, not only that. It also defines interfaces of remote
application's methods (thus enables early type checking and easy
integration) and via UDDI mechanism it can expose remote application's
methods to other applications.
Those applications need not to know how exactly remote Web Service is
build, until they conenct to it (so called "late-binding").
Most interesting feature is still the fact that it is XML based. Thus
you can build a Web form dynamically from WSDL description of Web
Service. When user enter data you can validate his input (because you
have type information and enumeration values listed in WSDL). Then, you
send this data to Web Service SOAP engine and get some result - also in
form of XML (Soap Body with or without Xml body). This result can
contain simple data, tables, structures, nested data or even
files, images or MIME attachments (as in Soap MIME standard). You then
just display it on user screen, by processing it thru XSLT first.


> Access to another page, say soap.php, would allow SOAP request.
 > Additionally, a daemon could listen on a port for yet another form of
 > communication. To me, the view layer should just be given data, how it
 > presents and formats it should be a extensible architecture. Please
 > let me know if this doesn't make any sense.

AB: Of course you are right. But the difference in our views is that you
want to enableWeb Services and SOAP as one of possible 'plug-ins' in
some other, more rigid architecture built in yee-olde PHP. When I want
to build whole thing around Web
Serivces and SOAP and yee-olde PHP is only a tool.
You must remember that Web Services are one of the bigegst revolutions
of last years. They are language independent (PHP, C, Java, .NET C#) so
entering whole new world of integration possibilities. It is not
desirable to write a monolythic Web SER management portal in PHP and
then enable this or that as a plug-in. It is far more desirable
to specify architecture of Web portal in terms of of Web Services (so:
functions, what they do and their interfaces) and then
write it in this or another language.If this happens to be PHP5, OK for
me. But it could as well be C and SER module,
using gSOAP library.



> As for a secure SOAP engine, I am not totally certain I understand what
 > you mean.
AB: I just mean Web Service build with SOAP that uses XML Encryption or
XML Digital Signature to transmit safely XML messages in open text. No
need for TLS (HTPS) anymore.


I see an architecture where different SIP objects interact with each,
executed by each command in turn, and then the combined end-data, stored
in a Context object, would be passed to the view layer, to be presented
in whatever form it chosen. Another layer would be responsible for
storing and loading the domain objects. In this instance, LDAP could be
supported as one method, SQL as another. Again, I think a pluggable
storage model would work best, as the types employed are widely varied.

AB: Yes, I agree. Current version has Ldap backend, but previous ones
had MySQL. It is just the user choice which backend he wants to use for
Web Services (where the user, domain or system data is stored). It
happens that I think that MySQL SER architecture is totally not
scalable, that's why I moved to Ldap. Look how Iptel's SER developers
struggle in version 0.0.10 to have virtual domain support and other
things. But this is only my opinion, people will choose.

CONCLUSION: I'm observing some European projects now. Tendency is to use
Web Services (SOAP) everywhere where possible. Look at Parlay X Web
Services 2.0 at www.parlay.org. I think this is what future brings:
independent from language, platform and operating system. Nobody will
say that "this PHP5 code on Apache with Apache struts works on Linux, 
but another does not work on MS Windows". We would be platform 
independent and integration will be fast.

When you look at company-to-company electronic integration, electronic 
document interchange and business process integration, secure Web 
Services this is what European Commision is pushing to. Believe me, I 
see european projects doing exactly this.
What is more - when you want to implement business process integration 
in future, using some sort of business process languages like BPEL or 
WSFL, they are also Web Service based.

Imagine your partner uses your system to build his own branded VoIP 
service. He gets new customer from his Web Portal. He contacts you via 
SOAP and launches your Web Service function 
addSubscriber(parameters,credentials). You then:
1) Add this person to subscriber dbase
2) Change this persons preferences to defaults
3) Change its personal data
4) Add subscriber to your billing system
5) Create tariff for subscriber on billing system
6) Send message to partner confirming the actions.

Imagine now that in every ov above 6 steps something can go wrong and 
you have to roll-back and inform about fault. You cannot do it without 
having stateful business process manager. And you need every of those 6 
elements to be Web Services.
There is no another way and I repeat - know at least one European 
research project that says the same.




> I agree that your concept would be very interesting to investigate. Would
 >  you mind providing more information about the types of services you
 > provide, how you developed this system, what architecture it is built
 > on, what problems you encountered, and so on?
 > Does anyone have a problem with this system being developed in PHP? I
 > have the majority of my experience here, and I think it would be well
 > suited to a web-based project.

AB: This can be done in PHP5. Using libraries as nuSOAP or PHP SOAP,
Sablotron or PHP XSLT it is easy to do in PHP.


--
Regards,
Arek Bekiersz

mailto:arek at perceval.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Simplified.jpg
Type: image/jpeg
Size: 42706 bytes
Desc: not available
Url : http://openser.org/pipermail/devel/attachments/20060126/7c797e10/Simplified-0001.jpg