We're trying to find a solution that will allow us to consume web services from within OpenACS. The need has become rather pressing as we have tried different libraries and found mixed results. The clock keeps ticking for our client, though, and they want delivery on the integration promises of some of their other applications, which all provide decent WSDL and SOAP.

Thus far, we have not tried xotcl-soap, because our environment does not yet include XoTCL. We are, however, very excited about XoTCL and we are willing to increase the priority on upgrading if it buys us a working SOAP/WSDL solution, as well.

So, I have checked out xotcl-soap and xotcl-request-broker from their SVN repository and attempted to install them on a box where we were experimenting with XoWiki. It was a no-go with xotcl-soap 0.4, because our xotcl-core was too old and the download server at media.wu-wien.ac.at seems to be offline. So, I had to downgrade to 0.3. Is that version functional? Even when running the included examples, I get dozens of errors.

I'll post a couple of the errors and version information below, in case anybody can help. Primarily, I want to know what's the recommended version and where I can download it. Is there an alternative site if media.wu-wien.ac.at continues its outage through the whole holiday?

I'm going to purposefully snip the error messages short, in case this is something obvious and easy to solve. If anybody wants the entire error messages, let me know and I'll paste them in.

Thanks in advance to anyone who can help.

Kind regards,
Justis

version information

Here is stuff that might be relevant. I can give more details upon request:

OpenACS: 5.3.2

XoTCL: 1.5.1

xotcl-core: 0.56.3

xotcl-note: 0.8

xotcl-request-broker: 0.3

xotcl-soap: 0.3

xowiki: 0.60.2

from /xosoap/doc/poem

invalid command name "SOAP::create"

    while executing

"SOAP::create getPoem  -uri "urn:xmethods-getPoem"  -proxy $endpoint  -params { statement string }  -schema [list xsd $schema]  -encoding http://schema..."

    ("uplevel" body line 7)

    invoked from within

"uplevel {

    	  #package req SOAP
set endpoint "http://localhost:8000/xosoap/services/Poem"

set schema http://www.w3.org/2001/XMLSchema

...snip

from /xosoap/doc/xotcl-soap-client

invalid command name ""

    while executing

"$plugin info parameter"

    (procedure "new" line 14)

    ::xorb::client::Stub->new

    invoked from within

"::xorb::client::Stub new -bind SqiService1"

    invoked from within

"set s_new [::xorb::client::Stub new -bind SqiService1]"

    ("uplevel" body line 13)

    invoked from within

