Home
The Toolkit for Online Communities
17607 Community Members, 0 members online, 2636 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : SOA? - Generic XML-RPC Bridge to Database API

Forum OpenACS Development: SOA? - Generic XML-RPC Bridge to Database API

Icon of envelope Request notifications

Hi All,

I just wanted to announce that we (]project-open[) are going to publish very soon a generic XML-RPC bridge for the database API. Please find the details below and let us know what you think. We've are still in an advanced planning phase, so there is still some room to influence our design. The package will be licensed under GPL V2.0.

SOA:

There is an incredible hype around this little acronyme ("Service Oriented Architecture") these days. Both SAP and Oracle are rewriting (or at least pretending to...) their applications to support this concept.

To me SOA means a kind of "component architecture" for web services (WS). You have "components" (WS) and you've got "glue code" (scripts, XML routers, Workflows, MS-BizTalk, ...) that connects the different WSs amongst each other and impose a certain business logic and some sequencing.

So given this definition (please let me know if you think I got it wrong), we'd propose nothing less then a complete "SOAization" of OpenACS / ]project-open[. Using this interface, any external application with the right credentials would be able to integrate with and "remote-control" an OpenACS instance.

SOA might imply SOAP as a communication protocol (Does it? It's become just such a fuzzy term), so somebody might argue that our XML-RPC-based approach isn't really SOA compatible. However, we could easily create a SOAP-version of our generic interface in the future. Any opinions?

Interface Requirements:

During some recent customer surveys it turned out that "integratability" was #1 inhibitor for our potential ]project-open[ customers. Our customers frequently have legacy systems written in MS-Access etc. that need to read from and write to ]po[. So they are preoccupied by the integrated approach of ]po[ and need to be reassured that there applications will continue to be supported.

On the other hand there is usually very little budget available while most of our customers are not very "IT-sophisticated". So the integration needs to be easy and transparent (easy to debug).

Interface Generic Architecture:

Normally we'd need hunderts of different XML-RPC calls in order to access and modify the hundereds of object types in OpenACS / ]project-open[. However, after some discussions we've come up with the idea that OpenACS is really just a database (objects "live" in the DB, instead of "living" in the memory). So we'd only need four different API calls to access any type of object:

- "LOGIN": Authenticate and generate a session key

- "SELECT": Retreive the fields of an object from the database

- "UPDATE": Modify the fields of an object

- "PLPGSQL": Execute a object__new() or object__delete() procedure to create and delete objects

The integration with our "DynFields" (formerly known as "FlexBase") metadata model allows us additionally to access fields in "extension tables". For example we've got a table "im_employees" in ]project-open[ that contains payroll information for users of type "employee". Fields in this table are automatically selected and updated with the XML-RPC calls.

Interface Communication Protocol:

We've been looking at all three options for the interface. We have finally decided to go with XML-RPC, because it is the _easiest_. Here are the details:

- XML-RPC is the oldest XML-based interface standard. It's been kind of deprecated with respect to SOAP in the last years. However, it's much easier to use then full-blown SOAP.

- SOAP is the standard today for XML-based communication. In particular there is the cool WSDL feature that allows yout to meta-describe your communication protocol in XML, so that the usual tools (MS, IBM, ...) can automatically create proxies/interface objects for the SOAP messages.

- REST is a cool newcomer these days. The main difference to SOAP is that related objects are _reference_ (included as URIs in the XML text) instead of _embedded_ (included inside the XML document as subobjects). In REST every object (user, forum item, ...) has its on URI (a slightly generalized type of URL).

Interface Security:

We're sticking with HTTP over SSL ("HTTPS") for security. For authentication we're probably going to use a session key that is generated using the "LOGIN" message.

Dependencies with ]project-open[:

We'll try to keep the XML-RCP-Bridge free from dependencies to ]po[.
The main issues is the "DynFields" SQL Metadata system which hasn't been included in OpenACS yet. However, we've mainly going to use the table "acs_attributes" to extract information about "extension tables" and dynamic attributes, so you could edit the contents of this table manually without DynFields.

As said in the into, we've already taken some decisions (XML-RPC and the generic interface idea), but everything else is still flexible.

Cheers,
Frank

frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/

We did something similar at Galileo, is a SOAP implementation to run any query through SOAP, and get the results in the client, an manipulate those as you usually do with the standard db_* API. I've been wondering if the community will be interested in something like this....
Collapse
Posted by Torben Brosten on
Hi Frank,

I've been considering a general wsrp service also.

As I see it,

1. the service should use openacs authenticate and permissions (via http/https) before executing a call and/or screen based on ip and a hash, etc etc.

2. the call should be to a tcl API instead of db_* so that values can be easily customized to meet requirements that would complicate db_*, for example to allow general audit features to work (since ecommerce packages use them and this is wsrp).

3. there would be a table mapping "allowed" calls to specific protocol access and openacs tcl api (all other requests are refused and optionally logged).

4. there would be different urls within the package for different protocols, for example: soap, xml, cgi, and other third party standards (such as legacy ones). I think this approach would largely prevent the splintering of services into innumerable packages, as is possible with OpenACS on the client side, at least when using payment-gateway which requires another package for handling each protocol (currently either ezic-gateway or authorize-gateway only).

5. the package would be.. package aware so it could be mounted any number of times in any number of places and provide different services to each.

I'm also open to suggestions..

Collapse
Posted by Daniël Mantione on
Install the PostgreSQL ODBC driver and you can integrate with MS Access at the SQL level. Add a single extra layer and you can only integrate at the Visual Basic level.

Usually the simplest option is the best one.

Collapse
Posted by Frank Bergmann on
Hi,

Just a few answers/comments:

> Install the PostgreSQL ODBC driver

This is basicly the idea of the interface: Document the PostgreSQL API once and use the documentation for both, direct ODBC (LAN) and WS (Internet) access. This is why I've called the package a "bridge" (-> OO bridge pattern).

> run any query through SOAP

Hi Roc, that sounds very interesting. Could you provide us with the source code? It would be nice if we could offer both SOAP and XML-RPC. I'm not sure whether we'd integrate it "Phase 1", but we'd definitely adapt the design of the package in order to be extensible.

> 1. the service should use openacs authenticate and
> permissions (via http/https) before executing a
> call and/or screen based on ip and a hash, etc etc.

Hi Torben, that was our idea as well. There is a security token scheme from some bulk mail package from Malte Sussdorff that we'd use. So the user would authenticate once against OpenACS auth, obtain a hashed auth token and execute multiple calls with this token. The only issue with this is that the token has a unlimited livetime today. We might have to change that...

> 2. the call should be to a tcl API instead of db_* so
> that values can be easily customized to meet
> requirements that would complicate db_*, for
> example to allow general audit features to work
> (since ecommerce packages use them and this is wsrp).

Right, we're using the TCL API already for our prototype. Also, we need to extract fields from "extension tables" as defined in acs_attributes, so we had to discard early the use of the db_* interface.

But I don't understand the "audit" thing and how that relates to ecommerce. Could you elaborate, please?

> 3. there would be a table mapping "allowed" calls
> to specific protocol access and openacs tcl api
> (all other requests are refused and optionally logged).

Do you refer to introducing permissions, similar to the ones of the PostgreSQL database user? Maybe read and write permissions per object? That's an interesting idea. We've only been considering a all-or-nothing scheme until now.

> 4. there would be different urls within the package
> for different protocols, for example: soap, xml, cgi,
> and other third party standards (such as legacy ones).

Right, that was our idea.

> prevent the splintering of services into innumerable
> packages

I think I understand. So the extensibility towards SOAP would probably be the first step towards such a "unified" architecture, so we're back with Rocael and his SOAP interface.

Thanks a lot for the feedback so far, I really appreciate it.
Frank

frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/

Collapse
Posted by Torben Brosten on
Hi Frank,

The ecommerce auditing feature basically tracks changes that users and admins make to editable data, see: http://openacs.org/doc/ecommerce/audit and a discussion on making this service available to any package or user action: http://openacs.org/forums/message-view?message%5fid=456993

You ask: Do you refer to introducing permissions, similar to the ones of the PostgreSQL database user? Maybe read and write permissions per object?

The mapping/filtering would be in addition to any permissions that are implemented at the url level and object level (including checking for read/write/create/delete permission on a called object before taking action on it).

Creating a general service has the potential of making the website vulnerable to complete tcl api access in a manner similar to how developer-support provides tcl api access to admins, or user input fields are vulnerabilities for certain attacks by blue meanies etc. If there will be any user-level or package-admin level configurable services (which saves having to hard code each one), then there needs to be a way to screen calls before they get processed in any way --similar to how html and html attributes are screened in user input now.

Collapse
Posted by Torben Brosten on
Frank, you write:

"..The only issue with this [item 1, authentication] is that the token has a unlimited livetime today. We might have to change that..."

I imagine implementing a hash that works similar to how the session cookies work, where a component of the hash requires re-authenticating after a certain period and it ties in to existing session procs.

Since this is between machines, maybe it could use the shortest of the session intervals, SessionRenew (or a combination of SessionRenew and SessionTImeout ) in the kernel parameters etc.

Anyway, I'm not certain of the details beyond this.

Frank, I love the basic idea of SOA'izing OpenACS. Not because of the "SOA" buzzword - I don't care about that - but because this sort of flexible remote programmatic control can be hugely useful. However, this statement worries me:
We've come up with the idea that OpenACS is really just a database [...]

The problem is that although the above is a useful metaphor and guideline, it is nowhere near 100% true of OpenACS in practice - nor should it be!

For example, look at how user creation is handled. Last time I checked, the Tcl user creation procs call a whole bunch of different helper procedures, in an entirely non-obvious fashion. There is an underlying simple-looking PL/SQL object-like API, but in fact it is not sufficent, it only does part of the work. Correctly creating a new OpenACS user is totally dependent on calling the correct Tcl proc. Now, that particular example could probably be alleviated by refactoring the existing OpenACS use creation code. But there must be many other examples. E.g., cacheing. Sooner or later, your XML-RPC SOA stuff is going to need some way to say, "Change X, and then please also flush the corresponding cache Y."

Non-trivial real-world integration with remote systems is going to require access to the OpenACS Tcl API in some fashion. Access to merely the PL/SQL (or plpgsql) API is not sufficient.

Moreever, it would probably be a bad idea to make the PL/SQL API sufficient! At least arguably, the gratuitous over-dependence on PL/SQL introduced in ACS 4.0 is one of OpenACS's core weaknesses - and OpenACS hackers much more expert than me seem to think so too.

Ideally, going forward I would like to see a complete, well-factored Tcl API running in AOLserver, which uses PL/SQL only where specifically useful, with no attempt to give the PL/SQL API full coverage. (I suspect Gustaf has some thoughts and has done some work along those lines, perhaps from a relatively XoTcl-centric angle.)

SOA-style programmtic control would then logically hook into this clean and comprehensive Tcl API. However, there's no reason you have to implement one before the other, you could build in some sort of general SOA Tcl interface now, use that to write whatever ad-hoc SOA functionality you really need right now, and then only later revisit a refactoring of the underlying OpenACS APIs. Indeed, getting SOA to work out in the wild, on real-world projects, would probably give you a lot of ideas about where and how you'd like to improve the OpenACS APIs in the future.

Also, above I repeatedly say "Tcl API" because that happens to be what OpenACS uses, but in this context Tcl is largely incidental - what I'm really talking about here is OpenACS's "application server API", and for better understanding, that's probably the term that should be used when talking to outsiders.

If OpenACS actually needed to support another in-process programming language, defining bindings for it to the canonical Tcl-based app server API would be pretty straightforward. But of course, such multi-language support is much harder and messier if you don't have a really good and clean canonical API - which is basically the current de facto situation in OpenACS.

Note, semi-related, the zipfile of the old code I posted back March 2005 to allow a client AOLserver to login under SSL to a remote OpenACS server is still available on my website.

Collapse
Posted by Jade Rubick on
Our forthcoming SOAP / WSDL package will expose arbitrary Tcl procs to external SOAP invocation.

Will be released some time soon..

Collapse
Posted by Frank Bergmann on
Hi,

First of all thanks for the great feedback. There are many consideratations that we'll include in the design.

Torben wrote:
> Creating a general service has the potential of making
> the website vulnerable to complete tcl api access in a
> manner similar to how developer-support provides tcl api
> access to admins, or user input fields are
> vulnerabilities for certain attacks by blue meanies etc.

I guess you're right. However, a simple, all-or-none version of the package would be reasonable first step in a project with several phases, wouldn't it? We'd have to make sure thought that we can reasonably introduce suitable permissions later. The first step for us is to connect with some trusted 3rd party applications, which would get full access.

One simple way could be SELECT/UPDATE/INSERT operations per _object_type_ (not per table). With DynField we've got a mapping anyway from object_type to tables, so there would be no issues with using object types in the API. Then you could add permissions per user group and object type. That's quite easy, performant and consistent. What do you think?

> I imagine implementing a hash that works similar to how
> the session cookies

Right, that's the way.

Andrew wrote:

> > We've come up with the idea that OpenACS is really
> > just a database [...]
>
> The problem is that although the above is a useful
> metaphor and guideline, it is nowhere near 100% true
> of OpenACS in practice - nor should it be!

Hi Andrew, I see you point. However, we're probably still going to go that way. That's because it's "low hanging fruit". It will probably take us some 2-3 days to implement the entire f... API for about 80 different object types. It would take us weeks and months to do it on the TCL API level. Also, we've based ]project-open[ pretty much on the database, and all of our main objects are perfectly accessible on the DB level.

So I guess we will have to stick with the SQL and PlPg/SQL access if we want to get a moderately complete API. Also, there would be an incredible _testing_ complexity with a TCL API, because TCL and the API are dynamically typed, and any integrator would get zillions of little issues (or do you have an idea for efficient testing with a high coverage?).

However, we could design the API so that we could deal with exceptions such as your "user" case. We could catch these exceptions (asuming that there is a finite number of them!) and "redirect" them to a TCL function. What do yo think?

> could build in some sort of general SOA Tcl interface
> now, use that to write whatever ad-hoc SOA functionality
> you really need right now

That's not an options for use, because it's our customers who demand a complete interface, so that they can write their own integrations with their own team.

Maybe I'm a bit simplistic, but I had to learn the hard way that 80% solutions win (and what part of OpenACS is not an 80% solution?), because they're the only ones that get implemented in a limited amount of time. I really like the "Make simple things easy to do, and make hard things possible" approach. Atleast this API is going to be working and to be quite complete...

Bests,
Frank

frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/

Collapse
Posted by Andrew Piskorski on
Frank, your arguments and plans sound basically reasonable to me. Beyond that, I haven't studied these issues enough to have any more ideas. Since obviously you have, I'll just assume you're on the right track. ;)
Collapse
Posted by Frank Bergmann on
Hi,

We've finished the first (reading) part of the implementation. I would be very interested in your feedback.

Documentation is available at the url below. Also, there is sample XML code for requests and replies:

- http://www.project-open.org/doc/xml-rpc/

A running demo is available at:

- http://pcdev32.dnsalias.com/. Please login as "Ben Bigboss" and then select the "XML-RPC" tab for the demo. The "Select Test" is actually working already, while the "Call Test" (calling PlPg/SQL procedures) is still in the making.

The source code is available at:

- cvs -d:pserver:anonymous@berlin.dnsalias.com:/home/cvsroot checkout intranet-xmlrpc

I hope we'll finish the the remaining stuff until the end of this week. Please let me know is you intend to use the stuff.

Cheers,
Frank

we'll commit our soap DB stuff this week during the bug-stomp!
Collapse
Posted by Don Baccus on
Well, this is shaping up to be a classic OpenACS scenario.

Several people talking about committing packages to do similar things, thereby complicating our code base and giving future package implementors arguably too much choice.

Is there any reason why we shouldn't work towards one solution to be included in the actual OpenACS source tree?

I love having people jumping up and offering their code to the public, that's great, of course, but how many ways to dot one's "i"s and cross one's "t"s should we implement in the toolkit?

We have our stuff working for months at our production site, will be good if other take a look a see if they wanna use it. We'll happy to support and use an official tool.
Anyway, ours is relatively simple and focused on just passing the queries to the other side and get results back!!!
Collapse
Posted by Malte Sussdorff on
I can only second Don here. Could Rocael and Frank please exchange the code and figure out a best of breed merge, which will than make it into OpenACS proper, maybe having a discussion first how their approach is different.

It is really great to hear, but I know that there is yet another organization supposedly working on this and now we have a TCL standard for it as well.

Last but not least, we will have to integrate part of our TCL functions and database tables in project manager as webservices into a mobile framework. So we would probably end up using both Rocaels as well as Franks approach. Though, before anyone get's their hopes up that we will do it, nothing is confirmed and development would not start before 2007.

Collapse
Posted by Jade Rubick on
I think what we should do is have the core team look at the implementations and decide which to include as the standard for OpenACS.

We're planning on making it this easy to export a Tcl proc to SOAP:

ad_proc -public -soap mynamespace::myproc {
set foo bar
}

We have the server side completed and are testing it now, and most of the infrastructure for the client side as well.

Jade

May I wish that the OCT takes a look at the *features* and says which it likes best and then hopefully between the three of you, you could mould it into one nice and neat package, that suits all your needs?
Collapse
Posted by Brian Fenton on
Does anyone know the current state of affairs with XML-RPC support in OpenACS? I have a job which may require XML-RPC support so it would be good to know if all of the solutions mentioned here are still supported before I quote for it.

Any info would be greatly appreciated,

thanks
Brian

Collapse
Posted by Frank Bergmann on
We wouldn't even have started with our own stuff here if there would have been some previous work. So yes, that's a pitty. But maybe "competition" is rising the spirits (and code quality) on all ends?

However, SOAP and XML-RPC are very different protocols and known web services such as the one from Google support both protocols, and even REST as a third one. Also, there may be differences in the priorities and scope. For example, we had to "reinvent" full-text search and filestorage for ]project-open[, because the existing stuff was completely unsuitable for us.

Another option is to keep our stuff private and sell it as a proprietary package. I've got no problem with that either... :--)

So Roc, I'm really curious to see your code. Could you please send me the current version as soon as possible? Maybe we can still stop the development here and adapt your stuff.

Bests,
Frank

frank_dot_bergmann@project_dash_open.com
http://www.project-open.com/

Collapse
Posted by Nick Carroll on
It might be worth noting that you can do cross-domain XMLHttpRequest calls (ajax) with a web proxy. Yahoo shows you how, and provides code for a simple web proxy.

http://developer.yahoo.com/javascript/howto-proxy.html

For some cases this approach may be better than web services.

Collapse
21: soap-db (response to 1)
Posted by Rocael Hernández Rizzardini on
Ok, the package is called:
soap-db, is on cvs now.
Basically it allows you to perform queries in a db_ style, send it to a soap server, and operate in the callers environment the results in the same way you do with the normal db_ API.

soap-db is the client API that mimics the db_ API.
This allow you to connect to any database without the need of having specific drivers for aolserver.

Also, there is a server API implementation for openacs as well, the working code we use is here:
http://cvs.openacs.org/cvs/openacs-4/packages/soap-db/tcl/example-soap-procs.txt?rev=1.1.1.1&view=auto

You need to have installed tsoap package, plus for the server side you'll need the soap-gateway (which allows you to expose oacs procs to soap).

The original design was mine, the development was done by derick at galileo.

We have been using it in production for quite a while without troubles.
The only thing that we cannot handle yet is transactions (like db_transaction), the best approach we use is to substitute that to a complete SOAP proc call that in the server side the proc should handle itself the transaction.

Collapse
Posted by Frank Bergmann on
Hi Roc,

I briefly checked out your code and it looks great, obvious! Unfortunately, it is quite OpenACS-centric. Or do you have an example of an external application (.Net, Perl, ...) accessing the service?

Also: I don't see how we would impose fine-grain security policies with your system. We need to be able to restrict read/write access to certain object types. For example, an external Microsoft timesheet application should be able to read "Projects" and create and modify "Timesheet" objects, but should not be able to read financial documents nor human resources stuff.

So I've got my doubts whether your package allows us to reach our goal: Provide system integrators with the easiest possible option (shortest code in Perl RPC::XML) to connect their existing systems with ours.

Or do you see an option to integrate our needs into your package?

Cheers,
Frank

The package is oacs centric in the sense that it runs queries through soap and expects a return in the same form that the db_ API will return it internally, therefore you can use stuff like <multiple>> and list-builder in your site even running queries through soap.

Although we don't have non-oacs examples for the server API (the one that will be running the queries, and returning them in a db_ way), I'm pretty sure you can build it any soap server-language environment.

Fine-grain security policies was not the goal of this package, first due our project goals, that was to run queries in this way, within an internal-secure-restricted network. Since this package does what it is meant to do, you might be able to build a top of it the security policies, in the same way that db_ API does not inherently check them but other procs does.

Collapse
Posted by Jade Rubick on
Hi Frank:

I think our package may fit your needs -- it's not OpenACS specific, and it allows you to only expose the procs you want.

I like Roc's API, however. Tying the client side to the db_ api is a smart idea.

Collapse
Posted by Wolfgang Winkler on
Hi Jade!

Is there already a test version of your SOAP/WSDL Client-Server? I need a decent SOAP implementation in the next weeks and my options so far are TclSOAP or, preferably tsoap or java. But I'd like to see your package as well.

Collapse
Posted by Jade Rubick on
Hi Wolfgang:

I'll ask Tom to respond.

Collapse
Posted by Tom Jackson on
Wolfgang,

Jade asked me to report the status of our project, tentatively called tWSDL.

The first thing to keep in mind is that this project is completely independent of OACS, maybe more important: there are no additional dependencies beyond using AOLserver and tDOM. Parts of it run with tclsh, most runs with libnsd loaded, the client side will likely be completely independent of AOLserver (maybe not independent of libnsd).

WSDL is a step beyond XML-RPC and SOAP. WSDL is more like a data model for a service. An important new feature is that WSDL defines message types. By defining types, WSDL enables type checking prior to invoking a procedure. The same information can be used to figure out how to construct messages, where to send them, and how to validate the result.

Unfortunately Tcl doesn't specify types, so there is a little more work required if you want very good type checking. On the other hand, Tcl's very simple (and few) data structures makes it easy to model a procedure call and result in XML Schema.

Speaking in OACS language: WSDL is like a page contract, where you can equate a page to an WSDL operation.

WSDL could potentially cover a huge number of implimentations. However, tWSDL is first restricted by the WS-I Basic Profile. This means that the basic protocol is SOAP/HTTP using document/literal, plus a few hundred other restrictions. (Literal is required, tWSDL may end up supporting rpc/literal). These choices greatly reduce the complexity of XML processing. Third parties can add their own protocols, by adding a routine which processes a small slice of the request. Note that collections of operations, called 'portTypes', are completely independent of the protocol, so everything below portTypes: operations, messages and types never change if you add a protocol.

So what do we want to be able to do with tWSDL?

Server side:

- It should be possible for the developer who knows zero about WSDL/XML/SOAP to easily create a service based upon a Tcl procedure.
- It should also be relatively easy to create a service which enforces type checking on the input and output documents.
- More advanced developers should be able to construct services which can process and produce XML documents at the complexity of, for instance, an invoice or sales transaction.

Client side:

- A tWSDL client should be able to read a WSDL file and create a client Tcl API.
- Client code can then use the new client API to invoke the service.
- In the simple case, a single call to a client API will return a Tcl result.
- In more complex cases, client API's will construct an XML document, then invoke.
- Client will have full ability to validate outgoing and incoming documents and report faults.

So where is tWSDL right now?

The server side is progressing very well. We can create a service based upon any Tcl procedure which produces a simple result (list).

Extending this to more complex results will be relatively easy. Although there are automatic procedures for handling the usual case, these can be replaced with custom code. Eventually there will be helper procedures to make it easier to write custom code.

It is important to point out that custom code doesn't need to deal with any of the other parts of tWSDL. Essentially the custom code which invokes the procedure is handed a Tcl representation of the XML document (by reference). This document could be of any complexity. The custom code completely handles this processing until it returns a reference to the result XML. In the current API, this 'custom' code is auto-generated.

The separation of the invoking code from the service ensures that the developer is not limited by 'my' preconceived ideas: any XML document can be processed and/or returned.

Although simple things are simple, the simplist thing: no brainer WSDL, is still a few weeks away. This is nothing more than a wrapper with a few conventions on how things should be done. At the moment we have two services, one imaginary (no real backend), one real. These two services offer enough diversity to build the no brainer service.

Since tWSDL will be used with ACS code, I will develop a switch for ad_proc, which Jade mentioned above. The switch will employ the conventions (hmmm, maybe we can configure those), to build a service at runtime. In any case the switch will do nothing more than cause a single proc to run which will use introspection to create a no brainer service. It should be just as easy to call the proc outside of ad_proc (at the correct time).

Another important part of tWSDL is fault/error handling. Currently client errors are handled: incorrect target namespace and invalid document (type errors). Server errors are not handled yet, but will most likely return a stacktrace. You still get a 500 response, which is all most clients need to know that it is a server error. Error checking/handling is done according to the WS-I Basic Profile.

Code Release:

I'm open to suggestions here. I don't mind releasing this package now, but anyone using this needs to remember that major changes could result. However, I have already done a handfull of major changes and the code changes to the application code have been easy and fast to apply. Application code relies mostly on metadata, so there is very little risk that a big change in implimentation would change the amount and type of metadata required. Most changes so far have been to the form in which the metadata is presented to the API.

OACS has a unique and valuable API, there is also a huge investment in page flows which cannot be replicated by a web service. A web service can potentially be useful in OACS for existing and potential packages, but not every package. The only thing that is really universal across all OACS installations is the Tcl API. tWSDL offers the potential to expose any Tcl API as a web service. In addition, it should be noted that OACS also uses conventions related to types and data structures. It would not be difficult to exploit this metadata to build high quality web services with very little additional effort by the developer.

There are still many questions to be resolved for any web service package including security and how a web service should fit into the request processor. The fact that web services use a different processing model than a pure HTTP service makes this a difficult question.

Collapse
Posted by Wolfgang Winkler on
Tom,

Wow, this was an extensive answer. The first part could be the about page of a website :-).

