The Source for Java Technology Collaboration


Wiki to allow discussions within the wiseman community.

A few core principals/design choices to consider when discussing/implementing Wiseman design discussions below:

  • All apis, methods, interfaces should aim for simplicity, functionality and quality in Wiseman implementation so that the widest list of consumers can successfully consume and extend the framework for their associated needs.
  • Consumers/Users of the framework should not have to be WSDL,JAXB or WS-*spec experts to create simple WS-Management enabled services with this toolkit apis provided.
  • Provide as many methods taking simple String arguments, making safe assumptions compliant with the WS-Management and it's extensions of the WS-* specifications.
  • At the end of the day the framework consumer has access to the underlying Management instances and can customize to their hearts content if they do not like the default, customizations or methods that we've provided.
  • The Default Addressing Model as described in the Ws-Management specification is a safe assumption to code to when providing Client/Server support apis.
  • For full-featured implementations of the specifications it is acceptable that we have a base dependency on a servlet engine(like Tomcat, Jetty, etc..) to leverage ACL and protocol security mechanisms provided by this platform. Providing more light weight implementations is encouraged but not required at this time.
  • It is safe to assume that framework customers will provide and XSD to describe their custome model to utilize some of the framework components(like WSDL & code gen).
  • All new and existing functionality should be accompanied by tests (mostly unit) that exercise the same functionality upon check in.
  • JAXWS style deployment is and important J2EE?/WS exposure mechanism that Wiseman should go out of it's way to provide support for.
  • Avoid implementing many extensions or changing interfaces drastically beyond/different what is described by WS-Management specification.
  • Addressing Endpoint Reference "Properties" have been removed from the Endpoint-Reference definitions in later versions of Addressing spec. We should use and refactor to use Reference "Parameters" only in the place of referenceProperties.
  • In addition to the above, for the 1.0 release Eventing and enabling technologies(Metadata), all-around documentation, simplification of Client framework and refinement of WSDL and code generation process are all high priorities.

-- Main.simeonpinder - 22 Feb 2007


Technical discussions

JAX-WS 2.1 support January 2007

EnumerationContext changes pre 0.6 release

EnumerationContext improvements post 0.6 release priority for 1.0

Build out better docs(formal/api/dev tutorials) priority for 1.0

Code/Wsdl Generation process enhancement priority for 1.0

Eventing client/server support classes priority for 1.0

Definition of a public API for WiseMan priority for 1.0

Select a WS-Man specification release for 1.0 priority for 1.0

Relies on JAX-WS 2.1 Addressing

Addition of MetadataExchange implementation for resources priority for 1.0

JAXB Context reuse and other optimizations priority for 1.0

WiseMan 1.0 release

List of Issues that are making 1.0

-- * Main.jfdenise - 27 Feb 2007 *

Updated link for JAXB Context reuse

-- Main.denis_rachal - 02 Mar 2007

Topic WiseMan . { Edit | Ref-By | Printable | Diffs r10 < r9 < r8 < r7 < r6 | More }
 XML java.net RSS

Revision r10 - 02 Mar 2007 - 13:59:34 - Main.denis_rachal
Parents: WebHome