SOA is great but it’s a lofty concept. I’m looking forward to the day when SOA becomes SOI, Services Oriented Implementation. I imagine an application server where I can run Java, C++, maybe Perl or other popular languages. All managed under one engine. The engine would adhere to specifications driven by the world’s foremost experts. I need to protect my investment, of course.

Today’s application servers are good role models. They provide basic functionality for: thread and database connection pooling, application deployment, clustering, web based management, and more. It’s been tremendously handy keeping all these details out of our code. Remember the day when we had to code all the details as well – ouch. Moving applications from one application server to another is relatively easily. Granted, not without a little pain and frustration, as us salty dogs know.

Up to this point our visionary SOI server can run Java, C++, and Perl applications. All managed from a single application server. Wow, a Herculean dream, but it’s not over yet. We are still missing: diagnostics, security model, integration framework, property management, auditing, license management, analytics & instrumentation, persistence, and much more.

Sadly, today there are no SOI servers. Businesses are solving their own problems using a mix of existing technologies and custom code. Effectively is analogous to each business writing their own application server for servlets; we would all agree this is craziness. We all need the same features but attack the problem differently. Of course, anyone can argue each company has different needs. How could implementations account for this? Well, the industry did it with servlets! The key is to separate the service component(e.g, property management) framework from the implementation. In the case of property management imagine a Window’s program being able to leverage a Java property or the other way around. Most of us could build such a system but it would be a one off solution. And solutions not build upon standards are not information assets that can be transferred easily.

Think about the problems this can solve! I believe with the right talent, seeding and buy-in from vendors, we could get there. There is already work on a number of fronts, both technology and specification:
Diagnostics – log4j, JMX, and SNMP
Security model – Liberty Alliance, SAML
Auditing – log4j, Sarbans-Oxley
Property Management – JNDI, Preferences, JDO, ORM, etc.
License Management – only vendor technologies. Little in the way of adopted standards or open implementations.
Persistence – RDBM, JDO, ORM, the list goes on
Integration – MOM, ESB, SOAP and Web Services

Is this a reasonable dream? Can all this be stuck under the hood of one car? Is the enterprise destine to be a permanent mix of technology and competing standards? Before you answer, think about how many dollars are spent when one company acquires another and both must integrate. Or a service provider paradigm, where one vendor must integrate with another to provide a service. Multiple this times the number of occurrences in the country. The cost is huge! Is anyone perusing such challenges or interested in doing so?

Milton Smith
brahma_bull_sj@yahoo.com

actually we cannot really define soa to know if soi is better or not
any thing these days called SOA or support soa or facilitate soa but really there is no definition for soa so i cannot claim that ur words are correct as i donot know either

.net. And that wouldn’t be a bad thing if we could swap out pieces of the .net application server with better implementations the way we can with j2ee containers.

.net

Did you notice that any decent OS can run applications written in vastly different languages?

.net is a next attempt by MS to build a decent OS. If there is a decent OS in place then there is no need for .net

Did you notice that any decent OS can run applications written in vastly different languages?.net is a next attempt by MS to build a decent OS. If there is a decent OS in place then there is no need for .net

not really. The OS is much lower on the technology stack than the application server and they serve different purposes. .net is not an operating system and there will always be a need for application servers that manage the details of communicating with the low level operating system calls as well as managing threads, resources, and other goodies that application servers do.

...as well as managing threads, resources, and other goodies...

AFAIK, this is exactly what operational systems do for a living, besides lower level stuff. :)

Did you notice that any decent OS can run applications written in vastly different languages?.net is a next attempt by MS to build a decent OS. If there is a decent OS in place then there is no need for .net

not really. The OS is much lower on the technology stack than the application server and they serve different purposes. .net is not an operating system and there will always be a need for application servers that manage the details of communicating with the low level operating system calls as well as managing threads, resources, and other goodies that application servers do.

Where exactly do you draw the line between the OS and the application server? I think this separation only makes sense when you consider the objective of OS platform independence. Of course .NET is not an operating system in itself, but it is the next version of the Windows API.

Actually, you have to give Microsoft credit for not jumping on the application server terminology, which they could have done for purely marketing reasons (when it was in vogue), ignoring the utter meaninglessness of such a definition for a single platform environment.

I am of the opinion instead of architecting applications as services, one should think about exposing integration points as services.

Using services (specially remote) for everything may not make sense. That's one of the reason why people don't like EJBs.

So I propose the term: "Service Oriented Integration"

Author definitely needs to familiarize himself with CORBA architecture and implementations.

