I have created under src a directory called corba and another one called idl. If you subscribe to fmaps-cvs you will be informed of the changes). I have started to put some idl from the GM package. I want to see how the orbit behave
in generating the implementation...
What I found out is that it seems the UML in the iso doc is not corba compatible...
Give it a try as ArgoUML do automatic generation of IDL. Just try to implement the following objects
// Coordinate Geometry
And check with the idl in the CVS, see if the UML spec holds...
As for the various ORB I would prefer orbit as it is a gnome project after all. I have found out that orbit does what I want, I didn't read enough doc or ask the right questions... Download the source code of gnome-db and have a
look in the libgda implementation.
Yes orbit use the POA. The old version was not but now it is implemented...
Do not commit to ArgoUML yet as I'm curious of the UML to IDL conversion. I suspect that the UML is not compatible and we will have to modify it to fit... I see already several extra funcions to add to the UML....
You may see that all the boundary functions are overload which are not authorised in CORBA.
John Reid wrote:
> Hi Franck, all,
> > OK, so we do not replicate efforts, shall I concentrate on updating the metadata
> > diagram?
> After playing with dia, I have decided I would like to persevere with argouml for the time being. Dia is a great diagramming tool, but I think ArgoUML may be better suited for some deluded scheme I have in mind ;-) Especially as
> > ArgoUML has the ability (experimental) to store UML model elements in
> > a database repository. This could come in handy with the
> > application/profile schemas. This, combined with what will hopefully
> > be standard tools, might just make life much easier.
> Any objections? I will generated graphics files of class diagrams for
> those who don't want to play with Argo. I have also knocked up some
> *really rough*working notes with some links about:
> * profiles mapping UML to other languages (especially IDL)
> * Object-Relational to Relational schema mappings
> I will create a developers docs directory for working notes and commit
> these. Somewhere we can store working files that may not be ready for
> the developers manual/webpages, need some discussion first or that
> should not be part of the documentation build ;-)
> I have also created a default XMI profile for use in ArgoUML - it is not
> yet complete as I have yet to grok how to represent parameterised
> classes in Argo :-( I will add this preliminary version to a tools/uml
> >>>> <snip>
> >>>> I'm looking at CORBA and the
> >>>> orbit implementation. I have everything understood on the programmation
> >>>> part. I use orbit-idl to generate the skeletons. My problem is what is the
> >>>> difference between a standard library with its .h file and a corba
> >>>> implementation? It seems that CORBA creates EXE rather than libraries that
> >>>> you can link to... I'm a little bit confused on the issue.
> >>> I haven't really played with CORBA yet, just done some reading - so I what I am
> >>> about to say could be completely wrong. Also, keep in mind that everything that
> >>> I have read was related to C++ - I didn't even know that there was a C ORB until
> >>> I read the orbit package description last night! Plenty of Python, Java and C++
> >>> ones though. Apparently there are also Cobol ORB's available (*shudder*).
> >>> Might also be worth looking at libgda again - manual describes it as a C wrapper
> >>> around CORBA services.
> I am currently playing around with the omniorb idl compiler. There is a
> python ORB available as well as C++ released under the GPL. They have
> just released a new version (v3) which includes support for the POA. Is
> there support for this in orbit?
> >> Well I didn't do anything as part of code, excpet testing some onliners to see how
> >> code is generated. I have the feeling that CORBA is not the solution for
> >> implementing most of the ISO, because it creates executable files not libraries. I
> >> may be missing something here but I haven't seen the same fonctionality as MS OCX
> >> objects (which are libraries).
> >>> For C++ ORB's it appears that the generated skeletons define (declare?) virtual
> >>> classes which are then implemented by classes derived from these. i.e. The
> >>> virtual classes define the interface, and there has to be executable service
> >>> somewhere - though this can mainly be a wrapper to shared libraries. The
> >>> generated skeleton acts in a similar role to the header file. Think I've got
> >>> that right ;-)
> From glancing through a CORBA text the other day, could the Dynamic
> Invocation Interface, Dynamic Skeleton Interface, Portable Object
> Adapter, Interface Repositories and Trader services be what we are
> looking for?
> >>>> I think I will start to code the Spatial Schema using the CORBA syntax
> >>>> (procedure name) but doing a library and I will see later.
> >>> I have extracted the OpenGIS idl code from the Catalogue and SF-CORBA docs.
> >>> Should I commit to cvs for reference (preferably in a cvs "playground" as
> >>> proposed above)? My guess is the general structure of the OpenGIS standards is
> >>> compatible with ISO, just the implementation details related to the data schemas
> >>> differ significantly. Need to check on this though
> >> Yes would be interesting to see.
> FMaps-devel mailing list