comp.lang.ada
 help / color / mirror / Atom feed
* Ada -> IDL (this is not a typo!)
@ 1998-12-02  0:00 Marc A. Criley
  1998-12-03  0:00 ` Brad Balfour
  1998-12-03  0:00 ` Alan Jenkins
  0 siblings, 2 replies; 4+ messages in thread
From: Marc A. Criley @ 1998-12-02  0:00 UTC (permalink / raw)


While the CORBA/Ada vendors provide IDL compilers to
generate Ada 95 from the IDL, is there a "decompiler"
that does the reverse?

Given a set of type declarations in a package (and the
packages that are depended upon) that are used for
external interfacing, is there a tool out there
that will generate corresponding IDL?

"I speak not for my employer"

-- 
Marc A. Criley
Chief Software Architect
Lockheed Martin M&DS
marc.a.criley@lmco.com
Phone: (610) 354-7861




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ada -> IDL (this is not a typo!)
  1998-12-02  0:00 Ada -> IDL (this is not a typo!) Marc A. Criley
  1998-12-03  0:00 ` Brad Balfour
@ 1998-12-03  0:00 ` Alan Jenkins
  1 sibling, 0 replies; 4+ messages in thread
From: Alan Jenkins @ 1998-12-03  0:00 UTC (permalink / raw)



It's a longshot, but Rational Rose provides a reverse engineering mechanism - 
this will take your Ada and reverse engineer it as a UML Model. From their. 
you can use Rose to generate the IDL from the reverse engineered model.

A bit of a long way round I guess.

Alan.

In article <366543C6.3E232C33@lmco.com>, "Marc A. Criley" 
<marc.a.criley@lmco.com> wrote:
>While the CORBA/Ada vendors provide IDL compilers to
>generate Ada 95 from the IDL, is there a "decompiler"
>that does the reverse?
>
>Given a set of type declarations in a package (and the
>packages that are depended upon) that are used for
>external interfacing, is there a tool out there
>that will generate corresponding IDL?
>
>"I speak not for my employer"
>




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ada -> IDL (this is not a typo!)
  1998-12-02  0:00 Ada -> IDL (this is not a typo!) Marc A. Criley
@ 1998-12-03  0:00 ` Brad Balfour
  1998-12-04  0:00   ` Marc A. Criley
  1998-12-03  0:00 ` Alan Jenkins
  1 sibling, 1 reply; 4+ messages in thread
From: Brad Balfour @ 1998-12-03  0:00 UTC (permalink / raw)


In article <366543C6.3E232C33@lmco.com>, "Marc A. Criley" <marc.a.criley@lmco.com> wrote:
>While the CORBA/Ada vendors provide IDL compilers to
>generate Ada 95 from the IDL, is there a "decompiler"
>that does the reverse?
>Given a set of type declarations in a package (and the
>packages that are depended upon) that are used for
>external interfacing, is there a tool out there
>that will generate corresponding IDL?

No, not to my knowledge.

It is certainly technically feasible, but I'm not sure that the result is what 
you'd like. Let me explain:

[A] Feasible:
It is quite possible to create a mapping from an Ada package specification to 
the corresponding IDL declarations. However, the OMG (and its Ada revision 
task force) have not done so. Most Ada constructs mapping from IDL to Ada is 
trivially reversable from Ada to IDL.
There are certain Ada constructs that don't have an obvious mapping to IDL 
(e.g., access types or private types). Certain patterns in Ada would need to 
be recognized and mapped onto IDL constructs. However, such a mapping is 
technically possible.
In fact, Objective Interface's ORBexpress idl2ada tool has been architected to 
not only emit Ada from IDL, but to be able to read that Ada back in. Among 
several possible future enhancements to the tool is a reverse mapping as you 
have proposed. However, that feature is not present in the current product.

[B] Desirable:
Given that it is possible, you might wonder why no one has done it. Certainly, 
the proposal comes up on a regular basis. Why have no CORBA developers come 
pounding on the ORB vendors doors demanding this feature?

Let me describe one major area where an Ada package and an IDL interface 
differ:
An Ada package specification exports subprograms. The semantics of these are 
those of local procedure/function calls within a process. An IDL interface is 
a (potentially) distributed interface. Calls to the operations in an IDL 
interface may result in a remote invocation of the operation's implementation 
(in another process, possibly on another machine). Clearly, while the function 
behavior of these two operations may be identical, the performance and other 
kinds of semantics may not.

As an example, it is common to design an Ada package to export a "list" type 
with an associated iterator. A programmer then calls on the package to set up 
the list/iterator and to retrieve the first value. Then, in a loop, the 
programmer calls "get_next" repeatedly to get & process each value. This is a 
classic design and a common package interface. It is also horribly designed 
IDL.

If one were to create a (potentially remote) IDL interface with this iterator 
model, the programmer would find that the performance is unacceptable. It is 
very expensive (relatively speaking) to call the remote implementation in 
order to return a single "element" of the "list". A much more efficient remote 
interface will "batch up" the results and return a series (i.e., a sequence) 
of these "list elements" to the client in a single remote call. The client 
then iterates through them locally.

[C] The Conclusion:
It is often desirable/necessary to redesign some/many/all of the interfaces to 
account for the potentially distributed nature of IDL. While this doesn't 
eliminate the desire or need for a tool like Marc describes, it does explain 
why the process isn't as automatable as one might think.

All that having been said, however, should Marc or anyone else really want 
such a tool, we'd never turn down money to build one for you :-)

I hope that this explanation answers your questions.

Thanks,
Brad


--
Brad Balfour
Director of Technology Services
Objective Interface
Brad.Balfour@ois.com    703/295-6533 (voice)   703/295-6501 (fax)




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ada -> IDL (this is not a typo!)
  1998-12-03  0:00 ` Brad Balfour
