synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: Job language syntax in the Synapse configuration
Date Mon, 24 Sep 2007 08:18:41 GMT
Paul,

I still do not agree to one single <startup> tag. One single startup tag
implies wrapping (grouping) all startups in to one tag right? We had this
kind of a configuration earlier and dropped these wrapping elements for the
simplicity and I just don't like grouping the elements in the configuration.

Here is my point;
Say we have <job> now, and <xyz> in the future as startup impls, but id and
may be tracing, statistics (may be in the future) like attributes are common
to all startups not just to jobs (SimpleQuartzStartup) or even to xyz. So it
is good to abstract out those common attributes to a higher abstraction
layer IMO, to *AbstractStartup*.

At the same time if we have multiple startups, it is good to have that
startup element with its common attributes in the top level so that the
configuration will be clean. This does not mean we should group all the
startup elements in to one single startup element, because we have common
but unique attributes for each and every startup.

WDYT?

BTW: I have done the refactoring up to some extent and will modify that as
per the discussion (changing the <job> to <onAlarm>).

Do we need to change the class names as well??? I prefer to change those as
well to have the right transparency...

Thanks,
Ruwan

On 9/24/07, Paul Fremantle <pzfreo@gmail.com> wrote:
>
> Ok I agree - I've never been good at names :-)
>
> I think there is one more issue. The "onAlarms" are the things that
> should have names.
>
> So the syntax should be
>
> <startup>
>
>   <onAlarm id='blah' .../>
>   <onAlarm id='foo' ..../>
>
> </startup>
>
> There is no need for multiple <startup> tags that are named.
>
> Finally, should we make it <onStartup> to match onAlarm?
>
> Paul
>
> On 9/24/07, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> > So .. I think this is not right yet.
> >
> > The problem is that we're using *two* very generic terms: "startup" and
> > "job". I believe that with our current semantics, the prior means "do
> this
> > as you start up" and the latter means "execute a Java class at a given
> > clock ala cron". Is that right?
> >
> > What I suggest is that we keep <startup> but change <job> to something
> > like this:
> >    <onAlarm class="..">
> >      <simpleTrigger ..> | <cronTrigger ..>
> >      <other stuff>
> >    </onAlarm>
> >
> > I actually don't like simpleTrigger etc. - I'd prefer something like:
> >    <timer cron=..> and
> >    <timer count=.. delay=..>
> >
> > This way, its clear that <onAlarm> is simply a task executed upon some
> > trigger. We currently only have timer triggers but we could later have
> > different triggers too.
> >
> > In the future if we want something other than an alarm triggered task
> > executed at init time, then we can have new xml for that and just have
> it
> > execute. For example, I can see a <log> action being a useful startup
> > thing .. log a message to some place when the system starts up? (I did
> say
> > in the future BTW!)
> >
> > Sanjiva.
> >
> > Ruwan Linton wrote:
> > > After deeply looking in to Paul's code on the startup factory and
> > > serialization, I thought of the syntax again with keeping Paul's
> points
> > > about the startup element on this thread in my mind, I think the
> > > following configuration is clean and clear.
> > >
> > > <definitions>
> > >  <startup id="startup1">
> > >   <job class="MessageInjector">
> > >      ......
> > >   </job>
> > >  </ startup>
> > >  <startup id="startup-n">
> > >   <$ANY_TAG_REGISTERED_WITH_STARTUPFINDER ...../>
> > >  </startup>
> > > </definitions>
> > >
> > > (one startup per startup element and there can be number of startups
> in
> > > the synapse def as in proxy definitions)
> > >
> > > This syntax will add an id to startups so that we can control them at
> > > runtime (if needed) because there is an indexing mechanism. This
> syntax
> > > will be same as proxy syntax from the configuration point of view.
> > >
> > > This also requires a certain amount of refactoring and I am ready to
> go
> > > ahead with that.
> > >
> > > Thanks,
> > > Ruwan
> > >
> > > On 9/21/07, *Ruwan Linton* < ruwan.linton@gmail.com
> > > <mailto:ruwan.linton@gmail.com>> wrote:
> > >
> > >     +1 for the option [3] and I am happy to do the refactoring if we
> > >     have decided to go with this option. (Indeed my original proposal
> > >     was this)
> > >
> > >     BTW: Serializer does not seem to be working properly.. (When I
> tried
> > >     to start synapse using a configuration with a startup job it
> builds
> > >     the job correctly but does not serializes the job on serializing
> the
> > >     config (I will look in to this).
> > >
> > >     Thanks,
> > >     Ruwan
> > >
> > >
> > >     On 9/20/07, *Paul Fremantle* < pzfreo@gmail.com
> > >     <mailto:pzfreo@gmail.com>> wrote:
> > >
> > >         I'm not sure everyone is clear - maybe its because I haven't
> yet
> > >         documented this :-)
> > >
> > >         There is a new type of extension point called a Startup with a
> > >         Factory... just like Mediators.
> > >         Job is a type of Startup - with its own XML, just like a
> mediator
> > >         defines its own XML.
> > >
> > >         So if we added another type of Startup then it would have a
> > >         different
> > >         tagname. So at the moment we can have:
> > >
> > >         <startup>
> > >           <job....>...</job>
> > >           <asankha>
> > >              <scheduled to work 24x7x265>
> > >           </asankha>
> > >         </startup>
> > >
> > >         So there are three choices:
> > >
> > >         1) Keep a wrapper element for all "startups"
> > >         2) remove the flexibility to have different startups
> > >         3) Refactor the code so it can tell if its a startup or a
> mediator
> > >         when it hits the tag QName and do the right thing for each.
> > >
> > >         Paul
> > >
> > >         On 9/20/07, Asankha C. Perera < asankha@wso2.com
> > >         <mailto:asankha@wso2.com>> wrote:
> > >         >
> > >         >  Well.. if we have other types of jobs.. can we do something
> like
> > >         >
> > >         >  <definitions>
> > >         >    ...
> > >         >    <job class="x.y.z.Quartz"....>
> > >         >    <job class="a.b.c.Marble"....>
> > >         >
> > >         >    ...
> > >         >  </definitions>
> > >         >
> > >         >  thanks
> > >         >  asankha
> > >         >
> > >         >  Paul Fremantle wrote:
> > >         >  Do you envisage we will have other kinds of Startup or
> should
> > >         we pull
> > >         >  the pluggability for that?
> > >         >
> > >         >  Paul
> > >         >
> > >         >  On 9/20/07, Asankha C. Perera <asankha@wso2.com
> > >         <mailto:asankha@wso2.com>> wrote:
> > >         >
> > >         >
> > >         >  Paul
> > >         >
> > >         >  Opps.. nope.. the opposite of it..
> > >         >
> > >         >  e.g.
> > >         >  <definitions>
> > >         >  ...
> > >         >  <job....>*
> > >         >  ....
> > >         >  <proxy... >*
> > >         >  ....
> > >         >  </definitions>
> > >         >
> > >         >  thanks
> > >         >  asankha
> > >         >
> > >         >
> > >         >  Paul Fremantle wrote:
> > >         >  I'm not clear from your note, but I think you are saying
> there
> > >         should
> > >         >  be a top level tag that holds the jobs:
> > >         >
> > >         >  e.g.
> > >         >
> > >         >  <definitions>
> > >         >  <xxxxx>
> > >         >  <job>...</job>
> > >         >  </xxxxx>
> > >         >  ...
> > >         >
> > >         >  Is that what you meant?
> > >         >
> > >         >  Paul
> > >         >
> > >         >  On 9/20/07, Asankha C. Perera < asankha@wso2.com
> > >         <mailto:asankha@wso2.com>> wrote:
> > >         >
> > >         >
> > >         >  Paul / Ruwan
> > >         >
> > >         >  However, I agree we could do it. Thoughts from others?
> > >         >
> > >         >  Well.. when we finalized the config language syntax, we had
> a
> > >         top level
> > >         >  "definitions" and then one or more "proxy", "sequence",
> > >         "endpoint" etc
> > >         >  definitions. So I guess the "job" definitions should be
> > >         handled the same for
> > >         >  consistency.
> > >         >
> > >         >  asankha
> > >         >
> > >         >
> > >         >  On 9/20/07, Ruwan Linton <ruwan.linton@gmail.com
> > >         <mailto:ruwan.linton@gmail.com>> wrote:
> > >         >
> > >         >
> > >         >  Hi all,
> > >         >
> > >         >  For the moment the configuration for the jobs seems to be
> like
> > >         following;
> > >         >
> > >         >  <definitions>
> > >         >  <startup>
> > >         >  <job ...../>*
> > >         >  </startup>
> > >         >  ......
> > >         >  </definitions>
> > >         >
> > >         >  The <startup> element is wrapping all the jobs. With
> compared
> > >         to other
> > >         >  elements in the configuration like <sequence>, <endpoint>
> and
> > >         all they are
> > >         >  top level elements even mediators can appear in the top
> level
> > >         in which case
> > >         >  that collection is treated as the main sequence. So I
> propose
> > >         to bring the
> > >         >  <jobs> element to the top level as follows;
> > >         >
> > >         >  <definitions>
> > >         >  <registry ..../>?
> > >         >  <proxy .../>*
> > >         >  <sequence .../>*
> > >         >  <endpoint ..../>*
> > >         >  <job .../>*
> > >         >  <localEntry .../>*
> > >         >  (mediator)*
> > >         >  </definitions>
> > >         >
> > >         >  If we do have multiple types of jobs then we can let the
> > >         FactoryFinder to
> > >         >  handle that. Is there any particular reason that I am
> missing
> > >         here? If not
> > >         >  shall we bring these jobs to the top level before 1.1release?
> > >         >
> > >         >  Thanks,
> > >         >  Ruwan
> > >         >
> > >         >  --
> > >         >  Ruwan Linton
> > >         >  http://www.wso2.org - "Oxygenating the Web Services
> Platform"
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >
> > >
> > >         --
> > >         Paul Fremantle
> > >         Co-Founder and VP of Technical Sales, WSO2
> > >         OASIS WS-RX TC Co-chair
> > >
> > >         blog: http://pzf.fremantle.org
> > >         paul@wso2.com <mailto:paul@wso2.com>
> > >
> > >         "Oxygenating the Web Service Platform", www.wso2.com
> > >         <http://www.wso2.com>
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > >         To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > >         <mailto:synapse-dev-unsubscribe@ws.apache.org>
> > >         For additional commands, e-mail:
> synapse-dev-help@ws.apache.org
> > >         <mailto:synapse-dev-help@ws.apache.org>
> > >
> > >
> > >
> > >
> > >     --
> > >
> > >     Ruwan Linton
> > >     http://www.wso2.org - "Oxygenating the Web Services Platform"
> > >
> > >
> > >
> > >
> > > --
> > > Ruwan Linton
> > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>


-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Mime
View raw message