You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dan Creswell <da...@gmail.com> on 2012/09/25 09:15:49 UTC
Service Definition
Greg T from elsewhere:
"For service definition, I'm thinking something like this (starting from
your DemoServiceImpl class):
@Service(exporter="defaultExport", join="defaultJoin")
@NameEntry("DemoService")
@ServiceInfo(name="DemoService", manufacturer="Apache Software
Foundation",
model="demo-101", version="1.0")
public class DemoServiceImpl
implements DemoService
{
@Override
public String hello(String msg)
throws RemoteException
{
return "hello back: " + msg ;
}
}
"
I kinda like the convenience of this equally there's some stuff I don't
like....A number of those aspects are run/deployment-time configuration,
they shouldn't be sitting in the code. NameEntry for one but, if you ask
me, exporter as well.
Do you want SysAdmin's wading through code? Heck, do *they* want to wade
through code?
So we're back to Greg's remark re: stilton.
If we really see value in the above, can we consider providing something
else that works for an ops team too? (Cos none I've ever come across would
touch the above with a barge-pole). Or can we at least make it clear what
mechanisms should be in place for "best practice" (jeez, I hate that term).
Two cents,
Dan.
Re: Service Definition
Posted by Greg Trasuk <tr...@stratuscom.com>.
Comments interspersed...
Greg.
On Tue, 2012-09-25 at 03:59, Dan Creswell wrote:
> On 25 September 2012 08:46, Simon IJskes - QCG <si...@qcg.nl> wrote:
>
> > On 25-09-12 09:15, Dan Creswell wrote:
> >
> > If we really see value in the above, can we consider providing something
> >> else that works for an ops team too? (Cos none I've ever come across would
> >> touch the above with a barge-pole). Or can we at least make it clear what
> >> mechanisms should be in place for "best practice" (jeez, I hate that
> >> term).
> >>
Sure. No reason you can't also have an external configuration, and make
it so the external config overrides the annotation-based config. That's
exactly the way it is in EE5/EE6. The practise there seems to be that
coders put a "baseline" config into the annotations, and ops team
overrides them in the config file if appropriate.
There also seems to be a lot of cases in the EE5/EE6 world that I talk
to where there isn't the coders are the ops team, or where ops treats
the app as a black box, so annotations are mostly it. At the same time,
many places seem to have an ops team that is competent and involved. So
the mechanism needs to handle both cases.
> >
> > Glad you introduced ops teams. Would a middle ground be possible? Two
> > options: A annotation refering to a part in a deployment configuration
> > file, or using the annotations as defaults, and provide ops team with a
> > overriding option?
> >
> >
> I was edging towards the latter whilst scribbling the above...
>
>
> > Gr. Simon
> >
> >
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 11:32, Greg Trasuk wrote:
> @Service(attributes= {
> @NameEntry(...), @ServiceInfo(...) } )
>
> But I started thinking that the syntax starts getting too complicated.
Indeed, lets leave it with the simpler, flatter variant.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Tue, 2012-09-25 at 05:05, Simon IJskes - QCG wrote:
> On 25-09-12 10:32, Simon IJskes - QCG wrote:
> > On 25-09-12 09:59, Dan Creswell wrote:
> >>> Glad you introduced ops teams. Would a middle ground be possible? Two
> >>> options: A annotation refering to a part in a deployment configuration
> >>> file, or using the annotations as defaults, and provide ops team with a
> >>> overriding option?
> >> I was edging towards the latter whilst scribbling the above...
> >
> > We need an id to hang overrides onto, so i've created the ServiceClass
> > annotation. Greg, are you ok with this?
>
> Or do we use the Class as an id?
I think you'd probably use the class name to identify which class the
overrides belong to. I kind of pictured the "@Service" annotation as
being the touchpoint that says "this class should be instantiated and
configured as a service", and then the other annotations simply adding
detail to that.
Another option would be nesting annotations, e.g.
@Service(attributes= {
@NameEntry(...), @ServiceInfo(...) } )
But I started thinking that the syntax starts getting too complicated.
Greg.
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 10:32, Simon IJskes - QCG wrote:
> On 25-09-12 09:59, Dan Creswell wrote:
>>> Glad you introduced ops teams. Would a middle ground be possible? Two
>>> options: A annotation refering to a part in a deployment configuration
>>> file, or using the annotations as defaults, and provide ops team with a
>>> overriding option?
>> I was edging towards the latter whilst scribbling the above...
>
> We need an id to hang overrides onto, so i've created the ServiceClass
> annotation. Greg, are you ok with this?
Or do we use the Class as an id?
Re: Service Definition
Posted by Gregg Wonderly <gr...@gmail.com>.
For me, the question is whether there is something to get out of annotation processing. Like, for example, generating a "text" config file that matches/extracts all the data that the annotations represent. That would allow ops teams to have "everything" in hand to "tweak". They'd know everything that the developer had allowed them to tweak, and what the defaults were.
Gregg Wonderly
On Sep 25, 2012, at 7:11 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 25-09-12 11:26, Greg Trasuk wrote:
>>
>> On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote:
>>> On 25-09-12 09:59, Dan Creswell wrote:
>>>>> Glad you introduced ops teams. Would a middle ground be possible? Two
>>>>> options: A annotation refering to a part in a deployment configuration
>>>>> file, or using the annotations as defaults, and provide ops team with a
>>>>> overriding option?
>>>> I was edging towards the latter whilst scribbling the above...
>>>
>>> We need an id to hang overrides onto, so i've created the ServiceClass
>>> annotation. Greg, are you ok with this?
>>
>> Sure. I suspect we need to flesh out some samples and see how they
>> look, then edit the "annotation vocabulary".
>
> I've created <http://svn.apache.org/viewvc/river/jtsk/trunk/netbeans/federation/src/org/apache/river/federation/IntrospectionConfiguration.java?view=markup>.
>
> Would this be too much encapsulation? It would be nice if we had some kind of introspection information collector where we can put all annotation parsing.
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 11:26, Greg Trasuk wrote:
>
> On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote:
>> On 25-09-12 09:59, Dan Creswell wrote:
>>>> Glad you introduced ops teams. Would a middle ground be possible? Two
>>>> options: A annotation refering to a part in a deployment configuration
>>>> file, or using the annotations as defaults, and provide ops team with a
>>>> overriding option?
>>> I was edging towards the latter whilst scribbling the above...
>>
>> We need an id to hang overrides onto, so i've created the ServiceClass
>> annotation. Greg, are you ok with this?
>
> Sure. I suspect we need to flesh out some samples and see how they
> look, then edit the "annotation vocabulary".
I've created
<http://svn.apache.org/viewvc/river/jtsk/trunk/netbeans/federation/src/org/apache/river/federation/IntrospectionConfiguration.java?view=markup>.
Would this be too much encapsulation? It would be nice if we had some
kind of introspection information collector where we can put all
annotation parsing.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 03-10-12 12:09, Greg Trasuk wrote:
>
> I'm not sure what you mean. Are you thinking something like this?:
>
> Entry[] entries=EntryAnnotationReader.readEntries(MyService.class);
>
> So the EntryAnnotationReader is a utility class that knows how to
> introspect the class and translate its annotations to a set of Entry
> classes.
Yes, but not a static method. But you were thinking about annotations
that specify things like which Exportor and such did you?
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Greg Trasuk <tr...@stratuscom.com>.
I'm not sure what you mean. Are you thinking something like this?:
Entry[] entries=EntryAnnotationReader.readEntries(MyService.class);
So the EntryAnnotationReader is a utility class that knows how to
introspect the class and translate its annotations to a set of Entry
classes.
Cheers,
Greg.
On Tue, 2012-10-02 at 08:32, Simon IJskes - QCG wrote:
> On 25-09-12 11:26, Greg Trasuk wrote:
> >
> > On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote:
> >> On 25-09-12 09:59, Dan Creswell wrote:
> >>>> Glad you introduced ops teams. Would a middle ground be possible? Two
> >>>> options: A annotation refering to a part in a deployment configuration
> >>>> file, or using the annotations as defaults, and provide ops team with a
> >>>> overriding option?
> >>> I was edging towards the latter whilst scribbling the above...
> >>
> >> We need an id to hang overrides onto, so i've created the ServiceClass
> >> annotation. Greg, are you ok with this?
> >>
> >>
> >
> > Sure. I suspect we need to flesh out some samples and see how they
> > look, then edit the "annotation vocabulary".
>
> So we would create an 'EntryLookup' interface, and implement this with a
> 'EntryIntrospector'? This concept can be extended with a registry that
> contains a map<Class,Entry[]> or something like that, so we can prime
> the lookup, for classes not annotated.
>
> Gr. Simon
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 11:26, Greg Trasuk wrote:
>
> On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote:
>> On 25-09-12 09:59, Dan Creswell wrote:
>>>> Glad you introduced ops teams. Would a middle ground be possible? Two
>>>> options: A annotation refering to a part in a deployment configuration
>>>> file, or using the annotations as defaults, and provide ops team with a
>>>> overriding option?
>>> I was edging towards the latter whilst scribbling the above...
>>
>> We need an id to hang overrides onto, so i've created the ServiceClass
>> annotation. Greg, are you ok with this?
>>
>>
>
> Sure. I suspect we need to flesh out some samples and see how they
> look, then edit the "annotation vocabulary".
So we would create an 'EntryLookup' interface, and implement this with a
'EntryIntrospector'? This concept can be extended with a registry that
contains a map<Class,Entry[]> or something like that, so we can prime
the lookup, for classes not annotated.
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Service Definition
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Tue, 2012-09-25 at 04:32, Simon IJskes - QCG wrote:
> On 25-09-12 09:59, Dan Creswell wrote:
> >> Glad you introduced ops teams. Would a middle ground be possible? Two
> >> options: A annotation refering to a part in a deployment configuration
> >> file, or using the annotations as defaults, and provide ops team with a
> >> overriding option?
> > I was edging towards the latter whilst scribbling the above...
>
> We need an id to hang overrides onto, so i've created the ServiceClass
> annotation. Greg, are you ok with this?
>
>
Sure. I suspect we need to flesh out some samples and see how they
look, then edit the "annotation vocabulary".
Greg.
>
>
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 09:59, Dan Creswell wrote:
>> Glad you introduced ops teams. Would a middle ground be possible? Two
>> options: A annotation refering to a part in a deployment configuration
>> file, or using the annotations as defaults, and provide ops team with a
>> overriding option?
> I was edging towards the latter whilst scribbling the above...
We need an id to hang overrides onto, so i've created the ServiceClass
annotation. Greg, are you ok with this?
Re: Service Definition
Posted by Dan Creswell <da...@gmail.com>.
On 25 September 2012 08:46, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 25-09-12 09:15, Dan Creswell wrote:
>
> If we really see value in the above, can we consider providing something
>> else that works for an ops team too? (Cos none I've ever come across would
>> touch the above with a barge-pole). Or can we at least make it clear what
>> mechanisms should be in place for "best practice" (jeez, I hate that
>> term).
>>
>
> Glad you introduced ops teams. Would a middle ground be possible? Two
> options: A annotation refering to a part in a deployment configuration
> file, or using the annotations as defaults, and provide ops team with a
> overriding option?
>
>
I was edging towards the latter whilst scribbling the above...
> Gr. Simon
>
>
Re: Service Definition
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 25-09-12 09:15, Dan Creswell wrote:
> If we really see value in the above, can we consider providing something
> else that works for an ops team too? (Cos none I've ever come across would
> touch the above with a barge-pole). Or can we at least make it clear what
> mechanisms should be in place for "best practice" (jeez, I hate that term).
Glad you introduced ops teams. Would a middle ground be possible? Two
options: A annotation refering to a part in a deployment configuration
file, or using the annotations as defaults, and provide ops team with a
overriding option?
Gr. Simon