I think it is a very good idea to keep your package independent of OACS. So one could setup a simple aolserver installation (e.g. for pulling information from webservices) without the need for a full blown OACS installation.

I see a strong need for TCL/AOLSERVER/OACS as more and more companies are providing their services via webservices.

We will start two independent projects in the next weeks, where in one case we implement the server (client is C# .NET), and in the other case we are the client (server is JAVA).

If it is possible, I'd like to try tWSDL. I think it would be a good testrun for your project and the API, as both projects will feature a rich set of functions and services.

Collapse
Posted by Tom Jackson on
It is more likely to work well with services defined by .NET, as (unbelievably) MS generates very high quality WSDL files. tWSDL will generate a WSDL file to match .NET, but this work is not complete yet. I still need to add the 'types' element. The client will read the WSDL file to generate the API, but it needs to be compliant with what the tWSDL server would generate. At the moment, I'm using an XSL transform on the WSDL file. Someone could also create an XSLT to generate the server side application in Tcl, all that would be left is to write the Tcl procedure, and maybe any special type validators.

I'll try to find a place to put the current documentation on line, and figure out how to get a current snapshot of the code. We are using svn instead of cvs.

Collapse
Posted by Wolfgang Winkler on
Are there any news concerning tWSDL? Is there a downloadable version somewhere?
Collapse
Posted by Jade Rubick on
Hi Wolfgang:

The server portion is in a working state, and we're doing work to integrate it into our own implementation of ad_proc (mostly done).

We'd like to do a similar example integration with OpenACS when we release it, so that a lot of the complexity is hidden from the developer. We'd prefer that when people do the first look at it, their experience is "wow, that's easy" rather than seeing too much complexity (which is inherit in WSDL).

But if you're willing to deal with the underlying API, we can release an early, pre-release version.

Otherwise, I expect we'll have something ready within the next few weeks.

Collapse
Posted by Wolfgang Winkler on
A prerelease version would be very handy. I've no problem with the complexity and maybe could provide some real world testing experiences.
Collapse
Posted by Wolfgang Winkler on
Either I've no clue how google code works, or there are no files in the repository.
Collapse
Posted by Tom Jackson on

Wolfgang,

You can now browse the current code at: http://twsdl.googlecode.com/svn/trunk/.

Or do a svn checkout:

svn checkout http://twsdl.googlecode.com/svn/trunk/ twsdl