[swordfish-dev] Chat transcript 11/11/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 11/11/2008

[START Transcript 11/11/2008]

Volodymyr Zhabiuk
Regarding javadocs: will add.
About the scenario including consumer / provider independent from camel, it is already implemented
Right now I'm implementing the integration test for the configuration and exchangeListener
I meant, that i have imported your api project into eclipse. Saw the problem u described. And after I've executed mvn eclipse:eclipse the problem have been settled

Volodymyr Zhabiuk
What about your plans in terms of Swordfish?
The configuration integration has been written
Pls check the org.eclipse.swordfish.core.planner.test.integration.ExchangeListenerTest
It includes the configuration test as well as the roundrip scenario, when the messageExchange is intercepted by the registered test interceptor

Dietmar Wolz
next thing will probably be a swordfish wrapper arount the event admin service, lets wait for Oliver before we discuss the details
Volodymyr Zhabiuk
Updated javadocs within the org.eclipse.swordfish.api.configuration and org.eclipse.swordfish.api.context packages

Oliver Wolf
morning gents
we'd like to to some painting, could you please go here: http://www.twiddla.com/49551

Oliver Wolf
do you have issues with twiddla?

Andrey Kopachevsky
no, skype just more convinient, we can do this in twiddla

Oliver Wolf
ok, let's use skype for talking and twiddla for drawing and we'll lokk for a whiteboarding solution for skype
ok, back to the topic:
in the current sopera implementation, there is a facility that allows software components in the core to send events of two types
operational events and messge tracking events
message tracking events are used to track the progress of message processing in the core, operational events are used to notify administrators or other software components of events like failure situations etc.
what we'd like to do for swordfish is to introduce a concept like this based on the OSGi EventAdmin Service, but a bit more general than we did in the sopera implementation
let's talk about event sources first
message tracking events will probably be generated from two types of components: first of all from a special kind of interceptor that lives in the swordfish core and generates events as messages flow through the chain. This interceptor will probably be configured by policy.
a second source of tracking events will be binding components and service engines if we require events that are generated more closely to the application code or to the wire (but we won't be bothered about them right now, it's only important to keep in mind)
(BTW, if you have questions please interrupt)
the source of operational events can be just about anything in the system: the swordfish core itself or any plugin that needs to create notifications about soecial situations
just take a look at the twiddla drawing that dietmar is just creating 

Andrey Kopachevsky
yes, it's interecting process)
who are publisher and who are subscribers in this scheme?

Oliver Wolf
i think it gets clearere when i continue 
now let's talk about event sinks
in sopera, we currently have two types of event sinks: first one is a logger that takes events and creates log entries
second one is an event sink that buffers events for a specified time or until a size threshold is reached and then sends them a single package to a remote service called notification receiver which stores them in a database for reports etc.
As is said, we intend to use the OSGI EventAdmin Service as the basis for this mechanism

Volodymyr Zhabiuk
A small question about <<message tracking events will probably be generated from two types of components: first of all from a special kind of interceptor that lives in the swordfish core and generates events as messages flow through the chain. This interceptor will probably be configured by policy.>>
Could any interceptor in the chain generate that events instead of some centralized interceptor tracker?

Oliver Wolf
sure, any interceptor can create events
but it might make sense to have a special kind of interceptor which is dedicated to only this single task
independent from any other processing steps

Volodymyr Zhabiuk
But you've mentioned a special kind of interceptor that will track how other interceptors process messageExchange?

Oliver Wolf
no, sorry... i wasn't clear about that... the idea is to have a special interceptor that only performs one task: if an exchange flows through the interceptor, extract some metadata from the exchange (like exchange id,...) and create an event.
we could use a policy assertion to specifiy which parts of the exchange sdhould be included in the event (just metadata, whole payload, parts of the payload defined by a xpath _expression_ etc.)
but now it's not about this special interceptor, but about the general concept where this interceptor is just an event source
the idea is to define a Swordfish API that basically wraps the OSGi EventAdmin Service and enforces some conventions
for example, all events types related to swordfish should live in the same topic namespace as defined by a namespace prexix (like org/eclipse/swordfish/)
and, depending on the event type, a few event properties should be guaranteed to be set
like for example the exchange if in case of a tracking event and a severity level in case of an operation event

