How is the CORBA IDL used to support communication between objects that have been implemented in different languages?
CORBA IDL lets you specify objects interface in programming language neutral way. Once that is accomplished for objects you would like to expose over the wire, CORBA specification details how is that interface exposed, and used in different languages like C++, Smalltalk, Java, etc.. This part of the specification is referred to as "language mappings".
So it is not that all of your python objects just appear as java objects on the other side. You need to describe behavior of object you would like to share with IDL, and than code them, and their usage according to the rules specified by the language mapping.
Related
The official site as well as some other sources describe one of the benefits of Google Protocol Buffers as being highly inter-operable. I know the technology supports different language bindings out of the box, and many more as third party implementations, but what does that mean exactly?
Is my understanding correct in thinking that as long as I have a common schema file, I can run the protoc compiler and generate code for multiple languages, and then write a program in one language using the generated code, serialize some data to a file, and then parse it in another language in another program?
For example, could my client-side application running in Java serialize a Google Protocol Buffer and send it over the wire to a server implemented in C++ which can then parse it and use it readily as long as both sides were generated from the same schema file?
If that is correct, what allows that to happen - is it that their serialization/parsing logic adhere to a common/consistent wire format detailed here?
Yes, you can, and yes, it is because the wire format is fixed (i.e. the same for any language binding).
I want to write an OCaml library which will be used by other programing languages like C or even python.
I not sure it's even feasible, and i guess i need to drop some type safety and add runtime checks to the interface for dynamically typed language.
Is it doable ? Is there tools to achieve this goal to auto-generate bindings ? I think stuffs like Corba do not fit well with ocaml ABI, but I may be wrong.
EDIT : by dropping the runtime requirement and using only languages having a llvm frontend, I could use llvm as a common ABI I guess, but it seems tricky.
OCaml has a FFI to interact with C code. The code for the binding has to be written in C, not in OCaml (which has no direct representation of C values, while C has representations of OCaml values). My advice would be:
On the C side, decide what would be the best interface to export that C programmers would like (or Python programmers writing Python bindings starting from your C interface)
Define a "low-level layer" on the OCaml side that gets your OCaml value as close as possible from the C representation
Write some C wrappers to convert from this low-level OCaml representation to your optimal C representation
The reason for step (2) is to have the step (3) as small as possible. Manipulating OCaml values from the C side is a bit painful, in particular you risk getting the interaction with the Garbage Collector wrong, which means segfaults -- plus you don't get any type safety. So the less work you have to do on the C side, the better.
There are some projects to do some of the wrapping work for you. CamlIDL for example, and I think Swig has some support for OCaml. I have never used those, though, so I can't comment.
If you know to which high-level language you wish to convert your interface to, there may be specialized bridge that don't need a C step. For example there are libraries to interact directly with Python representations (search for Pycaml, not sure how battle-tested their are) or with the Java runtime (the OCamlJava project). A C interface is still a safe bet that will allow other people to create bridges to their own languages.
It is feasible, but you need to understand involved topics, like how the GC works.
Have a look at this: http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc148
You need to be careful about types in the stub code, but otherwise you can keep type safety.
Wiithout wanting to create an open ended question....
F# is currently absent from the Windows 8 dev preview. There is a mapping layer in WinRT that wraps core objects into CLR objects for C# / VB or through other mappings for different languages.
Given that this model does not force languages through the CLR, my question as a functional programming novice is: Is this any benefit to F# (having a direct mapping to WinRT without the CLR layer could further reduce mutability, more native list types) or would it make sense to have a more purely functional language join the ecosystem and leave F# where it is (bearing in mind that interoperability is no longer restricted to CLR languages)
If anybody creates a pure functional mapping for WinRT, that would be quite interesting. However, there is no single right way of doing functional library for something (just like there is no single right way of doing object-oriented library).
The great thing about F# is that you can easily write your own functional wrapper over the underlying (imperative) API. For WinRT, this means that we can easily implement different functional approaches to WinRT programming, without having to write any COM-based mappings.
What is an example of a situation where CORBA would be used? Is it just a matter of using an interface language (e.g. Java) to 'talk' to all applications?
CORBA might be used to build a language-independent, O/S-independent distributed system. For example, C++ on Linux developers could build a common distributed system with Java on Windows developers. IDL describes the interfaces that bind the two implementations over a common substrate (CORBA).
CORBA is also useful when building a plain old distributed object system - it has a rich set of services defined and is generally very well thought out. However, these days - depending on the language - many folks have opted for either simpler (e.g., RMI, protocol buffers) or message-based protocols (e.g., HTTP) for building distributed systems, so it's not as common. CORBA suffered from design-by-committee (esp on things like security).
More info:
http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
You will see a list of real-life example of CORBA projects from below website.
http://www.cs.wustl.edu/~schmidt/TAO-users.html
TAO is one of the most popular C++ CORBA implementation available today. The project is pretty active.
CORBA technology vendors killed each other through incompatible and bureaucratic implementations. Today, you can safely consider CORBA to be a legacy technology; that is, use it if you have to deal with components that already expose themselves through COBA. Otherwise, stick to modern RPC/distribution standards like SOAP, or, better yet, REST/JSON.
Sorry. To answer your question: CORBA was intended to be what SOAP, REST, and others are today. Real-life examples of applications of the latter are examples of things attempted with the former.
What would be a valid reason(s) to use objects in functional programming languages? I see that f# is a functional programming language that lends heavily on the object side when dealing with the .net ecosystem of classes. But apart from this interaction with other assemblies/programs maybe written in c#, why would anyone choose to use objects for decomposition of a program in a function oriented language or style?
Does mixing up a style of program prove a help or a hindrance?
Functional and object oriented designs make different types of extensions easy. Given a discriminated union in a functional setting, it's easy to define any number of functions which work on that type, but it's hard to add additional cases to the type, since that would require going back to add the additional case to each function which pattern matches on the type. On the other hand, given a base type (or interface) an OO setting, it's easy to add new subtypes, but adding new operations to the base type is hard, since it potentially requires modifying existing subtypes to add an implementation of the new operation to each one.
Depending on the type of extensibility that's most relevant to the task at hand, either the functional or the object oriented approach may make more sense, so it's nice to have both options available. One popular approach is to use a functional approach "in the small" and an OO approach "in the large" (e.g. it's mentioned in this podcast with Luke Hoban).
Objects provide encapsulation that makes large-scale programming easier.
What would be a valid reason(s) to use objects in functional programming languages?
Objects are used in functional languages for a variety of reasons:
Large-scale structuring of programs.
Interoperability with existing OOP code (e.g. on the JVM or CLR).
Problems for which the ability to extend class hierarchies with more classes is a natural fit.
Does mixing up a style of program prove a help or a hindrance?
Can be a help but it would not be a good idea to do it without good reason.