[Ace-users] Re: [ciao-users] CIAO productivity tools ...

[Krishnakumar B]

Hi Sandro,

On Fri, 31 Aug 2007 06:11:05 PM -0500, Sandro Andrade wrote:
> Hello all,
>
> I have been wondering for some time about how to leverage development
> productivity when using TAO/CIAO technologies. It's clear for everyone
> the benefits introduced by CCM when compared to CORBA 2.x development
> model but it's also evident that CCM-based development implies
> worrying about middleware-specific artifacts.
>
> In that scenario, my questions are:
>
> 1) What's the current status of CoSMIC toolchain ?

The toolchain is pretty stable.  The only weakness is the lack of
professional documentation...

> How much does CoSMIC abstract the middleware-specific artifacts from the
> developer ?

Pretty much everything.  There are generators (as well as importers for
some artifacts) for most artifacts including IDL files, CIDL files, MPC
files, component packages (ZIP files) as well as all of the deployment
descriptors necessary to deploy a CCM component using D+C.  We could do
with some integration with the Repository Manager and the Naming Service,
but it's not a show stopper.

> 2) We know that MDA is a very promising technology for potencial model
> reuse but wouldn't it be better if there is a more easy-to-use
> approach ? I mean, using CoSMIC requires understanding the MDA process
> and developing of PIM models.

I agree with Doug's answers to these questions.

> What about the EJB3 annotated classes approach ? Classes look like
> ordinary classes (POJO - Plain Old Java Objects) and annotations are used
> to guide the deployment process.  There isn't initial need for callback
> methods and deployment descriptors. Of course, we would need a more
> clever container and deployment infra-structure but I think this is a
> good approach for development productivity.

Annotated classes are a good approach to get something up and running early
on in the development lifecycle, or in small-scale component systems.
Deployment of large-scale component systems will definitely require
information that is simply not going to be available or easily replicated
during development.  So the annotations in the code will require overriding
at deployment time.  That's why EJB didn't remove the option to use
deployment descriptors.  It makes you wonder what is finally gained by
these annotations apart from forcing developers to write more code.  And I
don't even want to get into what happens if you annotate incorrectly.  Are
we going to need an annotation compiler?  Will such a compiler be able to
look at these classes from a global perspective?  How do you resolve
ambiguities in annotations, i.e., characteristics that apply only in some
uses of a class?

Please also note that the unfortunate choice of using XML to describe the
deployment descriptors as well the lack of using high-level techniques like
MDE are what prompted the introduction of techniques like "dependency
injection".  AFAIK, EJB still doesn't have a notion of describing
connections among components by entities that are outside of the component
implementation.

IMHO, all of these techniques like annotations will fall out of favour once
the deployment tools mature and/or when MDE becomes more popular.  Since
these techniques require operating at the level of code as opposed to
high-level abstractions, I think that they are a throwback from making
developers think about system-level issues.

Annotations are, however, useful for capturing pre-conditions,
post-conditions and invariants of a class.  For example, one could probably
do things like model extraction from source code, model checking of source
code using annotations.  In such scenarios, the functionality of a class
should never be different from the annotations.  IMHO, using annotations to
capture things that will definitely change during deployment is just a
waste of time.

> We have been working on the development of a visual configuration and
> deployment tool for CIAO/DAnCE: the ATOME tool (http://atome.sf.net -
> sorry ! yet in portuguese). The general idea is to insulate the developer
> from CIAO-specific artifacts like IDL/CIDL/MPC files, executors and
> deployment XML descriptors and provide a visual environment for component
> composition and deployment and DAnCE repositories integration.

>From looking at the screenshots, it looks like the tool tries to achieve
something very similar to what PICML already does.  I would highly
recommend that you play with CoSMIC to get a sense of what is already
available.

-kitty.

-- 
Krishnakumar B <kitty at dre dot vanderbilt dot edu>
Institute for Software Integrated Systems, Dept. of EECS, Vanderbilt University