@ 1998-12-04  0:00   ` Marc A. Criley
  0 siblings, 0 replies; 4+ messages in thread
From: Marc A. Criley @ 1998-12-04  0:00 UTC (permalink / raw)
  To: Brad Balfour

Brad Balfour wrote:
> 
> In article <366543C6.3E232C33@lmco.com>, "Marc A. Criley" <marc.a.criley@lmco.com> wrote:
> >While the CORBA/Ada vendors provide IDL compilers to
> >generate Ada 95 from the IDL, is there a "decompiler"
> >that does the reverse?
> >Given a set of type declarations in a package (and the
> >packages that are depended upon) that are used for
> >external interfacing, is there a tool out there
> >that will generate corresponding IDL?
> 
> No, not to my knowledge.
> 
> It is certainly technically feasible, but I'm not sure that the result is what
> you'd like. Let me explain:
> 
> [A] Feasible:
> It is quite possible to create a mapping from an Ada package specification to
> the corresponding IDL declarations. However, the OMG (and its Ada revision
> task force) have not done so. Most Ada constructs mapping from IDL to Ada is
> trivially reversable from Ada to IDL.

Brad,

Thanks for your comments.  Indeed they help me focus better on what
exactly I was interested in.  It's not so much a full-blown IDL->Ada
converter, as something more along the lines of the c2ada tool that
converts C headers to Ada.  I was looking for something that would convert
Ada type definitions to IDL, I wasn't really concerned about the
subprograms.
I expected adopting CORBA to drive significant changes to the interfacing
implementation.

While it is true that the IDL-->Ada mapping is "trivially reversible", when
there's a lot of interface messages, the constituents of which need to be
traced back into their defining packages, it can get rather tedious, hence
is a good candidate for automation.  If tool could do most of the job, with
some final editing or cleanup of warnings, that'd be sufficent for me.

<Additional good commentary snipped>

> I hope that this explanation answers your questions.
> 
> Thanks,
> Brad
> 
> --
> Brad Balfour
> Director of Technology Services
> Objective Interface
> Brad.Balfour@ois.com    703/295-6533 (voice)   703/295-6501 (fax)

-- 
Marc A. Criley
Chief Software Architect
Lockheed Martin M&DS
marc.a.criley@lmco.com
Phone: (610) 354-7861
Fax  : (610) 354-7308




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1998-12-04  0:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-12-02  0:00 Ada -> IDL (this is not a typo!) Marc A. Criley
1998-12-03  0:00 ` Brad Balfour
1998-12-04  0:00   ` Marc A. Criley
1998-12-03  0:00 ` Alan Jenkins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox