Re: stereotype service (was: underlying politics)

[Torsten Schulz <Torsten Schulz germany sun com>]

> On Fri, 20 Oct 2000, Dietmar Maurer wrote:
>> > Actually it is possible to emulate services within BONOBOs approach.
>> > We could specify an EMPTY interface for each service and then
>> > specify all the stuff within this interface instead of a service.
>> > This would be like: "An object which implements this interface has
>> > to implement the interfaces XA and XB as well." We just have a
>> > notation for that - and a special stereotype.
>> 
>> AFAIK CORBA does not has the service concept? So this would imply
>> an extension of the CORBA IDL.

>         When I spoke to Torsten about the service concept he informed me
> that it was merely a contract definition spec. that tells you what
> interfaces are available from the queryInterface action thus:

> service Cell {
>         interface XCell;
>         interface XFormatProperties;
>         interface XSheetItem;
  
>         etc. etc.
> };
>         forms an aggregate object definition, and that no code was
> generated from this construct. So, surely we already have the concept well
> enshrined in the architecture, we just don't have the fragments of IDL and
> the 'prepend X before every real interface' thing ( which I have a rather
> dim view of personaly :-).

>         It seems I must have misunderstood your above comments however; is
> it possible un UNO land to do a query_interface on 'Cell'

  no, you can only query for _interfaces_
  
> and if so; what 
> interface do you get ? I can see that having oaf specify 'services' might
> be useful, but this can be achieved anyway by just specifying the
> collection of interfaces that you require.

  The service stereotype in UNO IDL is a just a way do make contracts
on a higher level of granularity as interfaces provide. It actually has
no impact on generated code nor any behavior of the activation
process at runtime (am I right Michael H.?), except that servers and
clients can refer to the identifier of the service (...::Cell) when
registering and factory and querying for a service implementation.

  But it is still very important for StarOffice API because it
clarifies the behavior of components. Because the definition of 'what
provides a Cell component' is specified - unfortunately not proved at
runtime - we avoid inconsistence and different interpretations.

  In fact the service stereotype is just a documentation, but it is a
formalized documentation and we want to take more advantages from it
in the future, like automatic skeleton generation, introspection,
debugging, advanced scripting support etc.


-- 
Best regards,
 Torsten                            mailto:Torsten Schulz germany sun com