--- Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> Are you saying that you disagree that EJB defines a
> model for constructing and packaging components that
run in an EJB container? Or are you
> disagreeing the EJB is a component model?
Agree here.
> Every component model I've ever seen is
> platform-specific, and it defines a
> container-oriented packaging scheme.
Disagree. Component Object Model is not
platform-specific. COM is language nutral and can be
implemented in languages such as COBOL and C++. (So
you can implement COM using objects or not objects. If
not the component will loose object oriented
features.) It defines interface binary standard.
Container and controls must have certain agreement to
be able to cooperate. In fact, COM is a mini
architecture that can be designed in three different
ways: class nesting, interface implementation, and
multiple-inheritance.
EJB are components that are modeled for JAVA only.
JAVA is an object oriented language and has component
model in itself. Hence I agree that EJB is a platform
specific for its language dependence.
> Service orientation is platform-agnostic.
Yes. Like object model and component model, Service is
also a model and can be designed/implemented in
different ways.
>Although developers often implement service using
>components, it's by no means a requirement. You can
Since Service is an architecture, it can be designed
and implemented in many ways. This architecture has
three elements: Service descriptions, mapping, and
executable agent. Mapping translate messages into
native data. Relationship between service description
and excutable agent are many to many. Each elements
can be implemented in many different languages. I
agree that implementing service using components is
not a requirement. However, as I said, using the unity
(service) of the technology (service oriented) does
not qaulify the SW having the architecture (SOA) of
that technology (service oriented).
>implement services using EJBs and generate a JAX-WS
>interface around the beans. But I think it's
overkill.
Using components to implement services is not
overkill. Components are central to Service in the
same way objects are central to COM. By implementing
COM using objects, COM has object oriented features
inherited from objects plus new features unique to
COM. By implementing Services using components,
services have component oriented features plus new
features emerged. If we follow the intergration rules,
services we implemented have richer features that
include features of object oriented and component
oriented technologies
> When using Java, I recommend using POJOs.
> (Do you consider POJO to be a component model? If
> so, what's the difference
> between "object" and "component"?)
POJO is not a component model. It is simply object
oriented objects. But JAVA is byte standard, it can
be seen as a component with single interface which is
reduced into objects.
>But more to the point, you can also implement
services using Python or Perl or Ruby or whatever and
expose them using POX over HTTP. No component model
>involved there -- but it's certainly
service-oriented.
Yes, you can implement service that way. If you do
not use components, then you loose all powerful
features Components can offer. As such you have
services but may not have SOA.
Jerry
> Anne
>
> On 5/23/06, Jerry Zhu <[EMAIL PROTECTED]> wrote:
> >
> > --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> >
> > > Components are typically associated with a
> component
> > > model -- JavaBeans, EJBs, servlets, COM,
> ActiveX,
> > CORBA Component Model, etc. And now, most
> > > recently, Service Component Architecture (SCA).
> In
> > > all cases, these component models define
> > implementation-specific packaging schemes.
> > >
> > > Services are more abstract and
> > implementation-neutral.
> >
> > Anne, I disagree with you here.
> >
> > Objects, Components and Services belong to three
> > different kinds of technologies and all are
> models.
> > An object groups data and functions into an unity
> of
> > levels of access. A component groups objects into
> a
> > unity of interaces of access. A service groups
> > components into an unity of components. I see this
> > evolotion of technology as stages of integration
> into
> > greater capabilities. Each time of intergation
> the
> > unity increases its capability and solves
> different
> > types of problems. The implementation of all
> three
> > unities requires platforms. Platforms are
> languages.
> >
> > The use of unities of a technology in the SW does
> not
> > qaulify the SW having an architecture of that
> > technology. It must use the unities in certain
> way
> > such as object oritented SW must use inheritance.
> I
> > cannot see that SW without inheritance is object
> > oriented. I call this unity composing patterns.
> Each
> > technology has its composing patterns. Hence to
> judge
> > whether a SW is using Service technology is to see
> > that both services and service composing patterns
> are
> > used. Service unity is clear and the composing
> > pattern are to be defined.
> >
> > Jerry
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
