JOnES Meeting Notes:
Architecture
General JBI presentation + Petals overview
- Service Assembly discussion
- the description does not show up at runtime? you can get it using JMX but not at fine granularity, plus not easy to reconfigure
- sardes proposes to have fractal components for service units and also for BCs and SEs
- question: if third-party components come in, can they be managed through the fractal controllers? yes, at high-level through the wrapper
- suggestion: to improve Fractal to have different membrane requirements (with rules such as: to implement a Fractal component for JOnES you must implement the JBI interfaces...)
NMR discussion
- overview
- discussion about message excganges and delivery channels (some confusion exists around the terminology)
- connected mode: to avoid making different connections and routing (transport-level) each time (lower-level concept, at or just
- above transport level - at the layer that sends the MEs).
- proposal to extend the communication patterns (publish/subscribe, multicast etc.)
- QoS for the messages (reliable, fifo, causality?)
- how to use dream (to configure the entire NMR or just the lower levels of JORAM)?
- in JMS there are already a lot of features which would be useful to configure with DREAM
- maybe have a way to have multiple delivery channels with different properties that could be used by the same component
- discussion on administration tasks (JADE) - consistent way for management of installation, creation of instances and configuration
- Proactive: on the deployment side - they deploy JVMs pre-configured for running Proactive code, or it can launch binaries
Fraclet:
- presentation 06-10-11-JOnES-Fraclet.pdf
- help with development of Fractal components (less work and duplication)
- protection against Fractal API changes
- encourage the usage of all the component-model features (which would otherwise be very prone to errors)
- uses attribute-based programming -> generation of source code and descriptors
- supports Java 5 and XDoc (XDoclet 2)
- reduces significantly the amount of code that needs to be written (Petals example shown)
Thread Management:
- need to control thread allocation to avoid performance degradation due to context switches
- protect against crashes due to too many threads created
- modification of the Thread class -> threads will be assigned to areas (according to different criteria)
- areas can block thread execution to prevent overload; they can also raise alarms
- this can be extended to other resources: sockets, messages etc
Generic Deployment Framework (FDF)
- addresses heterogeneity of targets and things to deploy + orchestration of tasks
- everything is a component: variables, shells, software etc.
- we have an "install" component, a "start" component, "stop", "uninstall" etc...
- could be used to install the JADE bootstraps
Petals
- message persistence (using JORAM, a server can receive a message even if it was down when the message was originally sent)
- inter-container communication: JMX, Tribe and JORAM (problem with ports - too many open, maybe there are security problems?)
- there is a need for a distributed JNDI directory
- 98% compatible JBI (transactions are missing)
- try to pass the TCK (mid Nov)
- integrate Petals in JOnAS
- Eclipse plugin
- Orchestra integrations (this needs JOnAS in the background); it would be good to have a "stand-alone" BPEL service engine
General Points:
- Must check other products on the market to see what they offer (the FT deliverable will address this)
- Proactive: what they offer is provided either by Jacquard or by Sardes. No action to be taken now, perhaps if we see a use for their technology with a binding factory within the DREAM contribution.
- Points raised about Maven and it's problems (eg. impossible to specify compilation order for projects)
- Points raised about orchestrating hierarchical component control with Fractal (eg. for "start" we could specify the order in which the sub-components must be started -method for dependency specification)
PDF
History