archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: MRM-124 - XML RPC Web Services
Date Wed, 10 Sep 2008 04:21:11 GMT
+1

Emmanuel

On Mon, Sep 8, 2008 at 9:05 AM, Maria Odea Ching <oching@apache.org> wrote:

> +1 to merge too :)
>
> -Deng
>
> On Mon, Sep 8, 2008 at 2:52 PM, Arnaud HERITIER <aheritier@gmail.com>
> wrote:
>
> > +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