Sybase's EAServer already supports Java/J2EE, as well as C++ and even PowerBuilder components via CORBA.

http://www.sybase.com/developmentintegration

The page for EAServer seems to be broken at the moment, though!

Surely the author is not atttempting to create a new buzzword here?

Doesn't he realise that he will very quickly find himself wrapped up in a brutal demarcation dispute with Gartner if his tries to do this?

Firstly, as nice as SOI would be to have for future projects (and I do believe we are moving this way - take a look at any of the major vendor application server solutions: Oracle, IBM, BEA, Sybase), the real issue is not where the code runs, but how we are going to get everything to interoperate. SOA is the answer to current needs whereby current IT architectures/infrastructures (and even ones in the near future - next 5 years) include legacy applications, which would be prohibitively expensive to move, and new applications which need specific resources usually only available n*tier models. Hence, SOA solves the problem of stove-pipe implementations by allowing ALL applications (legacy and otherwise) to interoperate via channels such as BPEL. Although SOI would be nice, as long as we go to different vendors for enterprise and departmental applications, we will probably ALWAYS need an integration/middle layer or API that will allow all of the applications to interoperate. As the transactions happening are ordinarily too complex to just be able to simply call APIs in rapid succession, that integration/middle layer must also expose some rules or a workflow interface. For instance, lets say you have two pure J2EE applications deployed to the same J2EE application server, one homegrown and one COTS; and both applications have clearly defined Java APIs. Now you want to integrate the two applications such that when a transaction completes in application #1 it fires off another transaction in application #2 - it would be easy enough to just link the two together, but what about all of the rules that happen inbetween (what if the first transaction needs to be rolled back after it has fired the second? What about error handling between the two?): It's the complexities between systems is what spurred the "invention" of SOA (using technologies such as BPEL). Integrateable APIs, architectures and applications have been around for a long time, but until now, we have lacked the standards to handle the complexities inherent in enterprise systems.

I imagine an application server where I can run Java, C++, maybe Perl or other popular languages. All managed under one engine. The engine would adhere to specifications driven by the world's foremost experts.

You kinda get at what the Global Grid Forum planned. But GGF posed a distributed architecture, not a monolithic one. So with GGF's OGSA interoperability specification for SOA, there now exist containers for Java/Axis, C++/gSOAP, Perl, and Python. Despite the heterogeneity, they federate easily. But they never share a memory space, so it's like Jini, but for heterogeniety and without a tuple space. An XML tuple space service can be easily added as an afterthought.

The idea that there should be one container or engine to house the diversity suffers from some gross problems. Implementation languages should never appear in a specification, except as a prescribed binding, like W3's DOM binding for Java. The specification authors shouldn't be constrained by least-common-denominator language constraints (times four or so very crappy languages). C++ is inherently unsafe, and it's unfair to subject Java classes to potential corruption.

OGSA did it right. They specified WSDL and abstract semantics for SOA federation, and the vendors can decide in an ad hoc way which languages deserves support.

Notice the spiritual divergence of corporate and academic grids. The academic grids have no hubs, no central brokers -- mostly just peers happily cross-referencing eachother in their distributed registries. Whereas the corporations want a monolithic broker that this SOI thread implies.

C++ is inherently unsafe

In what way is C++ inherently unsafe????????????????

In what way is C++ inherently unsafe????????????????

It gave me carpal tunnel syndrome ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

In what way is C++ inherently unsafe????????????????

It gave me carpal tunnel syndrome ;-)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

I thought carpal tunnel syndrome was suppose to be a myth like the Lockness monster and bigfoot. On a less silly note, someone needs to invent a direct interface so programmers can just plugin like Neo 8-)

peter

In what way is C++ inherently unsafe????????????????

It gave me carpal tunnel syndrome ;-)Peace,Cameron Purdy

I thought it was minesweeper :))

In what way is C++ inherently unsafe????????????????

It gave me carpal tunnel syndrome ;-)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

I believe that would be due to lack of safe typing.

And what does safe typing mean ? In this context I can only assume it means that typing C++ code is unsafe as it may give you carpal tunnel, because there's no other reasonable interpretation of what you said.

In what way is C++ inherently unsafe?

Buffer overrun, which is perhaps a conduit for Internet worms. C++ is object oriented assembly language, easily trampling on pages. It's structured peeks and pokes. Occasionally GDB is little help at diagnosing the root cause of a memory corruption. For the unfortunate C++ programmer, achieving memory sanity might need a tool such as ValGrind or Purify. It hurts to recite this, knowing that many C++ programmers won't bother with a memory analyzer. But to a Java programmer, it's just another ArrayIndexOutOfBoundsException, reported line precise.

