Recently in CORBA Category

IONA and Microsoft have a history. IONA has always recognized the value of Microsoft in the IT organizations of the worlds most successful corporations. Back when people were talking about COM Vs CORBA in the 90s, IONA recognized the opportunity to bridge both technologies. IONA understood that Microsoft dominated the desktop in large enterprises (OS/2 was still around but declining). IONA built COMet as a very successful COM/CORBA bridging technology. In my opinion that product helped both companies considerably. Today, as both companies roll out more SOA technologies and products, it is important for us to partner.

IONA continues to help bridge Microsoft based applicaitons and services with non-Microsoft based applications and services today with Artix and Artix Connect. IONA has been working to help integrate with Microsoft products such as Connected Services Framework (CSF) and Customer Care Framework (CCF) - see our Microsoft partner page for more details.

Of course there is also a lot of cooperative activity with Microsoft in the various WS-* standards bodies and working groups. And IONA has participated in interoperability events and plugfests to help ensure that our products interoperate. As new products from IONA and Microsoft come to market, IONA is making sure that we continue to interoperate and integrate with Microsoft.

Many of you know me as a Mac guy. Well I just got a new Dell to help me focus on some of my Microsoft activities. More on that later.

Is it because the so-called experts are wrong and the customers understand the problem better? Perhaps an academically sound approach just isn't needed in the real world and hubs will do just fine, thank you very much. (I believe there is a class of user this just can't scale too).

Is it because buyers are just plain uneducated or ignorant? I've come across many of these over the years. And I've come across system integrators that build out poor designs tha make distributed architectures look bad.

Is it because customers don't care? They're so burned out buying infrastructure that they've given up the fight? Let's face it they've gone through RPC, DCOM, CORBA, J2EE, .Net etc. and now they're faced with ESBs, JBI, SCA, WCF .....

Is it because hubs can make good sense for small to medium sized businesses and people can't differentiate between a small/medium sized problem and a big problem? The solutions must be different to scale and take care of issues such as transactions and other enterprise features. But, perhaps, it's just seems easier with a hub.

Is it because of perceived benefits of a hub like management? This is of course only a perception problem there are many technologies out there that allow for central management of a distributed architecture.

Hubs seem to have gravity and people get attracted to them. Unfortunately hubs can turn into black holes. Sucking in all that surrounds it into a dense mass from which nothing can escape.

Of course many customers are getting sick of hub based approaches and are not buying. They have enough infrastructure and plenty of hubs. Now they want to leverage that existing asset while a the same time taking advantage of SOA.

Look when you get down to it everything (in this service world) is just a string coming over the wire. Web services, REST, CORBA etc. are just arguing where the unwrapping of the string occurs.

Take CORBA for example. When you look down into it there is basically one operation called a Request that puts a big blob of data (a document?) on the wire. At some point the data gets unwrapped and examined and a dispatch to piece of coded logic (the business) occurs. So is CORBA RESTful?? Is the Request just really a PUT in disguise?? ;-)

Either you have one location and you put and the semantics of what your doing (the operation) in the document - e.g. orderItem. Or there is a different URL location for each operation. So either the document semantically tells you what you want to do (and you still need to dispatch to the right code) or else each location only performs one operation and you only send the data there. Actually the former sounds very like CORBA ironically. I.e the CORBA dispatcher sends the data to the right location of the business logic. ... But then so does the later. Wow CORBA is definitely not supposed to be RESTful but sounds like it. (I'm being factitious) The reason can you look at it both ways is that again at some point you need to dispatch a piece of data to a specific piece of code and at that point it becomes very "tightly coupled" no matter what the technology. Is a RESTful internet just a big ORB? Well I'm sure many of the REST folks would just say so.

I get back to my point. Everyone is getting bent out of shape about this and really it's just a matter of where the big string of data gets unwrapped and who wants to do the unwrapping. But when you do pick a particular technology to do your unwrapping then you take advantage of the capabilities of that technology. And in CORBA a runIT (in String blob) where there is a dozens of business functions hidden in the string, is definitely not taking advantage of the underlying infrastructure and a waste of money.

The big issue not whether a PUT or orderItem is better. That depends on the technology being used. If REST provides a great framework for maintaining, tracking, documenting etc. the real location and semantics of the operation then I think it's great. I can definitely see where REST makes a lot of sense. There is a LOT of waste and misunderstanding in other technologies. (There is a whole lot of complication in CORBA that I thought made it inaccessible to many developers and would drive anyone to a more RESTful state of mind).

Imagine if the anchor tag of a hyperlink didn't allow you to specify any source. Imagine if it had an implicit "GET" as the source. So on ay web page the only semantic you had was "GET" as the link to the underlying href. Hyperlinks would be rather boring and not very well documented. And that's my point the semantics need not only be there for the operation but also for understanding the way the business works. Where the semantics are depends on the technology used and how rich it lets you document those semantics.

I'm looking forward to understanding more about how that works in REST. Perhaps it's just brilliant. Remember I was the one advocating using RSS feeds as a service lookup repository instead of UDDI a few months back. Boy it doesn't take long to fall from grace.

Some advocate a much more granular interface operation. E.g. having a specific interface operation for every product in your store! But this is neither practical or useful.

void buyItem (ProductCode, Quantity);

is much more sensible than:

void buyCheese( Quantity ); // I've seen something similar suggested


Consider an on-line retailer. You can be sure that there is not a placeItemTypeInCart for every subcategory of ItemType - i.e. placeNovelBookInCart or placeGardenHoseInCart etc. It would be completely impractical writing code (even generating code), maintaining code and documenting such an interface. Every time a business partner brings more products to your "store" you need to write more code.

This is the problem with taking some of the OO type concepts into the SOA world. We saw this and the earlier everything-is-a-string type approaches in CORBA and other technologies. Successful CORBA based application implementations are more than likely SOA based. You cannot and should not, as much as possible, let your implementation influence your SOA design. Now sometimes it does because perhaps you're not starting from scratch and you are dealing with production code (aka legacy). Extra layers of abstraction might be required to make a legacy application more service oriented.