[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dist-obj] Our Experience with Web services and Component Models
- To: email@example.com
- Subject: [dist-obj] Our Experience with Web services and Component Models
- From: Philippe Mougin <firstname.lastname@example.org>
- Date: Wed, 15 Aug 2001 16:51:49 +0200
- Delivered-To: email@example.com
- Delivered-To: mailing list firstname.lastname@example.org
- Mailing-List: contact email@example.com; run by ezmlm
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:
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
- 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.
To manage your subscription, mailto:firstname.lastname@example.org
Archives, FAQ, etc. http://www.distributedcoalition.org/mailing_lists/