You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2007/09/19 23:46:40 UTC
Architecture of cxf
Hello,
I have analyzed the structure of apache cxf with the achitecture tool
structure101.
The Architecture view below shows the layered architecture of cxf. Upper
layers may have dependencies on lower layers. Lower layers my not have
dependecies to upper layers. The arrows show cycles in the dependency graph.
Either I have not understood the architecture of cxf or the seems to be
a lot of cycles in the dependency graph. Especially service, interceptor
and endpoint seem to have cyclic references to other layers.
Are all these cycles necessary?
Best regards
Christian Schneider
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Architecture of cxf [aegis]
Posted by Christian Schneider <ch...@die-schneider.net>.
Benson Margulies schrieb:
>
>
> With Java5, Aegis is still quite handy when you want to talk a pojo and
> pass it around via a web service without adding references to JAXB
> annotation classes. What I'm missing is why anyone minds adding
> annotations to the service interface or implementation. Those things are
> specifically parts of the web service, so why not annotate?
>
In general I think you are right. People tend to turn from aegis to JAXB.
I do not generally object to annotations but they sometimes mix
responsibilities. Let´s take the example of a service described as a
java interface.
If you want to export the service using jaxb you have to add annotations
that are only neccessary for this type of export. If you then also want
to export the service
via rmi you still have the webservice annotations in it. So the rmi
client will depend on the annotation jars because he uses the interface
though he does not really need or want these annotations.
A particular bad case of this happened to me when I wrote an interface
between two applications that were talking through special database
tables. The contract of the interface said that a particular enumeration
instance had to include a space like "metric tons". A direct translation
to the enumeration was not possible as java would not allow spaces in an
enumeration instance. So I added a string representation directly in the
annotation like this MetricTons("metric tons"). This coupled the
representation inside the database to the java code. So when the
instance was printed in the application it also said "metric tons"
though I perhaps would wanted another representation there. Later I
facored out the string representation for the database into a map
outside the enumeration.
Drawing it together I think web service annotations make sense if the
only purpose of the objects is doing web services. So if you export your
inner business services through a special facade you won´t have many
problems with annotations. But if you want to transparently export your
inner business services without a separate java facade you will want
some abstraction and mapping outside the java interfaces and classes.
Best regards
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
RE: Architecture of cxf [aegis]
Posted by Benson Margulies <bi...@basistech.com>.
I've spent a certain amount of time inside Aegis of late. I have some
ideas about how perhaps it could be combed, but there's a bigger
question: why does anyone want to use Aegis for SEI / implementation
class properties, as opposed to beans and their properties?
I have the following hypothesis: back before Java5, setting up the
'jaxws' properties was a pain using the other available technologies. A
quick .aegis.xml file was a superior solution.
With Java5, Aegis is still quite handy when you want to talk a pojo and
pass it around via a web service without adding references to JAXB
annotation classes. What I'm missing is why anyone minds adding
annotations to the service interface or implementation. Those things are
specifically parts of the web service, so why not annotate?
Does anyone have any other facts about this?
Re: Architecture of cxf
Posted by Christian Schneider <ch...@die-schneider.net>.
I have looked into some more modules structure101 marked as having many
tangles.
cxf.aegis.type looks quite ugly:
cxf.ws.rm also has a big tangle:
cxf.ws.rm:
and cxf.jaxws:
--
Christian Schneider
---
http://www.liquid-reality.de
RE: Architecture of cxf
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi Dan,
Yes, the "2.1 migration guide" is very important.
Merging the utilities and rt-core modules with the api module makes
sense as they are all part of the api but there may be an argument for
keeping some separation between "must have" and "can have" api
functionality.
For example, to create and programmatically configure an endpoint you
"must have" cxf-api. To add your own interceptor that parses the payload
and needs access to the message schemas you "can have" cxf-dev-api that
will make your life easier.
dev-api can contain the common utilities and much of rt-core. Cxf-api
remains and possibly takes some packages from common-utilities.
Now the fact that the delineation is a bit loose maybe an argument for
just having one big api bundle but I think for first time users,
limiting the amount of api/capability that is exposed is liberating in
that it narrows the learning space. Cxf-dev-api on the other hand
emphasises the extensibility.
On api or impl, the issue comes into play from an OSGi perspective when
the interface/implementation is split across jars. Like the existing api
and rt modules.
The OSGi advice is: an exported package should not span bundles (think
jars). This allows substutability at the package level and ensures that
inter-package dependencies will work, that is, that there will be a
shared classloader for the entire package. It is possible to workaround
this using fragments and wrapper bundles but in order to have a one to
one mapping between existing CXF module jars and OSGi bundles, a package
naming split using something like .impl is required to ensure package
isolation.
This will all fall apart from in an OSGi deployment scenario however it
there are large (or small) implementation level dependencies (rather
than api interface dependencies) between modules. From an Architecture
perspective there should not be. The good news is that OSGi framework
will simply not allow this to happen at runtime.
I guess the idealised view is that the cxf module jars can be useable as
they are in an OSGi environment by simply adding some manifests and
simple activators. Making the .impl split between compile/runtime,
interface/implementation is a good start in this direction.
Working through the ramifications however will probably throw up areas
of the code that need some work to clear up their inter module
dependencies.
Gary.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 20 September 2007 23:03
> To: cxf-user@incubator.apache.org
> Cc: Tully, Gary; Christian Schneider
> Subject: Re: Architecture of cxf
>
>
> Gary,
>
> I've definitely thought about that. The issue now is
> compatibility.
> If people are subclassing
> org.apache.cxf.interceptor.BareInInterceptor,
> and we move it, they have to update code. I have no problem
> with that,
> we just need to start a section on the wiki for "2.1 migration guide"
> information so we make sure it's all tracked.
>
> First step is probably finding the packages that would be
> affected so we can examine them.
>
> The other issue that keeps popping up is whether
> cxf-common-utilities,
> cxf-api, and cxf-rt-core SHOULD be merged into one. IMO,
> common-utilities and cxf-api really should be merged together as they
> both really are the API's. I could also see much of core
> since a LOT
> of the rest of the stuff depends on stuff there. Thus, should they
> be "api" and not "impl" things? It's an interesting discussion.
>
>
> Dan
>
>
> On Thursday 20 September 2007, Tully, Gary wrote:
> > Hi Dan,
> > When looking at CXF from an OSGi bundle perspective the
> duplication of
> > packages between api and implementation limits the modularity. Both
> > interface and implementation are available to dependants by default.
> >
> > Would we consider adding an .impl to the implementation
> package names
> > in CXF.
> >
> > org.apache.cxf.interceptor.Inerceptor
> > org.apache.cxf.interceptor.impl.BareInInterceptor
> >
> > This would help Message.properties also.
> >
> > Best Regards,
> > Gary.
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: 20 September 2007 01:48
> > > To: cxf-user@incubator.apache.org
> > > Cc: Christian Schneider
> > > Subject: Re: Architecture of cxf
> > >
> > >
> > > We have a few places where package names exist in both the API jar
> > > as well as in the rt-* jars. This may be causing some
> issues with
> > > the analysis. They CERTAINLY have caused issues with the
> i18n stuff
> > > as grabbing the Message.properties seems to grab
> whichever is in the
> > > classpath first. Definitely something I'd like to see
> cleaned up.
> > >
> > > Dan
> > >
> > > On Wednesday 19 September 2007, Christian Schneider wrote:
> > > > I have done a second try at displaying the architecture.
> > >
> > > This time I
> > >
> > > > only included the cxf-rt* jars in the model.
> > > > This looks much better already ;-) Any idea why inlcuding the
> > > > other jars especially the api jar gave me so many cycles?
> > > >
> > > > This architecture view below shows only some cycles.
> > > >
> > > > Best regards
> > > >
> > > > Christian Schneider
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered Number:
> > 171387 Registered Address: The IONA Building, Shelbourne
> Road, Dublin
> > 4, Ireland
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Architecture of cxf
Posted by Daniel Kulp <dk...@apache.org>.
Gary,
I've definitely thought about that. The issue now is compatibility.
If people are subclassing org.apache.cxf.interceptor.BareInInterceptor,
and we move it, they have to update code. I have no problem with that,
we just need to start a section on the wiki for "2.1 migration guide"
information so we make sure it's all tracked.
First step is probably finding the packages that would be affected so we
can examine them.
The other issue that keeps popping up is whether cxf-common-utilities,
cxf-api, and cxf-rt-core SHOULD be merged into one. IMO,
common-utilities and cxf-api really should be merged together as they
both really are the API's. I could also see much of core since a LOT
of the rest of the stuff depends on stuff there. Thus, should they
be "api" and not "impl" things? It's an interesting discussion.
Dan
On Thursday 20 September 2007, Tully, Gary wrote:
> Hi Dan,
> When looking at CXF from an OSGi bundle perspective the duplication of
> packages between api and implementation limits the modularity. Both
> interface and implementation are available to dependants by default.
>
> Would we consider adding an .impl to the implementation package names
> in CXF.
>
> org.apache.cxf.interceptor.Inerceptor
> org.apache.cxf.interceptor.impl.BareInInterceptor
>
> This would help Message.properties also.
>
> Best Regards,
> Gary.
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: 20 September 2007 01:48
> > To: cxf-user@incubator.apache.org
> > Cc: Christian Schneider
> > Subject: Re: Architecture of cxf
> >
> >
> > We have a few places where package names exist in both the API jar
> > as well as in the rt-* jars. This may be causing some issues with
> > the analysis. They CERTAINLY have caused issues with the i18n
> > stuff as grabbing the Message.properties seems to grab
> > whichever is in the
> > classpath first. Definitely something I'd like to see cleaned up.
> >
> > Dan
> >
> > On Wednesday 19 September 2007, Christian Schneider wrote:
> > > I have done a second try at displaying the architecture.
> >
> > This time I
> >
> > > only included the cxf-rt* jars in the model.
> > > This looks much better already ;-) Any idea why inlcuding the
> > > other jars especially the api jar gave me so many cycles?
> > >
> > > This architecture view below shows only some cycles.
> > >
> > > Best regards
> > >
> > > Christian Schneider
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Architecture of cxf
Posted by Mansour Raad <mr...@esri.com>.
Cool - can you give me an insight of what OSGi implementation are you
using ? Tried felix and it worked pretty well - through you are
right - had to stand on my head when it came down to dependencies.
Tried following what Spring-OSGi is doing; by creating dependency jar
bundles that needed to be loaded first. A clean api/impl would be
very welcome :-)
On Sep 20, 2007, at 7:33 AM, Tully, Gary wrote:
> Hi Dan,
> When looking at CXF from an OSGi bundle perspective the duplication of
> packages between api and implementation limits the modularity. Both
> interface and implementation are available to dependants by default.
>
> Would we consider adding an .impl to the implementation package
> names in
> CXF.
>
> org.apache.cxf.interceptor.Inerceptor
> org.apache.cxf.interceptor.impl.BareInInterceptor
>
> This would help Message.properties also.
>
> Best Regards,
> Gary.
>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: 20 September 2007 01:48
>> To: cxf-user@incubator.apache.org
>> Cc: Christian Schneider
>> Subject: Re: Architecture of cxf
>>
>>
>> We have a few places where package names exist in both the API jar as
>> well as in the rt-* jars. This may be causing some issues with the
>> analysis. They CERTAINLY have caused issues with the i18n
>> stuff as grabbing the Message.properties seems to grab
>> whichever is in the
>> classpath first. Definitely something I'd like to see cleaned up.
>>
>> Dan
>>
>>
>> On Wednesday 19 September 2007, Christian Schneider wrote:
>>> I have done a second try at displaying the architecture.
>> This time I
>>> only included the cxf-rt* jars in the model.
>>> This looks much better already ;-) Any idea why inlcuding the other
>>> jars especially the api jar gave me so many cycles?
>>>
>>> This architecture view below shows only some cycles.
>>>
>>> Best regards
>>>
>>> Christian Schneider
>>
>>
>>
>> --
>> J. Daniel Kulp
>> Principal Engineer
>> IONA
>> P: 781-902-8727 C: 508-380-7194
>> daniel.kulp@iona.com
>> http://www.dankulp.com/blog
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
>
Mansour
:-)
RE: Architecture of cxf
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi Dan,
When looking at CXF from an OSGi bundle perspective the duplication of
packages between api and implementation limits the modularity. Both
interface and implementation are available to dependants by default.
Would we consider adding an .impl to the implementation package names in
CXF.
org.apache.cxf.interceptor.Inerceptor
org.apache.cxf.interceptor.impl.BareInInterceptor
This would help Message.properties also.
Best Regards,
Gary.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 20 September 2007 01:48
> To: cxf-user@incubator.apache.org
> Cc: Christian Schneider
> Subject: Re: Architecture of cxf
>
>
> We have a few places where package names exist in both the API jar as
> well as in the rt-* jars. This may be causing some issues with the
> analysis. They CERTAINLY have caused issues with the i18n
> stuff as grabbing the Message.properties seems to grab
> whichever is in the
> classpath first. Definitely something I'd like to see cleaned up.
>
> Dan
>
>
> On Wednesday 19 September 2007, Christian Schneider wrote:
> > I have done a second try at displaying the architecture.
> This time I
> > only included the cxf-rt* jars in the model.
> > This looks much better already ;-) Any idea why inlcuding the other
> > jars especially the api jar gave me so many cycles?
> >
> > This architecture view below shows only some cycles.
> >
> > Best regards
> >
> > Christian Schneider
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Architecture of cxf
Posted by Daniel Kulp <dk...@apache.org>.
We have a few places where package names exist in both the API jar as
well as in the rt-* jars. This may be causing some issues with the
analysis. They CERTAINLY have caused issues with the i18n stuff as
grabbing the Message.properties seems to grab whichever is in the
classpath first. Definitely something I'd like to see cleaned up.
Dan
On Wednesday 19 September 2007, Christian Schneider wrote:
> I have done a second try at displaying the architecture. This time I
> only included the cxf-rt* jars in the model.
> This looks much better already ;-) Any idea why inlcuding the other
> jars especially the api jar gave me so many cycles?
>
> This architecture view below shows only some cycles.
>
> Best regards
>
> Christian Schneider
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Architecture of cxf
Posted by Christian Schneider <ch...@die-schneider.net>.
I have just tried to only use the cxf-api. The architecture is the same
as when I used the cxf-rt* libraries.
CXF architecture using only the cxf-api jar:
BTW. I just analysed xfire too and compared to xfire cxf seems to have
improved greatly in design.
Best regards
Christian
XFire Architecture using only xfire-core jar:
Guillaume Nodet schrieb:
> Have you tried with cxf-api only ?
> Tr
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Architecture of cxf
Posted by Guillaume Nodet <gn...@gmail.com>.
Have you tried with cxf-api only ?
Tr
On 9/19/07, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I have done a second try at displaying the architecture. This time I only
> included the cxf-rt* jars in the model.
> This looks much better already ;-) Any idea why inlcuding the other jars
> especially the api jar gave me so many cycles?
>
> This architecture view below shows only some cycles.
>
> Best regards
>
> Christian Schneider
>
>
>
> --
>
> Christian Schneider
> ---http://www.liquid-reality.de
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Architecture of cxf
Posted by Christian Schneider <ch...@die-schneider.net>.
I have done a second try at displaying the architecture. This time I
only included the cxf-rt* jars in the model.
This looks much better already ;-) Any idea why inlcuding the other jars
especially the api jar gave me so many cycles?
This architecture view below shows only some cycles.
Best regards
Christian Schneider
--
Christian Schneider
---
http://www.liquid-reality.de