Intended Features

• pluggable conversion scheme
  • XML-RPC
  • JSON
  • ...

• pluggable transport protocol
  • embeddable in a servlet or standalone
  • HTTP - XML-RPC
  • HTTP - JSON-RPC
  • HTTP - REST-like - JAX-RS?
  • ...

• pluggable set of method annotations
  • former XmlRpc-Delight annotations, e.g., declaring Convertibles, etc.
  • JSR 311- JAX-RS or subset of it?

• automatic deployment of handlers based on annotations
  • e.g., @Tag(name="scope", value="myApp") @DelightHandler
  • or @DelightHandler(scope="myApp")
    • fetching handlers by scope (maybe also a pattern) methodInvocationManager.addHandlerByScope("myApp")

• life-cycle for handlers
  • support @PostConstruct and @PreDestroy
  • dependency injection for handlers

• Processing building blocks
  • ParameterConversionManager: handles transformations of parameter values api representation <-> transport representation
  • MethodAnalyzer: searches for annotations for some api method
  • MethodCallSender: performs sending a call through some transport (e.g., making the http call)
  • HandlerMethodInvocationManager: server-side, finds appropriate handler for an incoming call, performs method invocation

• Basic processing cycle
  1. handle interface call (proxy invocation handler)
  2. read method meta-data (from annotations)
  3. convert (java) method parameters into a transport representation, client-side
  4. send call to remote endpoint
  5. receive call on server side
  6. convert parameters back to java representation
  7. find appropriate method/handler based on information sent and meta-data read
  8. perform call
  9. convert result value returned by method call (if any) back to transport representation
  10. send back answer to client
  11. convert return value back to java representation
  12. return value in interface call

Questions

• Configuration
  • instances or only classes in configuration object?
    • classes
      • pro: delight creates instances and injects references to other building blocks, can be stored in a property file
      • con: additional configuration might be required (e.g., XML-RPC settings for sending and receiving a call)
    • instances
      • pro: properly configured instances, ready to use
      • con: instances must be created at delight config time

• Handler instantiation
  • who does this? Some Delight component which can ensure injected dependencies and calls to @PostConstruct methods

• JAX-RS
  • does this really make sense?