"uplevel {

    	  ad_page_contract {


      @author Stefan Sobernig

} {

...snip

from sample code in Stefan Sobernig's presentation

When running this code:

set glue [::xosoap::client::SoapGlueObject new \

  -endpoint "http://websrv.cs.fsu.edu/~engelen/interop2.cgi" \

  -action "http://websrv.cs.fsu.edu/~engelen/interop2.cgi" \

  -callNamespace http://soapinterop.org/ \

]
::xotcl::Object SimpleEcho -glueobject $glue
SimpleEcho ad_glue -returns xsDateTime \

  proc echoDate {-inputDate:xsDateTime} \

  { see http://www.whitemesa.com/interop/proposal2.html#echoDate }
set foo [SimpleEcho echoDate -inputDate 1956-10-18T22:20:00-07:00]

We get this error:

can't read "elementNamespace": no such variable

    while executing

"my getQName $elementNamespace $elementName"

    (procedure "SoapElement" line 17)

    ::xotcl::__#C ::xosoap::visitor::SoapMarshallerVisitor->SoapElement

    invoked from within

...snip

Hi Justis!

Thanks for giving xorb/xosoap a try. I will try to help you through getting it up and running:

Let me make some general comments at the very beginning:

1. All the errors reported by you are due to using OUTDATED examples. This is partly my fault as I (to admit it frankly) to remove some of them from the tarballs. I will take care of this as soon as possible. Thanks for pointing me to this issue .... However, all examples cited in the main documentation document are kept up-to-date (see below)!
2. The key reference for the on-going development, how-tos etc. is http://alice.wu-wien.ac.at:8000/xorb-doc/. As core part, it contains primers on using xosoap (bothing consuming and providing services) which are also reflected in ready-to-take examples in the package distribution. The examples you refer to (Poem, my Boston and Vienna conference slides are inherently outdated, as stated prominently at the beginning of the xorb-doc document!). NOTE, however, that our main server at VUE (alice.wu-wien.ac.at:8000, media.wu-wien.ac.at) has been down for three days now (probably hacked). But as I am currently spending a holiday leave far away from Vienna, I can hardly do anything about it personally. We hope to get it up and running again soon. Anyway, there are some work-arounds available (see below).
3. The first stable and, therefore, public release is 0.4+. Therefore, we do not recommend to use 0.3 anymore (for various reasons).
4. The current and most stable version is 0.4.2 of xorb and xosoap which corresponds to the trunk version. It also requires more recent versions of xotcl (at least 1.5.4) and xotcl-core (0.73+). I will try to guide you through setting these up below.

So, I have checked out xotcl-soap and xotcl-request-broker from their SVN repository and attempted to install them on a box where we were experimenting with XoWiki. It was a no-go with xotcl-soap 0.4, because our xotcl-core was too old and the download server at media.wu-wien.ac.at seems to be offline.

I am wondering, do you refer to getting xotcl-core or xotcl as such? xotcl is actually hosted at media.wu-wien.ac.at which is down, xotcl-core however is best retrieved from the openacs cvs.

I suggest the following steps (to work-around the current availability issues):

1. In case you need a recent installation of xotcl (at least 1.5.4, preferably 1.5.6), I provide the source tarball at for the time of media.wu-wien.ac.at being down: stefan.thinkersfoot.net/xotcl-1.5.6.tar.gz
2. Get a recent xotcl-core:

   cvs -d:pserver:anonymous@cvs.openacs.org:/cvsroot co -r HEAD xotcl-core

3. Get the trunk versions of xorb (0.4.2):

   svn co http://svn.thinkersfoot.net/xotcl-request-broker/trunk xotcl-request-broker

4. Get the xosoap trunk (0.4.2)

   svn co http://svn.thinkersfoot.net/xosoap/trunk xotcl-soap

5. You will now find a local copy of the xorb-doc document (currently not available) at xotcl-request-broker/doc/manual/manual.pdf or xotcl-request-broker/doc/index.html (xhtml derivate). ALTERNATIVELY, point your browser to http://teldev.wu-wien.ac.at:8000/request-broker/doc/ which is one of our staging machines which runs a recent version of xorb/xosoap.
6. Follow the examples in the quickstart section (or look at http://teldev.wu-wien.ac.at:8000/request-broker/doc/#x1-170003.2)

This should get you going with 0.4.2. If otherwise, please, report back and I will commit the time necessary to guide you through. I will be back in Vienna tomorrow afternoon, and will try to get our main machines (alice, media) up and running again.

Thanks for your patience!

//stefan

Stefan,

Thanks so much for the reply. You were right that my roadblock was about gettting XoTCL itself, not xotcl-core. I already had xotcl-core 0.8 from CVS and it didn't work. I was guessing it was because I still had XoTCL 1.5.1 and needed 1.5.6. So, the temporary download you provided is very much appreciated. The alternate locations for the documentation is also appreciated!

I haven't gotten a whole lot further, though. I ran into the following error when compiling XoTCL 1.5.6 and I'm not sure whether it's a problem in XoTCL's makefile or in the options we used in compiling AOLServer 4.5. Here's what I get:

/tmp/build/xotcl-1.5.6 # make && make install-aol rm -f libxotcl1.5.6.so
gcc -shared -pipe -g -Wall -Wno-implicit-int -fPIC -Wl,--export-dynamic -o libxotcl1.5.6.so xotcl.o xotclError.o xotclMetaData.o xotclObjectData.o xotclProfile.o xotclTrace.o xotclUtil.o xotclShadow.o xotclCompile.o aolstub.o xotclStubInit.o -L/usr/local/lib -ltclstub8.4
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: xotcl.o: relocation R_X86_64_PC32 against `LookupVarFromTable85' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libxotcl1.5.6.so] Error 1


Any suggestions?

Kind regards,
Justis

Justis,

Please, post the followings details:

• Which tcl version are you using?
• What are the configure options you passed to the xotcl and aolserver 4.5 builds, respectively?

I think Axis is a good platform for web services, but it all depends upon who set it up. Many WSDL are written by hand or semi-generated based upon an existing API. This leads to services which are somewhat tied to the base language and the web service toolkit because they rely on mapping of programming language types and structures to an XML-Schema. You can only go so far with this concept, so client programming is very complicated in the general case.

tWSDL/TWiST takes a toolkit approach. There are many low level support API which are combined to provide the final user layers. The tWSDL client is similar. I have not taken the approach of solving a single problem. Instead I have focused on trying to create some reusable components for the inevitable variability in web service descriptions.

But this is all speculation at this point. If you have a link to a representative WSDL, or if you can email me a copy, I can tell you more. At the very least, tWSDL/TWiST can be used to generate API to easily construct and validate messages using simple Tcl lists as input. The lists are data only, you don't need to include the element names. This allows any method of constructing the input list, your internal API don't need to know about the XML structure.

For instance: http://junom.com/ws/stockquoter2/?op=StocksOperation&mode=display

If you put in multiple stock symbols, like MSFT GM, and 1/0 in verbose, the internal API gets called:

::wsdb::elements::stock2::StocksRequest::new $someNS {{MSFT GM} 1}

This generates the StocksRequest message:

  <StocksRequest xmlns=&#34;http://junom.com/ws/stockquoter2&#34;>
   <Symbol>MSFT</Symbol>
   <Symbol>GM</Symbol>
   <Verbose>0</Verbose>
  </StocksRequest>

In response to this message, the internal API returns a list of StockQuotes like this:

::wsdb::elements::stock2::StocksResponse::new $someNS {{MSFT 27.44} {GM 26.77}}

Which generates this message:

  <StocksResponse xmlns=&#34;http://junom.com/ws/stockquoter2&#34;>
   <StockResponse>
    <Symbol>MSFT</Symbol>
    <Quote>27.44</Quote>
    <Name xsi:nil=&#34;true&#34;/>
   </StockResponse>
   <StockResponse>
    <Symbol>GM</Symbol>
    <Quote>26.77</Quote>
    <Name xsi:nil=&#34;true&#34;/>
   </StockResponse>
  </StocksResponse>

Note that the caller doesn't need to know anything about the handling of missing elements. These are filled in by the new procedure which is based completely on the XML-Schema type definition.

Tom and Stefan,

Thanks for the offer to give an opinion based on our actual WSDLs. I'm pretty excited about getting opinions from people who have first hand experience with the complexities of implementing SOAP clients against existing WSDLs. We're trying our best to pick a tool that will work for most of our needs. Once you consider that we may need to upgrade OpenACS versions in order to get XoTCL, it becomes a pretty large decision. We have a decent amount of code which differs from the core, so upgrading is not trivial. Even if it involves upgrading, though, I'd like to go with the right tool. Opportunities to integrate applications via SOAP seem to be around every corner. I'd like to capitalize on as many as possible and having the right tool is key.

There are 3 tools where we currently want to consume their web services from within OpenACS: JasperServer, Corticon, and Intalio. I have example WSDLs from all 3, but pasting them in here would make this a very long thread. I'm new to the forums and don't exactly know the accepted etiquette here. Is there a way to post these as attachments? Should I email them to each of you? Should I just post them?

Thanks in advance for the help. I sincerely appreciate the offers.

Kind regards,
Justis

Tom,

I emailed them to both of you. Thanks again for the help.

Kind regards,
Justis

For the sake of completeness: Our main machines are up and running again. This includes:

• xotcl: http://media.wu-wien.ac.at (http://www.xotcl.org)
• xowiki-doc: http://alice.wu-wien.ac.at:8000/xowiki-doc
• xorb-doc: http://alice.wu-wien.ac.at:8000/xorb-doc

Justis,

Right now, I just need to keep us moving forward to a decision on how best to begin consuming web services from within our existing OpenACS apps.

I know. You already received a rough primer from Tom on approaching your scenarios, mine on xosoap will follow tomorrow (Dec 30, 2007, GMT+1). I am quite busy these days, so am just now arriving at this point on my todo list.
I will post my suggestions to this thread ...

cheers
//s

Justis,

I hope you didn't take my comment as suggesting you should move faster.

No, no ... I didn't, I just wanted to express my awareness of your shortage in time ...

Finally, I reviewed the interface descriptions you provided to me by email (and which Tom is kindly hosting). A single one (jasperserver, http://junom.com/document/openacs/business-wsdl/jasperserver-repository.wsdl.xml) adopts the RPC/Encoded style, the other three, however, realise the document/literal style.

As for the RPC/Encoded style, realising a consumer is straight forward. Please, find and review a working example at http://svn.thinkersfoot.net/xosoap/trunk/www/demo/demo-ivc-jasperserver-consumer.tcl.
The above proxy was tested against an auto-generated mock service based on the wsdl provided.

As for the document/literal ones, the main problem is that document/literal support for the CONSUMER/CLIENT part has not been accomplished. This is, on the one hand, due to the fact that this feature has been ranked low in priority (at least so far), on the other hand, I am only now investigating a major rewrite towards a more general xml data binding infrastructure as discussed in http://openacs.org/forums/message-view?message_id=1392828. The latter is key to a sound support of document/literal style. Though I could think of some rough work-arounds for realising a simplistic document/literal service (jdbc one), the advanced features required by the others (TaskManager, unit_on_found) such as choice compounds etc. will only be available in the next major release of xosoap.

From my perspective, you now have three options:

• Depending on your time schedule, you might wait for an early preview of the xosoap rewrite that comes with the necessary features. I will be working on this in the first week of January, and there is a certain chance that I might provide support for the features your scenarios require. However, I can't make this a firm promise, the entire rewrite will only be finished for the OpenACS conference in Guatemela City in the mid of February. Also Tom might be working on tWSDL/TWiST consumer part (!?) in the meantime ...
• Provide RPC style wrappers in an alien environment, such as Axis, that hide the document/literal issues from xosoap consumers. I, personally, consider this a considerable extra amount of work and source of complexity. But is might be feasible ...
• For the time being, assemble and use the raw xml messages required by the services (using tdom). It is quite easy to extract sample or template raw messages from the interface descriptions. Tools such as http://soapui.org make this an ease ... Of course, this is only a temporary solution but still a valid recommendation.

Again, I will be working on the xosoap rewrite over the next week. Let me know whether you can afford waiting for xosoap to mature in these directions, so I can put some effort in getting your scenarios supported ...

cheers
//s

Tom,

The main issue, in my mind, is that you have several examples which will never be handled by a generic client without some hand programming.
Any complexType which adds attributes is going to require hand coding. There is simply no generic interpretation of how to handle values that are in both attributes and as element content.

I wouldn't sign the above statement. While it is common sense that xml/xml-s idiosyncrasies are critical when using xml as representation/ streaming format, it is a question of design whether to you want developers of your framework to express these more or less subtle differences when creating their mappings.

The attribute vs. element issue is one of the most trivial cases IF considered isolated from other xml/xml-s idiosynchrasies. It gets more complex once you consider the nillability constraint, just to name a prominent one. The approach taken by most frameworks (Axis, .NET, ...) is to generate per-type marshallers (note that "type" refers to "class type" with classes being representations of element types) from xml-s descriptions embedded in wsdls. They, then, take care of streaming ("serialising") certain members of an object into element attributes. It's a rather declarative approach.

In the end, it boilds down to the question for which overall purpose you want to conceptualise and devise your framework, which "remoting" lifecycles you want to support!
In conventional (OO)-RPC middleware, you deal with rather atomic, operation-level interactions (of objects) which may allow a design that simply rejects element attributes as representation flavour. This is fully valid and acceptable! In this life-cycle, developer devise procedures or objects first, representations come second. Once you enter other scenarios, where "document/ content models" are devised first, and language representations (procs or objects) are secondary, you end up with the need to support more of the xml/xml-s idionsynchrasies. This key distinction is also prominently mentioned at the beginning of the article posted above with the authors referring to schema-first vs. object-first approaches.

I'm talking about WSDL, which is a standard for describing a web service. Anyone who wishes to pick up a web service client have have it 'understand' the web service automatically should know that there are limits on when this can be done. The term for this understanding is interoperability. And it means that there are no ambiguous features in the description.

However, even WSDL is a pretty loose standard. I've pointed out before that an easier standard to follow is the WS-I Basic Profile:

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

Maybe you think I'm talking about how you translate an existing interface into a web service? Not sure, but the issue is a client issue, not a server issue. WSDL is used to abstract the interface away from the programming language used on the server. Otherwise, consuming an Axis service would require an Axis client, ruling out the use of OpenACS, C# or any other client. One of the main problems for interoperability with web services is their continued tie to the RPC style. It is easy to implement because it is based upon mapping programming types to a message format. Assuming client and server are based upon the same programming language, this is easy, but it isn't interoperable outside these rigid and narrow limits.

In the present case we have an Axis based service. The service is defined using a WSDL. My assumption was that the client should automatically read and understand the definition so that it can construct client API to invoke the operations. When the data is transfered as element content only, it is easier to create client API. In this case the parent could be considered a class or an object, and the child elements are slots, or whatever the correct word would be for the language. If you add attributes, there is an ambiguous quality. Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

This is, again, the easy case: data element have attributes. The hard case is a WSDL which has extensions. Who could ever provide a client which understood private extensions automatically, without hand coding? Nobody, outside the narrow meaning of the basic WSDL, very little can or should have a fixed meaning.

Tom,

If you add attributes, there is an ambiguous quality. Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

Again, this is what I referred to as "content-/ document-model-first" versus "language-construct-first" (or, schema-first versus object-first). It depends on your scenario and the set of requirements embodied in coded conventions. Justis' WSDLs are auto-generated by Axis which implies an object-first simplification. For the resulting Java objects, it does not make any difference whether an object member (i.e. property or slot in XOTcl terms) is transmitted as element or element attribute. That is, in object-first scenarios, there is hardly any quality difference between element and attribute content because the underlying object systems does not make these distinctions.

Your statement is certainly valid but only for schema-first scenarios, where we cannot stream-line schema information in the meta-object level of an object system. But this is certainly NOT an issue with Justis' WSDLs ...

Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

Again, you refer to something which does not concern Justis' WSDLs at all. In Document/Literal style, document content is not "encoded" as it would be with SOAP Encoding or whatsoever. It is a proper document that can be thrown against any XML schema.

Malte,

Also, how would you implement the "getProject" glueing in OpenACS if I have a TCL procedure that returns the project_id when called.

I tried to sketch a ready-to-take sample for you below ... did I get it right when assuming that you want to expose an existing tcl proc through a soap channel?

# / / / / / / / / / / / / / / / / / / / / / / / / / /

# $Id$
# -) prerequisites
namespace eval :some_name_space {

  proc getProject {input} {

    # retrieve project_id based on input ...

    set project_id 1

    return $project_id

  }

}
namespace eval ::cognovis {


  ::xo::db::require package xotcl-request-broker

  namespace import ::xorb::*


  # 1-) provide an interface description aka 'service contract'

  ServiceContract EchoProject -defines {

    Abstract getProject \

	-arguments {

	  input:xsString

	} -returns returnValue:xsInteger \

	-description {

	  A sample echo operation that returns

	  an arbitrary integer value.

	}

  } -ad_doc {

    This is the sample interface description as requested

    by Malte ...

  }


  # 1a-) deploy your interface description

  EchoProject deploy


  # 2-) Provide 'servant' code and register it with the invoker:

  # 'service implementation'

  ServiceImplementation EchoProjectImpl \

      -implements EchoProject \

      -using {

	Delegate getProject \

	    -for ::some_name_space::getProject \

	    {Delegates calls to the servant proc indicated ...}

      }


  # 3a-) deploy your service implementation

  EchoProjectImpl deploy

}

As for the second issue, i.e. document/literal support for the consumer side:

... how far did you manage to get with document/literal and is there a way to help speed up the process?

I am closing down and started rewriting xosoap allover, I have a somewhat firm deadline for the Jan 24, so, hopefully, till Sunday, there will be something operative (though not completed). Currently I can't think of anything that I can easily delegate to you, but I will think a bit and come back to you ... thanks for the kind offer!

For the sake of completeness (and the records). I spotted a critical typo in the code sample above that had evaded my eyes:

# 2-) Provide 'servant' code and register it with the invoker:


  # 'service implementation'


  ServiceImplementation EchoProjectImpl \


      -implements EchoProject \


      -using {


	Delegate getProject \


	    -for ::some_name_space::getProject \


	    {Delegates calls to the servant proc indicated ...}


      }

needs to be

# 2-) Provide 'servant' code and register it with the invoker:


  # 'service implementation'


  ServiceImplementation EchoProjectImpl \


      -implements EchoProject \


      -using {


	Delegate getProject \


	    -for ::some_name_space::getProject \


	    -ad_doc { Delegates calls to the servant proc indicated ...}


      }

Note the missing thingy is the "-ad_doc" flag ...