archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud HERITIER" <aherit...@gmail.com>
Subject Re: MRM-124 - XML RPC Web Services
Date Mon, 08 Sep 2008 06:52:23 GMT
+1 also

Arnaud

On Mon, Sep 8, 2008 at 8:05 AM, Brett Porter <brett@apache.org> wrote:

> Sounds good to me. +1 to merge.
>
>
> On 08/09/2008, at 3:41 PM, James William Dumay wrote:
>
>  Hey Brett,
>>
>> On Mon, 2008-09-08 at 15:27 +1000, Brett Porter wrote:
>>
>>> I like the simplicity of the API. I didn't dig into xmlrpc-binder
>>> itself though.
>>>
>>
>> Cool - the whole idea was that it there is supposed to be a minimal
>> amount of code inside of Archiva to get a XML-RPC service going.
>>
>>
>>> My main thoughts are about the data interchanged itself. How easy is
>>> it to work with outside the API (eg, from a different language, or
>>> AJAX, etc). How easy would it be to add alternate representations?
>>>
>>
>> Its simple really - say if you have a service method that returns a
>> simple POJO like this:
>>
>> @ServiceBean
>> class MyClass {
>>        String getMessage() { return "helloWorld"; }
>> }
>>
>> that will translate into the standard xmlrpc struct result which looks
>> like this:
>>
>> <struct>
>>  <member>
>>   <name>message</name>
>>   <value><string>helloWorld</string></value>
>>  </member>
>> </struct>
>>
>> So binding from different languages is pretty easy - the binder servlet
>> and client just translate these return values into pojo's for you
>> instead of getting back a Map of keyvalue pairs for the struct or having
>> to guess the primitive type returned.
>>
>> Say if we wanted to put in support for REST, we could also build a
>> similar framework that understands the binder annotations that support
>> rest. Patches welcome :)
>>
>>
>>> One thing I think we will notice as these services are added that some
>>> of the web logic is intermingled in the UI - getting that pulled out
>>> would be good. Would it make sense for Webwork actions to talk
>>> directly to service interfaces (but not going over xmlrpc)?
>>>
>>>
>> Yeah totally - all you need todo is inject the bean that represents the
>> service into your webwork action and away you go. (Keep in mind that
>> currently these beans are all singletons and that they should not hold
>> any state).
>>
>>
>> Thanks,
>> James
>>
>>  Cheers,
>>> Brett
>>>
>>> On 04/09/2008, at 2:55 PM, James William Dumay wrote:
>>>
>>>  Hey guys,
>>>> I created a branch for MRM-124 - support for web services using XML-
>>>> RPC
>>>> - which I am proposing to merge into trunk.
>>>>
>>>> https://svn.apache.org/repos/asf/archiva/branches/MRM-124
>>>>
>>>> It introduces two new modules - Archiva XML-RPC API and Archiva XML-
>>>> RPC
>>>> Services. These two modules use the library I wrote at Atlassian
>>>> imaginatively called "Atlassian XML-RPC Binder" which is a companion
>>>> library to the Apache XML-RPC client and servlet which makes XML-RPC
>>>> using Java easy and type safe. It is licensed under the Apache 2
>>>> license.
>>>>
>>>> So, let me explain how it works :)
>>>>
>>>> Here is a example application that uses the "test" XML-RPC service
>>>> included on the branch.
>>>>
>>>> package com.mycompany.testservicething;
>>>>
>>>> import com.atlassian.xmlrpc.Binder;
>>>> import com.atlassian.xmlrpc.DefaultBinder;
>>>> import java.net.URL;
>>>> import org.apache.maven.archiva.web.xmlrpc.api.TestService;
>>>>
>>>> public class App
>>>> {
>>>>  public static void main( String[] args ) throws Exception
>>>>  {
>>>>      URL url = new URL("http://localhost:8080/archiva/xmlrpc");
>>>>
>>>>      Binder binder = new DefaultBinder();
>>>>
>>>>      TestService service = binder.bind(TestService.class, url);
>>>>      System.out.println(service.ping()); //will output "pong"
>>>>  }
>>>> }
>>>>
>>>> When bind() is called, we pass an interface class type that represents
>>>> the remote service and the URL of the xmlrpc servlet and it then
>>>> returns
>>>> a dynamic proxy object of that interface.
>>>>
>>>> The object returned is a type safe instance of the remote service - so
>>>> when ping() is called we are actually calling ping on the xmlrpc
>>>> service.
>>>>
>>>> The interface looks a like this:
>>>>
>>>> import com.atlassian.xmlrpc.ServiceObject;
>>>>
>>>> @ServiceObject("Test")
>>>> public interface TestService
>>>> {
>>>>  public String ping();
>>>> }
>>>>
>>>> The ServiceObject annotation denotes that this is a xmlrpc service
>>>> with
>>>> the object name of "test".
>>>>
>>>> The server side object looks like this:
>>>>
>>>> import org.apache.maven.archiva.web.xmlrpc.api.TestService;
>>>>
>>>> public class PingServiceImpl implements TestService
>>>> {
>>>>  public String ping()
>>>>  {
>>>>      return "pong";
>>>>  }
>>>> }
>>>>
>>>> As you can see, the interface for accessing the service and
>>>> implementing
>>>> the server side service are the same (yay for interfaces).
>>>>
>>>> The best part about this is that anyone using the XML-RPC service to
>>>> talk to Archiva using java will be type safe the entire time they are
>>>> using it.
>>>>
>>>> Services are easily registered with the servlet by appending bean
>>>> references to the applicationContext.xml "xmlrpcServicesList" list
>>>> bean
>>>> - when the servlet initialises it looks for this list in the spring
>>>> ApplicationContext and allows clients to start accessing the services
>>>> defined. There is no need for a servlet subclass.
>>>>
>>>> If you wondering how to return POJO's (or lists of them) take a look
>>>> at
>>>> the following test case:
>>>>
>>>> https://svn.atlassian.com/svn/public/atlassian/xmlrpcbinder/trunk/binder/src/test/java/com/atlassian/xmlrpc/BeanServiceTest.java
>>>>
>>>>
>>>> Anyway, would love to hear your thoughts, questions and complaints :)
>>>>
>>>> Cheers
>>>> James
>>>>
>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>


-- 
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message