Peter Donald wrote:
> On Wed, 28 Aug 2002 22:50, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>Hi,
>>>
>>>I have been playing with the idea of having Services as first class
>>>metadata objects. By this I mean it would be possible to load a
>>>ServiceInfo class. ie You could load both ComponentInfo and ServiceInfo
>>>objects. The ServiceInfo objects would contain metadata specific to the
>>>object.
>>>
>>>The advantages of this is that you associate metadata with a service
>>>independent of an implementation. So this would allow you to indicate
>>>that all implementations of this service are pass-by-value objects or
>>>support soap/altrmi bindings. It would also allow us to generate webpages
>>>for each service aswell as each component.
>>
>>Hmmm... are not services simply Objects?
>
> No they are versioned java interfaces in most cases.
Hmmm... there is no imposition about this in Serviceable... hmmm...
>>If I use an existing service with no metadata, I loose the ability to
>>specify this?
>
> No - it just has no metadata associated with it (much like now).
Ok.
I didn't know a Service didn't have metadata, apart from the
COmponent->Object thing I don't see differences.
>>>Secondly, what do you think of having metadata about individual features
>>>in a service (ie methods/propertys). If we were to do that then we could
>>>pretty much model any of the various component systems out there. It
>>>would also get rid of a bunch of "extra" descriptors (like the mxinfo
>>>stuff in phoenix). However it adds a massive amount of overhead - what
>>>doyou think?
>>
>>Hmmm... I don't get the immediate value of repeating the method names
>>somewhere else... hmmm...
>>
>>example?
>
>
> the mxinfo files in phoenix essentially define management information for a
> component. As a result they include things like
>
> <attribute
> name="addressString"
> description="Address String"
> isWriteable="no"
> type="java.lang.String"
> />
>
> or
>
> <operation
> name="getServerPort"
> description="Returns port that the server listens on"
> type="java.lang.String"
> >
> <param
> name="instance"
> description="no description"
> type="java.lang.Integer"
> />
> </operation>
>
> These are things that are needed to automagically assembly nicely looking
> MBeans.
Ah, ok, I like this.
The doclet stuff, huh?
I thought it was already there :-)
> There is also other value to this. Paul could add transaction or security
> attributes per method for EOB. He would then be capable of doing everything
> EJB could theoreitcally.
Hmmm... I understand.
But for this, I have the sense that it's overkill to get to this level,
to go down to /generic/ *method* attributes.
So I can have Component lifestyle, method lifestyle... it gets me dizzy...
> Hell - you could even dynamically assembly the interface using BCEL if the
> service is remote service or someother stuff by just looking at descriptor.
I thought of this, yes, or even wrap non-java stuff.
> However I am not sure that there is enough value in going down to that level
> of granularity or not.
Now we are getting to a point in which the metadata describes the role,
right?
Some thought that interfaces were the role, then we understood that some
didn't have methods and it was bad, so we used metadata.
Heck, go with metadata only and you have a formal role specification, right?
It's good, it finally defines a generic contract fot the Service that is
not merely a string or human-readable javadoc.
So, if I write a Service, I don't have to write the interface
theoretically, because the metdata *is* the interface (and more).
Now, how do I keep in sync the two (in case I define the Service, if I
use ready made I just can write the descriptor in xml)?
1) use services via generic utility methods and loose strict type checking
2) make the interface by hand, or the metadata by hand, or both, and
have a doclet-like system that keeps *both* in sync.
3) other?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
