[Laszlo-dev] soap support
Henry Minsky
hminsky at laszlosystems.com
Thu Dec 4 19:30:20 PST 2008
One other thing, the version of the apache axis library we are using
is very old, and they changed the API in the more recent versions, so
a considerable amount of the code that makes the SOAP call, and then
encodes the result as JSON would need to be rewritten if that library
is upgraded. The code that is written depends on subclassing some of
the Apache Axis classes, and that would need to be changed. It would
be probably be a good thing if that code were updated and the old code
discarded!
On Wed, Dec 3, 2008 at 11:57 PM, ono keiji <keiji_ono at net8.co.jp> wrote:
> Thank you Henry, i will try this issue, and LPP-5172 should be reopened.
>
>
> Henry Minsky さんは書きました:
>> Here is a very simplified description of the SOAP implementation.
>> Please ask me if you need any
>> further information or have any questions.
>>
>> You can watch some of the transactions by turning on debug logging on
>> the server in
>> WEB-INF/lps/config/lps.xml:
>>
>> <logger name="org.openlaszlo" additivity="false">
>> <priority value="debug" />
>> <appender-ref ref="lps" />
>> </logger>
>>
>> <logger name="org.apache.axis" additivity="false">
>> <priority value="info" /> <!-- ??? I;m not sure about
>> this one ???? -->
>> <appender-ref ref="lps" />
>> </logger>
>>
>> And also using Firebug or other debugger to watch the HTTP
>> transactions when you run examples.
>>
>> There are some test cases in test/rpc/soap/*.lzx. The dotnet-math.lzx
>> one works now.
>>
>>
>>
>> The SOAP package does two things:
>>
>> Loading the SOAP WSDL and Creating Proxy Functions
>>
>> Initially, when a <soap> service is instantiated, it will send a
>> message to the LPS server, to get the WSDL description of the service.
>>
>> The Apache AXIS library encode the WSDL as a JSON expression which is
>> sent back to the Laszlo application.
>>
>>
>> In the lps/components/rpc/soap.lzx:
>>
>> The method soap.load() is called to load the SOAP WSDL, and build
>> proxy stub methods for each SOAP method that is listed.
>>
>> soap.load() ==>
>> LzSOAPService.loadObject(<callback delegate>, <WSDL-location>)
>>
>> LzSOAPService.loadObject makes a request to the LPS server, using a
>> request object (LzSOAPDataRequest), with a type "load".
>>
>> This is handled on the server side by the SOAP response handler:
>>
>> The request has a URL starting with "soap://" which is handled by this code
>> org/openlaszlo/servlets/responders/ResponderCache.java ==>
>> org.openlaszlo.data.json.SOAPDataSource.getData()
>>
>> The request has type of either "load", or "invoke". I will describe
>> "invoke" later.
>>
>> If the request is "load", then getData() calls
>> org.openlaszlo.data.json.SOAPDataSource.getService() which
>> returns an object of type
>> org.openlaszlo.remote.json.soap.LZSOAPService.
>>
>> This represents the WSDL list of methods, obtained through the
>> use of the Apache AXIS library. This is then returned to the
>> Laszlo client by returning a new SOAPData object. (The SOAPData
>> class is defined in SOAPDataSource.java)
>>
>> For example, for the test app
>> http://127.0.0.1:8080/trunk/test/rpc/soap/dotnet-math.lzx?lzr=dhtml
>> The request would have these parameters
>>
>> lzt xmldata
>> reqtype GET
>> request load
>> url soap://soap
>> wsdl http://www.dotnetjunkies.com/quickstart/aspplus/samples/services/mathservice/cs/mathservice.asmx?WSDL
>>
>> The response is this JSON description of the SOAP service method
>> {"__LZstubload": true,
>> "stubinfo": {"service":"MathService",
>> "port": "MathServiceSoap",
>> "wsdl":
>> "http:\/\/www.dotnetjunkies.com\/quickstart\/aspplus\/samples\/services\/mathservice\/cs\/mathservice.asmx?WSDL",
>> "__LZctypes": {},
>> "__LZnamespace": "http:\/\/tempuri.org\/"},
>> "stub": {"Multiply": {"parts": [["tns:Multiply",
>> null]],
>> "opstyle": "document",
>> "operation": "Multiply",
>> "port": "MathServiceSoap",
>> "service": "MathService",
>> "wsdl":
>> "http:\/\/www.dotnetjunkies.com\/quickstart\/aspplus\/samples\/services\/mathservice\/cs\/mathservice.asmx?WSDL"},
>> "Divide": {"parts": [["tns:Divide",
>> null]],
>> "opstyle": "document",
>> "operation": "Divide",
>> "port": "MathServiceSoap",
>> "service": "MathService",
>> "wsdl":
>> "http:\/\/www.dotnetjunkies.com\/quickstart\/aspplus\/samples\/services\/mathservice\/cs\/mathservice.asmx?WSDL"},
>> "Subtract": {"parts": [["tns:Subtract",
>> null]],
>> "opstyle": "document",
>> "operation": "Subtract",
>> "port": "MathServiceSoap",
>> "service": "MathService",
>> "wsdl":
>> "http:\/\/www.dotnetjunkies.com\/quickstart\/aspplus\/samples\/services\/mathservice\/cs\/mathservice.asmx?WSDL"},
>> "Add": {"parts": [["tns:Add",
>> null]],
>> "opstyle": "document",
>> "operation": "Add",
>> "port": "MathServiceSoap",
>> "service": "MathService",
>> "wsdl":
>> "http:\/\/www.dotnetjunkies.com\/quickstart\/aspplus\/samples\/services\/mathservice\/cs\/mathservice.asmx?WSDL"}}}
>>
>>
>> This is used in the client to build an object on the <soap> object
>> named "this.proxy", which holds the remote APIs. This holds the proxy
>> stub methods (Add, Multiply, Subtract, ... in this example). See the method
>> soap.makeProxyStubFunction in lps/components/rpc/soap.lzx.
>>
>> ================================================================
>>
>> Invoking A Remote Method
>>
>>
>> You can invoke a method by calling the SOAP proxy functions directly,
>> or by using the <remotecall> mechanism. See the test/rpc/soap/dotnet-math.lzx
>> example. It shows the two different ways to invoke SOAP methods.
>>
>> The <soap> object has a 'proxy' property which contains proxy stub
>> functions that were created automatically. You can also call the soap
>> object's "invoke()" method with the name of the method you want to call.
>>
>> The things that happen when you invoke a method are handled by the
>> LZSOAPService.invoke() (in lps/components/rpc/library/soap.js).
>>
>>
>> 1) A SOAP request is made by building a partial XML SOAP request on
>> the client, and sending it to the LPS server. It is not a full SOAP
>> request, just the parameters are encoded as XML. The other
>> information, such as the method name and SOAP URI are added as query
>> args:
>>
>> params.request = 'invoke';
>> params.wsdl = opts['wsdl'];
>> params.service = opts['service'];
>> params.port = opts['port'];
>> params.operation = opts['operation'];
>> params.opstyle = opts['opstyle'];
>>
>> The parameters are encode by the method LZSOAPService.__LZencSerializeParams().
>>
>> 2) The SOAP request is handled on the server by the
>> org.openlaszlo.data.json.SOAPDataSource class.
>>
>> The SOAPDataSource.invoke() method gets the SOAP service using the
>> Apache AXIS library,
>> and invokes it, passing the parameters which were encoded as XML on the client.
>>
>>
>> 3) The response comes back to the AXIS library, and is serialized as a
>> JSON expression using the
>> org.openlaszlo.remote.json.soap.encoding.SOAPDataEncoder class, and is
>> sent back to the Laszlo client application.
>>
>> 4) The JSON response is converted to Javascript values and returned
>> by the callback
>>
>>
>>
>> On Tue, Dec 2, 2008 at 7:38 PM, ono keiji <keiji_ono at net8.co.jp> wrote:
>>> Ok, i am expecting your note. :^)
>>> This is a real OSS.
>>>
>>> Before that, could i ask you some questions?
>>>
>>> 1.Maybe this bug miss v4.2. What version can i target and repository ?
>>> 2.Which should i take the latest axis library or Adobe RPC library ?
>>> And in the case of DHTML, can we run Adobe RPC in SOAP ?
>>> 3.The mean of 'converted it to send JSON' is OpenLaszlo dose not use XML-type in SOAP any more ?
>>> 4.Are you using any frameworks in org.openlazlo.*, something like spring ?
>>> 5.Someone guide me during this coding ? ,-)
>>> Are you always discussing with other members on IRC ?
>>>
>>> The time is coming to contribute.
>>>
>>> Best,
>>>
>>> ono keiji
>>> ono at net8.co.jp
>>>
>>>
>>> Henry Minsky さんは書きました:
>>>> I will write up a description of what I know of how the system works.
>>>> It is unfortunately overly complex I think,
>>>> because it uses an older version of the apache axis soap library on
>>>> the server, which is particularly hard to understand code, and also
>>>> the format which is sent back and forth from the laszlo app to the
>>>> server is not well documented anyplace. At at least converted it to
>>>> send JSON instead of swf byte code, so it is easier to understand and
>>>> debug the wire protocol now. Perhaps you can become the new expert!
>>>>
>>>>
>>>> On Tue, Dec 2, 2008 at 11:34 AM, ono keiji <keiji_ono at net8.co.jp> wrote:
>>>>> Hi Henry,
>>>>>
>>>>> Thank you for your direct mail. :-)
>>>>> But that so bad, you mean v4.2 won't contain the demo of Amazon-Soap too ?
>>>>> I believe there are a lot of soap user in OpenLaszlo.
>>>>> If i know where put my hand in, i will make it.
>>>>> Do you have some UML ?
>>>>>
>>>>> Best,
>>>>>
>>>>> ono keiji
>>>>> ono at net8.co.jp
>>>>>
>>>>>
>>>>>
>>>>> Henry Minsky さんは書きました:
>>>>>> Hi Keiji,
>>>>>>
>>>>>> Unfortunately, the support for SOAP has become a lower priority while
>>>>>> other swf9 features
>>>>>> are being worked on. I am not sure when I will have time to work more
>>>>>> on the SOAP
>>>>>> issues.
>>>>>>
>>>>>> One thing I have looked at is that in Flash 9, there is an adobe RPC
>>>>>> library which supports
>>>>>> SOAP and XMLRPC, I believe. There is a .swc library that needs to be
>>>>>> linked in at compile time
>>>>>> explicitly I think, I have not yet experimented with it, but it might
>>>>>> be a way to get SOAP
>>>>>> support in the future, and it does not rely on a server-side
>>>>>> transcoding process, so it
>>>>>> would possibly be suitable for SOLO apps.
>>>>>>
>>>>>>
>>>
>>
>
--
Henry Minsky
Software Architect
hminsky at laszlosystems.com
More information about the Laszlo-dev
mailing list