Volodymyr Zhabiuk
What is the difference between notification listener and receiver?

Oliver Wolf
the listener is the local event sink, the receiver is a remote service that the listener sends the packetized events to frequently
so what we would like to do in the first step is: create a swordfish API for the event system. it will basically be something like a facade to the OSGI event service that enforces some conventions
for example, we could have class like OperationEvent and TrackingEvent that derive from or delegate to an OSGi Event and fill the Event properties according to conventions

Volodymyr Zhabiuk
enum EventType{ OperationEvent, TrackingEvent;
    public void validatePropeties(Map props) throws SwordfishException
}
interface Event {  
  EventType getType();
  Map getProperties();
  String getTopic();
}
we may discuss the api?

Oliver Wolf
sure
questions is: how does the code look for the typical use cases:
1) some component sends a TrackingEvent
2) some component receives a TrackingEvent
how does some component get hold of something that it can use to send an event?

Volodymyr Zhabiuk
interace EventListener<T extends Event> {
String getSubscribedTopic()
EventType getSubscribedEventType()
public void onReceive(T event);
}
It can be done via SwordfishContext

Oliver Wolf
is there something like a Factory for EventSenders in the Swordfish API? Or do we expect implementors of Event sources to use an OSGi service and take care of ServiceTrackers and so on?

Volodymyr Zhabiuk
This way we update configuration as for now
public interface SwordfishContext {
   /**
    * Returns the SMX endpoint registry
    */
   public EndpointRegistry getEndpointRegistry();

   /**
    * Updates the configuration with the specified id
    * @see org.eclipse.swordfish.api.configuration.ConfigurationConsumer
    */
   public void updateConfiguration(String id, Map<String, ?> configurationData);

   /**
    * Returns the JBI component context
    */
   public ComponentContext getComponentContext();
}
we may add the method public void sendEvent(Event event);

Oliver Wolf
That sounds reasonable.... I'd like to ask you and Andrey to come up with a proposal and an example (preferably as a test case) for the two basic use cases (sending and receiving events)
is that ok for you?

Volodymyr Zhabiuk
sure. We will do
Dietmar, What do you think about this?

Dietmar Wolz
Oliver and I discussed the issue and Oliver presented the result

Volodymyr Zhabiuk
i mean about the api proposal?

Dietmar Wolz
no objections so far, we should further discuss when we have a running sample illustrating the ideas

Oliver Wolf
ok, next topic: configuration
question is: where do configurations that are distributed to components by the OSGi ConfigurationAdmin come from?
the OSGi way of doing this is by using bundle that has special privileges and acts as a configuration agent

Volodymyr Zhabiuk
In the current case they are sent via SwordfishContext.updateConfiguration(String id, Map<String, ?> configurationData);
id is basically the osgi PID

Oliver Wolf
yes, but this only covers the part between ConfigurationAdmin and the target component
it assumes that configuration objetcs already exist in the ConfigurationAdmin. But where do they come from?

Volodymyr Zhabiuk
ConfigurationAdmin.getConfiguration(java.lang.String pid) 
         Get an existing or new Configuration object from the persistent store.
so it is automatically created, if didn't exist before

Oliver Wolf
that's true, but where does the data come from?
the Configuration is just a representation of a Dictionary containing config properties

Volodymyr Zhabiuk
Initially the data is null or may be supplied by the managedService

Oliver Wolf
the actual data comes from a configuration source somewhere, e.g. a property file or a remote config service
the managed service itself does not know about its configuration

Volodymyr Zhabiuk
it may supply default values
as described in the example(specification)

Oliver Wolf
yes, but that's not sufficient
the components don't have a gui or some other means to actually change or define a configuration
So what we'd like to do is to create a Swordfish Configuration Agent (as a sperate bundle) that interfaces to configuration bbackends (like property files or the sopera remote config service), retrieves configuration data and uses ConfigurationAdmin to create Configuration objects that are then distributed to teh components
But what does the interface between the Configuration Agent and the Backend (ConfigurationSource) look like?
Configuration backends might need to be polled for new configurations or they might use a push approach. Configuration data from the backend can be any format (XML, properties, whatever) that the backend plugin needs to handle.

