On Aug 23, 2006, at 5:00 AM, Hawkins, Joel wrote:
Hi Andy,
I'm pretty new to it, too, hence the questions. :-)
For me, SCA seems like wiring technology that's very useful for things
with a bit of an impedance mismatch, whereas Spring is more focused on
IOC. Spring is very good at wiring things together that are meant
to be
wired, and functionality like the OSGi binding for Spring is a
means of
bringing more wiring targets into the fold. I guess my question is,
could SCA be the standard way for Spring and EJB3 to deal with these
impedance mismatches, so that all Spring would need to implement is an
SCA bean type, and all SCA would need to implement is an OSGi binding?
Then anything bind-able by SCA could be consumed by Spring - BPEL
components, Javascript, whatever.
I view things similarly as well I generally characterize Java SCA
Tuscany as "wiring infrastructure" which involves connecting services
both remotely and locally. Tuscany handles remote or "coarse grained"
connections through bindings which may involve delegation to some
transport. Tuscany handles local wiring (i.e. from source to target
in a shared memory space) either directly through a proxying strategy
or through delegation to a container extension (e.g. Spring). While
Java SCA Tuscany may use web services technology for interop, it is
just one option among many and it does not mandate them.
Tuscany supports (or should support since it is a work in progress)
multiple programming models to author services with. For Java,
there's an SCA POJO model, Spring and (hopefully at some point others
such as EJB, JAX-WS, etc.). The SCA programming model supported by
Tuscany is principally focused on exposing assembly concepts to the
service developer, so things like non-blocking invocations,
conversations, statefull interactions, etc. Spring, in addition to
having a programming model, is also an application framework so it
has a broader range of functionality including UI, persistence
abstraction, AOP, etc. From a Spring perspective, I'd say the value
in SCA is (as you stated) that it allows remote wiring to and from
Spring beans. Spring has a basic remoting technology but SCA provides
more thorough capabilities in this regard. I'd probably characterize
it more as "remote/coarse-grained" wiring as opposed to "mediated
wiring" since Spring's AOP infrastructure supports mediation on a
local scale.
Similar to Spring, there is some overlap with SCA with OSGi,
specifically around the OSGI r4 service model. However, I also see a
lot of complimentary function and actually view OSGi services as
fitting into an SCA environment. In this case OSGi provides a host
environment for Tuscany and OSGi services may be wired to from
Tuscany (as well as the latter publishing services into OSGi).
Jim
This seems like what the OSOA Client and Implementation spec for
Spring
implies. I just wonder how it's viewed from the Spring side of the
fence.
Rod and Adrian are one the spec group. Most of where they have
concentrated has been on the Spring Client and Implementation model
so my assumption would be the value they see is in integration of
Spring with SCA's remote wiring capabilities.
Oh well, it looks like we need those OSGi services and bindings in
Tuscany regardless, so I'll get back to working on them. For the OSGi
crowd, size matters - and smaller is better.
:-) One of the things we should talk about is embedding the Tuscany
runtime in "somewhat" small devices. I think it would be interesting
to have my Tivo wired with SCA. Seriously, I think this is a really
interesting scenario as there is no reason Tuscany should not be able
to scale down as well as up.
Jim
They won't want to include
the Spring jars if they don't have to. Thanks again for the link - it
helps to level-set what the SCA binding should be capable of!
Cheers,
Joel
-----Original Message-----
From: Andy Piper [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 6:07 PM
To: tuscany-dev@ws.apache.org
Cc: tuscany-dev@ws.apache.org
Subject: RE: OSGi host
Hi Joel,
I'm new to SCA, so don't believe everything I say :)
OSGi is IMO an infrastructure technology suitable for building
container technologies such as SCA.
Spring is a Java component wiring technology, so inevitably overlaps
with some of what SCA is trying to achieve (and EJB3 for example).
That's ok - customers will decide what is appropriate for them.
For me the sweet spot of SCA is SOA which has no overlap at all with
either Spring or OSGI.
andy
At 02:50 PM 8/21/2006, Hawkins, Joel wrote:
Hi Andy,
Thanks for the link. You bring up a question that's been troubling me
about some of this. What is the role of OSGi in SCA? How does it
differ
from the role of something like Spring? Or, asked in the larger
sense,
where does SCA fit into the world of Containers?
My assumption has been that OSGi is analogous to Tomcat - it is the
outer container for hosting SCA runtime instances (the Hosting
Platform). I saw Spring as something contained by an SCA runtime.
In my
simple world view, that would mean that the SCA runtime should
mediate
between the OSGi and Spring worlds. I'm assuming that we would
want an
SCA wire between Spring beans accessing OSGi services, etc. so
that SCA
would have a place to inject code (for whatever reason), and so that
the
SCDLs would more closely reflect the actual application's
interrelationships (a really nice side-effect that enhances
manageability). All of this argues for a separate OSGi binding for
SCA
(and a single SCA bean-type in Spring for 'outside' beans).
On the other hand, there is quite a bit of overlap between what
Spring
and SCA do, and I am getting the feeling that this code could rapidly
become wheel-shaped. :-) Do you have any suggestions for how to
proceed?
What are your thoughts on the big-picture relationship between SCA
and
these fully-featured containers like Spring and J2EE?
Thanks,
Joel
-----Original Message-----
From: Andy Piper [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 6:40 AM
To: tuscany-dev@ws.apache.org
Cc: tuscany-dev@ws.apache.org
Subject: RE: OSGi host
Note that you will get a lot of this stuff for free if you use
Spring.
http://opensource.atlassian.com/projects/spring/secure/attachment/
11891
/
spring_and_osgi.html
andy
At 14:44 18/08/2006, Hawkins, Joel wrote:
Jim,
I've done an intial checkin of your patch for OSGi host support. I
did some mods and didn't check in the samples as we have a
discussion
ongoing on how best to structure the samples and didn't want to
create more issues for now related to the restructuring.
Yes, how to deal with samples is always and issue. I'm sure dealing
with
test cases will be as well.
1. I didn't check in support for OSGi services as component
implementation types. For SCA, our model has typically been that
implementation types are created for artifacts that are deployed
and
evolved as part of a composite. Services that are not deployed with
the composite are treated as external and modeled as References. I
think this fits with OSGi as well, whose services are more dynamic
in
nature. Given that, I think we should be providing an OSGi binding
that accesses those services as References and publishes SCA
components as OSGi Services.
I agree. I think where I went for Implementation rather than
Reference
is when the core wanted me to specify a target declared in the
component. In the spec, you can declare a reference without a
target,
but that didn't appear to be the case in the code I had. My thought
process (such as it is..) was that at a certain layer exposure to
the
SCA runtime as an implementation or a service was really just a
layering
operation, and converting from one to the other wouldn't be a big
effort. I should have pointed that out in the patch. I'll take a
shot
at
converting this to a Reference today if you'd like.
2. Related to the binding, I started to make a bunch of mods to the
builder and removed the wiring and connector implementation since
the
core will provide those now. For example, the core will wire a
Component to a Reference with an OSGi binding and will wire a
Service with an OSGi binding to a target component. I haven't
finished this, but did put some basics in.
I wish I'd have waited another week to start - trying to grok all
that
wiring code made my head hurt. It was a good day when y'all decided
to
move that into the core. :-)
3. I added the OSGi project as a runtime project. I was imagining
having a generic OSGi project that provided the binding
capabilities
and then platform specific projects for running on various OSGi
implementations such as Equinox, Felix, or Knoplerfish.
Makes sense. There's only one class that's equinox-specific, so
hopefully the move to multiple OSGi implementations shouldn't be too
painful.
4. I started to make specific refactorings in the code to follow
some
of the patterns we have in the container. For example, instead of
BundleContextUtil, I was thinking we would have a "system
service" (another SCA component) that is an OSGiHost which allows
the
OSGi extension to talk to the OSGI container to do things such as
publish services. I didn't move the code over in BundleContextUtil
yet, though.
That's cool, so then OSGiHost may be the only platform-specific bit
of
code in the distribution. I like it.
5. I also renamed Activator to LauncherActivator as I think the SCA
runtime should be packaged as a bundle and launched through it.
Sure. Eclipse made the Activator class (it's a default). I assume
you
updated the manifest as well.
We can discuss the changes in more detail. I think we also need to
figure out a bunch of things, including application deployment,
extension deployment and how classloading will play out. For
example,
in our component tree, a composite may have the following
classloader
relationships. For system extensions:
<SNIP/>
We'll need to map that into OSGi bundles and classloader
management.
Yes, that's where the fun starts. Can you suggest a good
experimental
scenario based on what's in Tuscany today?
If you're online tomorrow, I will be happy to chat in more detail.
I'm on googletalk at [EMAIL PROTECTED] or (preferrably) on IRC
#tuscany.
I'm stuck behind a corporate firewall that doesn't allow IRC
traffic.
I'll try and get that fixed, but I can guarantee that it won't
happen
in
one day.
Thanks for submitting this and sorry I started to butcher parts of
it
so quickly!
No problem - I was planning on a fair amount of tear-up just
based on
what was going on in the mailing list!
The contents of this e-mail are intended for the named addressee
only. It contains information that may be confidential. Unless you
are the named addressee or an authorized designee, you may not copy
or use it, or disclose it to anyone else. If you received it in
error please notify us immediately and then destroy it.
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_____________________________________________________________________
__
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The contents of this e-mail are intended for the named addressee
only. It contains information that may be confidential. Unless you
are the named addressee or an authorized designee, you may not copy
or use it, or disclose it to anyone else. If you received it in
error please notify us immediately and then destroy it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
______________________________________________________________________
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The contents of this e-mail are intended for the named addressee
only. It contains information that may be confidential. Unless you
are the named addressee or an authorized designee, you may not copy
or use it, or disclose it to anyone else. If you received it in
error please notify us immediately and then destroy it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
