[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dist-obj] Our Experience with Web services and Component Models

Hi all,

I work in an R&D team which build software for collaborative commerce on 
the Internet (some call it c-commerce). We have found this domain to 
benefits strongly from web services since it involves connecting 
different organizations with a minimum of effort, in order to allows 
them to quickly forge partnership and build collaborative strategies. We 
are already deploying web-service based infrastructure for our clients. 
Internally, we use object-oriented design & programming, and the team 
has strong background in distributed components model. So we decided to 
publish a paper, based on our experience, about component models in the 
context of web services and object oriented programming. The paper is at:

http://www.orchestranetworks.com/us/solutions/0105_whitepaper.cfm

Mainly, it describes how we see web services opening new opportunities 
in the world of e-commerce, and provide a critical discussion about the 
current component technologies.

One of the bottom line is that we are probably at a point where 
components need to evolves, and where their future needs to be defined. 
During years it was commonly stated that a component war would happen 
between COM/DCOM/COM+, CORBA Components and EJBs. Now this seems to be 
obsolete:

- Microsoft is saying bye bye to COM and DCOM, now that they have 
launched their nuclear weapon: the CLR & .NET. Sure, the COM run-time 
can still be called from the new model and will be included in Windows 
for years, but it will be more and more in maintenance mode, while the 
new developments will append (if all goes right!) in the .NET space. And 
I think it’s safe to bet that even the transactional model of COM+ will 
eventually be replaced by a native transaction monitor for the CLR.

- The EJB component model has been very deceiving from a technical point 
of view, and is trying to re-invent itself with the forthcoming 2.0 
specification, while being pushed down the throat of users by tons of 
marketing and hype.

- The CORBA component model is still not finalized after all these years 
and is in a bad shape: since the OMG deadline is approaching, it will be 
either canceled, or artificially finalized and published in a 
incomplete, immature form. I don’t foresee strong support for it in the 
industry. From a technical point of view (and just my opinion), it 
doesn’t look as a desirable future for the technology. Instead it 
appears to me more like a psychological experience aiming to test the 
limits of complexity the human brain can handle.

 From this, I’ve a question: how do we want, collectively, the future of 
component to be?

In my opinion, one of the big mistakes we (as the whole component 
industry) made was to produce *distributed* component models. This 
probably took its source in the illusion we had that we would eventually 
be able to offer the same programming model (including ease of use and 
power) on distributed objects than on local objects. Something like a 
“transparency myth”. It was probably an interesting way to explore but 
we gone to far and decided to provide a unified model. The goal was to 
be able to use distributed component as if they were locals. But since 
we still haven’t found a way to do this 8-) the result is at the exact 
opposites: all components, including locals ones, needs to be used as if 
they were distributed, with all the limitations and complexities 
incurred. If I want to use the various services of my component model 
that have nothing to do with distributed computing, I still need to 
adopt a sub-optimal programming model. Yes, it means that I can more 
easily move my components on different computers, but I believe the cost 
is too high for just this benefit.

It seems to me that what we need is a *local* component model (i.e. a 
powerful object model with hooks for transactions support, integrating a 
nice object persistence model and maybe a few other services). These 
locals components could interface with various distributed computing 
technologies (like RMI, SOAP, IIOP etc.) depending on the context. The 
programming model for distributed interaction would depends on the 
distributed technology used and could possibly includes support for 
distributed transaction, but would not impact the programming model for 
local interactions. This means that this model could offer much more 
ease of use and power (the forthcoming EJB 2.0 do a little (but too 
limited) step forward in this direction with its local interfaces). In 
addition it would be great, at the distributed layer, to progress toward 
dynamic distributed implementations with no more need to generate and 
deploy code for proxy & stubs.

Of course, this is something that can be crafted by hand for a large 
part today: for instance, program your objects using java, add an OODMS 
or a good O/R mapping tool (or a JDO implementation) with transactional 
support, add support for dynamic SOAP (take GLUE for instance) or other 
distributed model relevant to your application, deploy on a application 
server able to do load balancing etc...
But this is not a easy to figure for a user new to these technologies, 
and not the direction advocated by the big players...

Anyway, I hope to hear about your opinion on this and the paper.

Best,

Philippe Mougin
pmougin@acm.org

==========================================================================
To manage your subscription, mailto:dist-obj-help@distributedcoalition.org
Archives, FAQ, etc.     http://www.distributedcoalition.org/mailing_lists/