Volodymyr Zhabiuk
Could the config data be some custom Java beans?

Oliver Wolf
hm...not sure what you mean....can you elaborate?

Volodymyr Zhabiuk
instead of xml or properties
ok just ignore that question

Oliver Wolf
hm...as an alternative...why not? in sopera, it's an xml document with a basic structure like
<config>
<component1>
<someproperty>somevalue</someproperty>
<someotherproperty>somevalue</someotherproperty>
</component1>
<component2>
<yetanotherproperty>somevalue</yetanotherproperty>
</component2>
</config>
this would have to be dissected into two configuration dictionaries, on for PID component1 and one for PID component2
the configuration agent would then use the ConfigurationAdmin service to create the configs and set the properties
so that's it, basically

Volodymyr Zhabiuk
clear

Oliver Wolf
we don't need the implementaion of the backend plugin yet, just a proposal for the API and maybe mock plugin for demonstratioon of API usage

Volodymyr Zhabiuk
ok

Oliver Wolf
any remarks, questions, or whatever? we have 3 more minutes

Andrey Kopachevsky
my remark is that listener and receiver not very clear name suffixes
particular user excpected to see sender and receiver

Oliver Wolf
good point, i'll leave that to your proposal... we can discuss it then...

Andrey Kopachevsky
also I would like to tell about my status for this week

Oliver Wolf
just decice yourselves who is going to do what or whether you'll work on the API things together+
@andrey: yes, please

Andrey Kopachevsky
I would like to work with events, because I'll need to change current exception listener realization according to new api
so, about status, yestorday I've been able to run roundtrip completelly based on pde plugins generated from our projects
and we have one issue with our new tagret platfrom
classloading issue with connected with JAXB implementation
there is situation when real factory name for xml parsing is readed from config file, and when some bundle try to instantinate it, but current bundle don't have corresponding import statements to achive factory class
maybe it not cleare, but I'm working on this also)

Dietmar Wolz
andrey: first step could be that you check in the new event-apis + javadoc, then we can discuss further steps. volodymyr: Same thing holds for the config agent / config source stuff

Volodymyr Zhabiuk
interface PollableConfigurationSource<T> {
      T getConfiguration();
      Map getProperties();
}

interface ConfigurationAgent extends SwordfishContextAware {
    List<T extends PollableConfigurationSource>  getKnownConfigurationSourceClasses();
    void setConfigurationSourceRegistry(ReadOnlyRegistry<PollableConfigurationSource<?>> configurationSourceRegistry)
}

interface ListeningConfigurationAgent extends EventListener<T extends ConfigurationSourceUpdateEvent>{}

Andrey Kopachevsky
@dietmar, oliver: did you save your diagram?

Dietmar Wolz
maybe I try to redo it tomorrow using powerpoint, twiddla is not really usable
related to the PollableConfigurationSource: we have to consider that the whole configuration consists of a list of configurations in the osgi sense - a single Configuration knows its pid and its bundleLocation and is more or less equivalent to a SOPERA component configuration. the whole system needs configurations for each component. Maybe we need a T getConfiguration(pid) or a Map<String,T> getConfigurations(), a map indexed by pids ?


[END]

Want to join the chat? 
http://www.skype.com/go/joinpublicchat?skypename=ranyart99&topic=Swordfish%20Developers&blob=Gu7tZh64gTuo551Icz6_iwhXVeXxQ0K4yEzI5XFwGdWIQ_-miteLtgSBILodJ8koN6Uwy9PiotEU5ewRYFqEJeUtl1Yhfc1ipuVwOFz0SWN9HwMZAeikprh0R_8
-- 
Wir bieten Trainings zu SOA:
Jetzt online auf unserer Homepage informieren und schnell buchen!
 
 
Oliver Wolf
Tel.:    +49 228-182 19059
Fax:    +49 228-182 19093
Mobil:  +49 160 98931313
oliver.wolf@xxxxxxxxxx
 
 
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.com
 
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Standort Bonn: Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Standort München: Hohenlindnerstraße 11b · 85622 München
 
 
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.