I once watched someone use a C++ interpretor on a grid. I suppose interpreted C++ could be as safe as Java.

Object Pascal compiler generate code in "debug mode" to make array access safe, probably modern C++ compilers can generate this stuff too.

Object Pascal compiler generate code in "debug mode" to make array access safe, probably modern C++ compilers can generate this stuff too.

I suspect that they can, but it would be very, very tricky. Pascal arrays aren't pointers. They are clearly delimited structures and the compiler knows their size, so can compile in range checks if required. C++ arrays are nothing more than pointers, and it is perfectly acceptable in C/C++ to read and write beyond the memory allocated in the declaration of the array. (I may be wrong, as my C++ skills are a bit rusty)

Sorry for meaningless title - I'm using a buggy browser...

C++ arrays are nothing more than pointers, and it is perfectly acceptable in C/C++ to read and write beyond the memory allocated in the declaration of the array. (I may be wrong, as my C++ skills are a bit rusty)

A C++ pointer can be used to accidentally trample data pages. C++ and its pointers are unsafe. Hence my reliance on a memory analyzer when testing compiled C++. Would you release a C++ product without ever having Purifyed it?

Buffer overruns isn't something inherent in the language.

You can do all sorts of nasty things in Java (delete files, gobble up resources, etc) but that doesn't make the language inherently unsafe.

I've worked on many C++ apps and memory management problems were way down the list in terms of quantity and difficulty in finding/fixing.

Sorry to nitpick semantics...I haven't had my normal caffeine allotment.

Sorry - my turn to nitpick!

Buffer overruns isn't something inherent in the language

I would argue that it certainly is:

int x[100]; x[199] = 1;

is perfectly acceptable C++. The ability to do potentially dangerous things with pointers makes C/C++ such a useful system language.

I've worked on many C++ apps and memory management problems were way down the list in terms of quantity and difficulty in finding/fixing.

I remember the bad old days of C++ coding on DOS. Memory management problems were frequent, and were often indicated by the PC locking up or strange random graphics on the screen. I suspect that was possibly an indication of poor coding skills, but we all make mistakes and I prefer, for general development, a language that is more forgiving, even if things are far safer under modern OSes.

new File("/boot/vmlinuz").delete();

public void recurse() { recurse(); }

These are perfectly acceptable Java codes, but I wouldn't say that Java is inherently unsafe because of that.

The JVM is implemented in C/C++ anyway, so if C is unsafe, so is Java.

A JVM doesn't necessarily need to be implemented in C/C++.

new File("/boot/vmlinuz").delete();public void recurse() { recurse(); }These are perfectly acceptable Java codes, but I wouldn't say that Java is inherently unsafe because of that.

Such actions could be blocked by a SecurityManager in Java.

The JVM is implemented in C/C++ anyway, so if C is unsafe, so is Java.

This is often stated, but is mistaken, as it confuses Java the language with the quality of implementations of the language. The JVM does not have to be written in C. I have known of some written in Smalltalk - a highly safe language. However, this is irrelevant.

void recurse() { recurse(); }

That's harmless. It crashes an HttpRequest thread, but the servlet and its container survive.

// This crashes the JRE...
void crash () {
 for (Set trash=new HashSet();; trash.add(new long[Integer.MAX_INT]));
}

Anyway, maybe we're missing what safety means to a developer. Safety might not mean that software never crashes. Maybe immediate error reporting is the key to safety. So if a servlet request exhausts the heap, the container may die, but the developer will see a stack trace indicating a likely cultprit. To the developer that's safe. It immediately flags a problem and he can fix it.

But if a C++ developer mistakenly deletes the same pointer twice, it may be thousands or billions of instructions later that the program shows symptoms. When the program eventually dumps core, it might be impossible to tell when and where the original bug struck. GDB can't alert a double delete, and that makes C++ unsafe. Only a memory analyzer can diagnose a C++ program that abuses pointers. Accidental pointer abuse is hard to avoid with industrial C++, hence demand for tools like Purify and ValGrind to restore sanity.

and that makes C++ unsafe.

What you say is certainly true. My only quibble was the statement that C++ is inherently unsafe.

There are levels of unsafeness, though. A core dump in a certain instance (particularly on new operating systems) could create less of a problem than a program inadvertently deleting a row from a database. The latter can be done using the "most safe" languages/platforms.

