river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: federation
Date Wed, 26 Sep 2012 19:45:26 GMT
Actually, I find that very interesting.

Config via convention (with overrides) is mostly there, I think.  We just
need to decide the convention and slot it in, so that's one hurdle.

>From my uses of River, I can think of a couple of annotations - not
necessarily the same ones - that would have been useful.  Lifecycle is
certainly interesting, especially as you go up through the layers from pure
River stuff into the business domain and what makes a service ready to do
it's job.  The question the becomes, I suppose, if there is a service
container, how does it hook in and what do those hooks look like?  Can we
draw any standard hooks out and bake them straight into River?  (This
conversation gives me deja vu.  ;-)

Gregg, does the service container you're working on have any of these kinds
of hooks?  Can you see it fitting into your work anywhere?  What kind of
help/support do you need?


On Wed, Sep 26, 2012 at 1:46 AM, Dennis Reedy <dennis.reedy@gmail.com>wrote:

> Hi Tom,
>
> I don't have developers :) There are people/organizations that use the
> framework I've lead and developed (with great input from so many), and
> people/organizations that I've worked with that want to understand how to
> deal with dynamic distributed systems. I've been fortunate enough to advise
> and apply much of the architectural principles that River brings to these
> engagements. My assertions are based on my experience.
>
> As for people who are new to any technology, I think the most important
> thing is to communicate concepts and knock down barriers for entry,
> Additionally, the project needs to show how easy it is to get something
> running. Perhaps not just get it running, but how to develop and test your
> service. Right now the bar is way too high for anybody to create a project
> using River that has full lifecycle support for:
>
> 1. Dependency management
> 2. Testing framework (not for River but for your services)
> 3. Packaging and deployment
>
> Once River can provide an approach for developers to easily develop,
> start, test and deploy their code, how can anyone really expect an uptick
> in use? Once the project accomplishes that, then lead the trail into how to
> customize and configure your services, smart proxies, dynamic systems. If
> I'm new to something, and it's a burden, I quickly turn the page and look
> elsewhere. Thats just me, but I'm not sure if it's not common with others
> as well.
>
> IMHO, the challenge for River is not configuration (sure it's a burden,
> but that can be dealt with the convention over configuration), it is
> grasping why River, and distributed services are different. Things (clients
> and service) come and go, this is the big difference. I mentioned these
> semantics before:
>
> - When has my service joined?
> - When is my service ready?
> - When should my service clean up resources?
> - Are all the things my service needs (think other services) found?
>
> With Rio, I've provided the following annotations that assist service
> developers with lifecycle transitions that we have seen to be important
> (there are other annotations, but I these are germane to the discussion):
>
> @Started: The Started annotation is used on a method in a service to allow
> the service to be notified that it has been started, that all
> infrastructure and property settings have been accomplished.
>
> @PreAdvertise: The PreAdvertise annotation is used on a method in a
> service to allow the bean to be notified before the service has been
> advertised. Note that this is important if you use Rio Associations (
> http://www.rio-project.org/associations.html). If your service strongly
> depends on (requires) other services, it will be advertised/unadvertised
> based on the availability of the services you require. Even if you are not
> using Rio associations, knowing that you have joined the network allows a
> service developer to start logic based on knowing you are discoverable.
>
> @PostUnAdvertise: The PostUnAdvertise annotation is used on a method in a
> service to allow the service to be notified after the service has been
> unadvertised. So basically, you were part of the djinn, now you're not.
> This is also important is using Rio associations, and one of your
> associated services is a requires association. Even if not using
> associations, being notified that you are no longer 'joined' is an
> important semantic. Need to checkpoint something? Clean up resources?
>
> I hope this addresses your question(s), if not let me know where I can
> elaborate/expand.
>
> Regards
>
> Dennis
>
> On Sep 25, 2012, at 742PM, Tom Hobbs wrote:
>
> > Just to prove I'm still here;
> >
> > If it's spitting out of config files you're interested in, a little while
> > ago I put some code in that allowed programmatic config generation.  I
> > forget the exact syntax, but something like;
> >
> > myconfig.setLookupGroups(grps).setName("My
> > Service").setEndpoint(EnpointType.class);
> > SeriviceStarter.start(myconfig)
> >
> > ...and so on.
> >
> > This used (from memory) Velocity (?) to create an in-memory file which
> the
> > existing ConfigurationFile bits could be fooled into thinking was a real
> > file and allow configuration off the back of that.
> >
> > Using the above, with Velocity (or whatever it was) to then write that
> file
> > to disk for tweaking, would be a reasonably trivial task.
> >
> > I'm interested in Dennis' assertion that developers are more interested
> in
> > lifecycle than config.  I think that's probably true of developers, but
> > probably not true of people new to River and who just want to write Hello
> > World services.  That's just my gut feel.  But I'm still interested in
> his
> > point.  So if we were to give Dennis' developers a magic annotation wand,
> > what kind of annotations would they like to see?  What would they look
> > like?  Or is it some other lifecycle mechanism handling thing they're
> > interested in?
> >
> >
> > On Tue, Sep 25, 2012 at 9:34 PM, Gregg Wonderly <gregg@wonderly.org>
> wrote:
> >
> >>
> >> On Sep 25, 2012, at 3:10 PM, Dennis Reedy <dennis.reedy@gmail.com>
> wrote:
> >>
> >>>
> >>> On Sep 25, 2012, at 405PM, Gregg Wonderly wrote:
> >>>
> >>>>
> >>>> On Sep 25, 2012, at 2:52 PM, Simon IJskes - QCG <simon@qcg.nl>
wrote:
> >>>>
> >>>>> On 25-09-12 21:37, Gregg Wonderly wrote:
> >>>>>
> >>>>>> From my perspective, it seems that the most predominate step
forward
> >>>>>> that we might take, would be to make all configuration used
in
> >>>>>> services be visible to tooling on the outside which could then
guide
> >>>>>> the deployment much more dependably and accelerate this small
but
> >>>>>> currently oh so fragile set of steps toward getting River up
and
> >>>>>> running in your environment.
> >>>>>
> >>>>> To me this reads like a mode where the 'easy' environment spits
out a
> >> configuration file, which if presented to the easy environment produces
> the
> >> exact same result, and allows for editting to tweak things. Does it?
> >>>>
> >>>>
> >>>> That might be one of the things which happens.  But, the annotations,
> >> ultimately, provide the metadata which defines the "parameters" of
> >> configuration which are valid.  So, tooling of all different nature can
> use
> >> that meta-data.
> >>>>
> >>>
> >>> Interesting idea! You also could create a ConfigurationProvider that
> >> writes out component, name, type, defaultValue (if any) and optional
> data.
> >> Might be a start for services that already exist and may not have
> >> annotations applied.
> >>
> >> One of the scenarios that I think about here, is that
> >> ConfigurationProvider then remains as the "interface" to configuration
> >> data.   An implementation which is constructed with a service that has
> >> annotations as being discussed here, could then read the annotations and
> >> know what should be available.  A subclass of that might be provided
> for a
> >> particular deployment environment to bridge from the annotated
> application
> >> to the runtime deployment needs as administered by the particular
> >> environments tooling.
> >>
> >> public class AnnotationNotProvidedException extends
> ConfigurationException
> >> { }
> >>
> >> public AnnotationBasedConfigurationProvider implements
> >> ConfigurationProvider {
> >>        private final Map<String,Object> configValues;
> >>        public AnnotationBasedConfigurationProvider( Remote svc ) throws
> >> AnnotationNotProvidedException {
> >>                …look for annotations and create a map for Configuration
> >> Provider containing defaults from annotations…
> >>                localConfigurationChanges();
> >>        }
> >>        protected abstract void localConfigurationChanges() throws
> >> ConfigurationException;
> >> }
> >>
> >> public RioAnnotationConfigurationProvider extends
> >> AnnotationBasedConfigurationProvider {
> >>        protected void localConfigurationChanges() throws
> >> ConfigurationException {
> >>        }
> >> }
> >>
> >> Gregg
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message