My only quibble was the statement that C++ is inherently unsafe.

I'm going to continue to argue that it is, and that is one of its strengths - it is why it so powerful as a systems language. C (the successor to B) was designed as a direct replacement for assembler. One of the design principles was that you could look at a C program and figure out what assembler instructions would result. This left no space for the addition of features such as bounds checking. If you don't think C/C++ is inherently unsafe, then you must also deny that assembler is inherently unsafe. I think that would be a difficult argument to make.

I argue that things that are inherently unsafe are things that in there typical use or in there nornmal state create hazards. Rattlesnakes are inherently unsafe. Radioactive waste is inherently unsafe. C/C++ and even assembly language is not inherently unsafe. You can do some very unsafe things but that's a different story.

I argue that things that are inherently unsafe are things that in there typical use or in there nornmal state create hazards. Rattlesnakes are inherently unsafe. Radioactive waste is inherently unsafe. C/C++ and even assembly language is not inherently unsafe.

I don't think that's what safety means to a developer or manager. To these folks, a language's safety is how quickly the important bugs get fixed. Unsafe is a synonum for schedule risk. Eg, GDB doesn't alert the use of an already-deleted buffer. Core might not dump until millions of instructions later. Without a memory analyzer like freeware ValGrind, root cause analysis might take a day. How many thousands of statements use pointers in a modest C++ program? Pointer diagnosis is a schedule risk for C++ but not Java. So C++ is inherently less safe than Java.

I would argue that it certainly is:int x[100]; x[199] = 1;is perfectly acceptable C++. The ability to do potentially dangerous things with pointers makes C/C++ such a useful system language.

In C++ you can always come out with Array<int, 100> having bounds checked, in accordance with the "pay as you go" philosophy.

I would argue that it certainly is:int x[100]; x[199] = 1;is perfectly acceptable C++. The ability to do potentially dangerous things with pointers makes C/C++ such a useful system language.

In C++ you can always come out with Array<int, 100> having bounds checked, in accordance with the "pay as you go" philosophy.

True, you certainly can write safe code. However, if you can't write the code I showed, it's not a valid C++ implementation, so my point stands.

Saying C++ is inherently unsafe is like saying guns are inherently unsafe. You can do some unsafe things with them (as you can to a lesser degree with Java) but the language itself is benign.

Saying C++ is inherently unsafe is like saying guns are inherently unsafe. You can do some unsafe things with them (as you can to a lesser degree with Java) but the language itself is benign.

True, saying C++ is unsafe is like saying guns are unsafe. I totally agree.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Saying C++ is inherently unsafe is like saying guns are inherently unsafe. You can do some unsafe things with them (as you can to a lesser degree with Java) but the language itself is benign.

That's a decent analogy, but I'd argue that guns without safeties less safe than guns with safeties. So what's a programming equivalent of a safety? Checked exceptions and automatic memory allocation/deallocation perhaps.

I'd also argue that pistols are safer than anti-aircraft weapons because they're less powerful. Java, in my opinion, sacrifices some power like pointers to specific memory locations and multiple inheritance for the sake of safety/simplicity.

Sure, programming languages, like guns, are benign, but we do use them, and if our gun is unsafe, we're more likely to shoot ourselves in the foot.

Call it SOX... no matter which acronym we consider here, the bottom line is that people want interoperability, integration and reuse among all components regardless of the language they were written in or the platform they were written for. There's not much that is really new here: CORBA was an early - and excellent - attempt at solving this; When application servers first came out (if you remember) they positioned themselves as "Web Operating Systems" - which still is IMHO the best way to think of them; We are clearly moving in the direction of "high-level" distributed operating systems (and have been for a while). Personally - I beleive that a far more important development can be found with OMG's MDA (Model Driven Architecture - another 3-letter acronym...). OMG knows something about interoperability and good design.
An excellent article (by none other than Grady Booch) on the vision and value of MDA can be found at: http://www.sdmagazine.com/documents/s=9224/sdm0408a/sdm0408a.html - enjoy!

Gad Barnea
GigaSpaces, Inc.
www.gigaspaces.com
stormscope.blogspot.com

ORACLE’s Designer was probably first MDA attempt on much smaller scope (ORACLE Model for ORACLE Forms on ORACLE DB) and it is not very successful IMO.

Scope of MDA is broader and therefore chances to succeed are even smaller.

Just 2 c

One way would be to implement your own J2EE JCA adapter executing non-Java code, like C/C++.

 Another intersting approach would be to implement byte code compilers for these languages and then compile into one byte code language, similar to .net

A third way would be to have cross language aspects, so I would define (say) a Java interface, but have aspects implemented in other languages.


Per Bergman
Versant Corp

Hi ServerSiders,

What you finally ask for is just interoperability don't you ? With some "interoperable" services for transacs, security, etc. ? And ability to make abstraction of the implementation, "contract-based" programming... All this standardized by an independant consortium, so that it's reliable...

Look at CORBA in general, and more precisely at the CORBA Component Model, you should like it... It's all about, in a few words, developing objects and even "EJB"s (even far more powerful, with facets, receptacles...) than can be implemented in almost any language, and run under any virtually OS/Platform !

Last but not least : it's available ! Many CORBA implementations are even for free with source code !!!
And guess what ?
IT ALREADY WORKS (I've even seen OpenCCM running on a wi-fi PDA !) :-)

Its only problem is it's not XML-based apparently !

Have fun,

Remi - CORBActivist

The author might want to look at CORBA and the CORBA based application servers like Sybase's EAServer. EAS is J2EE compliant and branded, supports C++, EJB, POJO, COM, and PowerBuilder. You can for instance install a C++ component, generate EJB stubs for it, and call your C++ right from your EJB or vice versa. Install a POJO and call it from C++, or COM or an EJB. EAS supports exposing these all as web services, JMS, distributed transactions, blah blah blah.

What's new here? This looks like a case of being so blinded by the high beams he forgot to chase the tail lights.

Dave Wolf
Cynergy Systems

Install a POJO and call it from C++, or COM or an EJB. EAS supports exposing these all as web services, JMS, distributed transactions, blah blah blah. What's new here?

Java clearly has conquered SOA, mostly with tooling. CORBA 3 and DCOM seem stale. Java emerged as the dominant SOA container. Annotations and aspects will disturb it some, but otherwise service containment is mature. Aggregating the containers, especially heterogeneously, is the real frontier. That's utility computing.

Lord god, in your heavenly wisdom, grant us deliverance from these bullshit acronyms.

--b

amen, brother.

It sounds nice. But SOA is something to integrate existing disparate applications. SOI concept will click if the vendors have the potential to build servers on that line.

Hence I feel SOA is most practical solution in coming years.

Tans

Sigh, the buzzword (SOA) has been accepted by the community so let's introduce a new one (SOI) so we can call ourselves specialists again. (We know the buzzwords the managers don't, that's why we consultants get paid so much)

But my first idea on that SOI idea: it's close to true evil, let's just rename SOI to Damien right away.

Different languages have different uses and different models (among other things: memory management, security, etc.).
You would place everything in one generic piece of software that handles everything? Wow, pretty suicidal. :-) There is no way that any group of people on the planet can define a container that allow for *clean* execution and interoperability of all forementioned languages in 1 container without changes to the languages.
One of the problems is that once such a spec would be done it's redundant because all those languages are legacy and the next best thing is out.

There are alot of other ways to create interoperability;
- CORBA
- SOAP
- For C(++) / Java interoperability you could also go for a BEA Tuxedo / Weblogic solution.
- Probably some other solutions as well that I don't know or just plain forgot.


And also keep in mind that mst of the software that is written now has either a life-span of about 5 years or is legacy the moment you finnish it.
I'd have to agree with a (techy) sales-guy i know: Java is the new Cobol.
And there's nothing wrong with that.
It means Java will be around for a loooong time (cobol-java migration projects anyone? ;-) )


Just my .5 ct, back to you Ted

Barre

You have some very good comments and I appreciate them.

I am aware of technologies such as CORBA, SOAP, and MOM for integration. However, what you end up with is a mish-mash of techno foo-faddle in the enterprise. Said in another way, there is too much technology in today’s enterprise. It’s difficult to manage, deploy, and extend upon. Additionally, these solutions require a broad range of skill sets and expertise based upon hard-won experience.

I agree these tools and technologies are flexible, and that’s precisely the problem. These technologies leave too much up to the discretion of the designers. While most businesses are skilled in their problem domains, building enterprise frameworks joining heterogeneous product lines is usually outside the expertise of many businesses. Unfortunately, businesses don’t have a choice, customers demand homogeneous: security models, administration interfaces, and synergy among a companies product lines. Businesses find themselves forced to dabble in the platform arena. As a result, the scope and quality of these platforms vary greatly between companies.

Another thing that complicates one-off add-hoc platforms is that they don’t preserve corporate investment. For example, company A has a suite of products. It has spent millions developing a framework that finally supports integration of its product suite. Company B purchases company A. Company B has its own integration platform. Now what? Company A may be charged with migrating its applications or platform to company B’s platform. This is required if Company B is to present a homogeneous product line of both companies products. What’s the value to the customer? Little, unless they purchase enough of the products to notice the integration advantages. What’s the cost – huge! What’s the chance for success – it depends.

As for the ability to bring such a platform to reality; while challenging, it’s entirely within the realm of possibly. At my company we did build such a platform supporting both C++ and Java components leveraging CORBA. It works well for us. I am not suggesting this will meet the needs of everyone. A generalized platform such as I describe in the article would be difficult to design. Also it would be less flexible than existing technologies. On the other hand, it would be much lower-cost entry in the platform area for the masses.

I am not saying such tools and technologies are not necessary. As you say, we are tasked with bringing the old as well as the new together. But for many, such technology could be a godsend and a good starting point.

Milton Smith
brahma_bull_sj@yahoo.com

these solutions require a broad range of skill sets and expertise based upon hard-won experience.

At least I agree on that point... and IMHO that's precisely *why* we get paid so much as Barre said in this thread ! Not because of the buzzword that's invented every year...

building enterprise frameworks joining heterogeneous product lines is usually outside the expertise of many businesses.

That's called "software integration". This is a job in itself. The goal is precisely is to put everything together, not to get into all details.
In a few words, it's design all day :-)

Look at financial places for example. They all have their own ways to do things, but they need to be interconnected. That's where integrators come into scene. But they don't really know what finance is about...

These are complementary roles (functionnal, business logic / technical, integration). It always have worked like that AFAIK...

Businesses find themselves forced to dabble in the platform arena.

That's life... Fortunately, everyone has something to bring to the other :-)

A generalized platform such as I describe in the article would be difficult to design.

OMG started that work years ago. I still can't understand why OMA hasn't penetrated the market more than it has.
All the problems you raise (that are a sad reality to many companies, I fully agree there), are solved by the OMG's approach. MDA's even a better example...
There's enough to build interoperability, or at least to cover 99% of the points you raise. Why spending so much time trying to reinvent something that's already under deep investigation (in an open and "democratic" way) since several years ?

Have fun,

Remi

Sigh, the buzzword (SOA) has been accepted by the community

Really ? I personnally still can't get used to it...
:-)

so let's introduce a new one (SOI) so we can call ourselves specialists again.

LOL

(We know the buzzwords the managers don't, that's why we consultants get paid so much)

Well, once again there's many categories of consulting. My partners and clients don't expect buzzword but the best software at the lowest price...
All this blah-blah is something they can't afford.

define a container that allow for *clean* execution and interoperability of all forementioned languages in 1 container without changes to the languages.

And there's no real point in doing that. What is precisely good in the variety of languages we have is that they all allow different things...
What's useful is being able to make them interoperate.
CCM is precisely about this (for business components only of course, each component model is supposed to solve a particular "family" of problems) : describe components in a "meta" way so that each language can implement them and/or connect to them...

There are alot of other ways to create interoperability;- CORBA- SOAP- For C(++) / Java interoperability you could also go for a BEA Tuxedo / Weblogic solution.- Probably some other solutions as well that I don't know or just plain forgot.

Of course... But then connecting to a remote socket and passing legacy data can also be considered as interoperability in some way !
To me, interop is there only if the "solution" can map high-level semantics and concepts that make the power of the languages we use now (at least objects, even better components).
Sending a text file over the wire is far from real interoperability IMHO !

And also keep in mind that mst of the software that is written now has either a life-span of about 5 years or is legacy the moment you finnish it.I'd have to agree with a (techy) sales-guy i know: Java is the new Cobol.And there's nothing wrong with that.It means Java will be around for a loooong time (cobol-java migration projects anyone? ;-) )

That's probably the best example you could take. This is precisely through such projects (legacy systems wrapping) that CORBA also "survived" all these years (it hasn't been seen very good by the managers compared to SOAP... maybe because you're always afraid of what you don't know or understand) !
Re-writing thousands lines of COBOL is something lots of companies could not afford. They simply wrapped their stuff in CORBA objects, and got low-cost XXX years extra...

Buzzword on one side, efficient software engineering on the other.
Software engineering is a young market and is still doing well, so bullshit still pays and vaporware sells OK.
But guess who will stay when it will be a "regular" business, in a few years (you know, businesses - actually almost all - where you can't think your client is a fool or you don't have one) ?

Have fun,

Remi - quality always pays