You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Rich Smith Jr (rjsmith2)" <rj...@cisco.com> on 2009/02/18 22:47:20 UTC
General selling point question (more, different questions)
Sorry in advance for the noise if this is not the correct forum for
this:
Our group is currently negotiating with another group in our company to
come to an
agreement on a platform for some common services.
The other team is pretty well set on EJB3 and JBoss, whereas we had been
leaning
toward SCA Java, in combination with at least Spring.
Stangely enough, there seems to be quite a bit of convergence between
the technologies,
and I know that implementation.ejb is actually one of the SCA component
implementation
types.
But, can anyone provide a pointer or some arguments in favor of or
against
Spring + Tuscany SCA Java ( + JBoss?) versus JBoss / EJB3.
As a starting point, the EJB3 argument goes something like this:
. JCP standards based
. Rich set of application services bundled with app server
. Built-in clustering capability (distributed coherent cache + JTA
provided
by app server)
I think the Spring / SCA argument would include:
. Supports heterogeneous components (EJB, Spring, OSGi...)
. More configurable (lighter weight deployments possible other than
full
app server).
The arguments against Spring / SCA include:
. Requires assembly of more parts (SCA, Spring, JTOM, Hibernate,
etc.)
. No built-in clustering capability (Terracotta looked promising, but
our legal department
will never approve their license, and we don't want "Powered by
Terracotta" all over our
application, and we're too cheap to pay for it ;-)
. Not JCP standard
My take on the EJB3 case is that while clustering comes bundled, it is
not clear that it
would really buy us anything. For our app, we don't need load-balanced,
symmetrical
pools of service instances running across multiple JVMs. We actually
need to carefully
configure which services run where, which are colocated, and which have
affinity to
certain servers. (Maybe it is possible to configure this with JBoss? I
know it is with
Tuscany SCA Java.)
Also, using EJB3 locks you into EJB-specific annotations, whereas using
SCA with
implementation.ejb, for example, would permit better interoperability
with non-EJB
components.
Does anyone want to weigh in on this, or just provide some links?
There's a lot of propaganda out there, and a lot of it is FUD or just
plain out of date.
It's hard to make a coherent argument one way or the other. Any help
would be
appreciated.
Thanks.
--Rich
________________________________
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Sunday, February 15, 2009 6:43 AM
To: user@tuscany.apache.org
Subject: Re: General selling point question
On Sat, Feb 14, 2009 at 5:51 AM, Moreau, Christopher
<Ch...@gdit.com> wrote:
This isn't a specific technical question, but rather more of a
how to I make the case for Tuscany SCA question. I am on a project with
multiple contributors. The SOA has an ESB. I am having a hard time
figuring out the key role for SCA. Many of capabilities seem like
things available via the ESB.
-C
Hi Christopher.
>From my point of view SCA's role is to provide consistency. For example,
consistency in the programming model used to expose services and exploit
references to other services, consistency in the way you describe the
assembly of components in your solution and consistency in the way that
policy is applied to control quality of service concerns. The SCA model
applies regardless of what implementation or communcation technology you
use.
In you're scenario how do the multiple contributors implement services
and communicate with the ESB? Do services only ever communicate via the
ESB?
Regards
Simon
RE: General selling point question (more, different questions)
Posted by "Rich Smith Jr (rjsmith2)" <rj...@cisco.com>.
I kind of get how SCA relates to ESB, but what I need to figure out is
how SCA relates
to EJB3.
I know that EJB is a component implementation type in SCA, but what
advantage is there
for using EJB within an SCA container as opposed to just using an app
server like JBoss
by itself?
I had listed what I consider to be some of the points in-favor or
against below.
Any help or pointers would be appreciated.
--Rich
________________________________
From: Raymond Feng [mailto:enjoyjava@gmail.com]
Sent: Wednesday, February 18, 2009 10:04 PM
To: user@tuscany.apache.org
Subject: Re: General selling point question (more, different questions)
Hi,
Here are my 2 cents for the SCA vs. ESB discussion:
1) IMO, SCA and ESB are positioned differently. SCA is an application
oriented service construction and assembly model while ESB is about the
integration of middleware to facilitate application connectivity. In a
way, SCA defines the logical structure and composition of an
application. With SCA, developers can focus on the business logic
without being puzzled by plumbing technologies. I have tried a JBI based
ESB. To my limited experience, the application code has to deal with the
normalized message to extract the request and package the response, the
business logic is polluted and coupled with the technology API calls.
2) ESB can be the communication infrastructure between SCA components.
SCA uses declarative bindings to configure how services communicate over
various protocols. In SCA, the reference and service need to have the
same bindings so that they can be wired. ESB can provide a universal
binding for SCA to hide the communication details.
3) ESB can also provide technology-oriented SCA components to support
the mediations between business components, for example, routing,
protocol conversion, data mapping, data transformation and business
rules.
There is also an interesting presentation from OASIS OpenCSA group:
http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files
/SCA-ESB-v4.ppt
Thanks,
Raymond
From: Moreau, Christopher <ma...@gdit.com>
Sent: Wednesday, February 18, 2009 3:57 PM
To: user@tuscany.apache.org
Subject: RE: General selling point question (more, different questions)
My impression after considering the same type of questions is that
Tuscany is functionally another type of ESB.
Since there is no standard for ESBs (similar to the servlet standard for
the app server) implementation and deployment of services and
communication between them becomes specific to the stack you have
committed to.
The theoretical benefit of the "SCA ESB" is that you have a standard.
The standard based deployment descriptor (the .composite file) is an
example benefit. You have more flexibility in binding (multiple
contributors can communicate with the different bindings) and
implementation types. That being said, you have still committed to a
particular stacks way of doing things, in this case it's the Tuscany SCA
ESB way which has its own collection of annotations, syntax, messaging,
and deployment methods.
Based on my current work, I would love to see SCA as an obvious choice
but what seems to complicate this choice even more is the various long
standing bugs with, and/or limited implementation of what would seem to
be very prominent binding types, namely web services, EJB, JMS:
For example: WS Related Issues (note the summary listing for each TR is
mine, not in the actual listing)
TUSCANY-1758 <https://issues.apache.org/jira/browse/TUSCANY-1758> :
Errors occur when referencing a WS created using Axis2 1.3
TUSCANY-1890 <https://issues.apache.org/jira/browse/TUSCANY-1890> :
Conversations not support for components using WSDL interface
TUSCANY-1892 <https://issues.apache.org/jira/browse/TUSCANY-1892> : WSDL
Generation does not support methods that throw Exceptions
TUSCANY-1912 <https://issues.apache.org/jira/browse/TUSCANY-1912> :
Errors occur when promoting a reference that uses the WS binding and
callback functionality
TUSCANY-2059 <https://issues.apache.org/jira/browse/TUSCANY-2059> : WS
binding does not support methods with no parameters and a void return
type
TUSCANY-2386 <https://issues.apache.org/jira/browse/TUSCANY-2386> :
Errors occur when using the WS binding and arrays of XML bound objects
TUSCANY-2664 <https://issues.apache.org/jira/browse/TUSCANY-2664> :
Errors occur when using the WS binding and Axis2 objects
TUSCANY-2757 <https://issues.apache.org/jira/browse/TUSCANY-2757> :
Errors occur when using Tuscany generated WSDL containing nillable types
TUSCANY-2853 <https://issues.apache.org/jira/browse/TUSCANY-2853> :
Cannot create WS clients from Tuscany generated WSDLs
Misc Issues
TUSCANY-2215 <https://issues.apache.org/jira/browse/TUSCANY-2215> :
Destroy method not called when request scoped components are destroyed
TUSCANY-2824 <https://issues.apache.org/jira/browse/TUSCANY-2824> : WS
binding does not apply the assigned WS security rules; full access is
given to any caller
WRT:
>>From my point of view SCA's role is to provide consistency. For
example, consistency in the programming model used to expose services
and exploit references to other services,
Don't I get this as soon as I commit to any stack?
WRT:
> consistency in the way you describe the assembly of components in your
solution
Again, don't I get this as soon as a pick my ESB stack(e.g. service
chains in Mule or JBoss, or BPEL w. JBoss)
>and consistency in the way that policy is applied to control quality of
service concerns. The SCA model applies regardless of what
implementation or communcation technology you
use.
I would like to understand this more so I can defend this. We're still
experimenting with application of policy. For QoS, am I just applying a
constraint? E.g.: It can answer within 3 seconds or I'm not interested.
We're investigating use of policy for identification and authorization
(w. SAML), any pointers or places in the wiki you recommend we look?
>In you're scenario how do the multiple contributors implement services
and communicate with the ESB? Do services only ever communicate via the
ESB?
The various contributors are experimenting with this right now. Service
chaining is used, UDDI is use for look up, etc...
With regard to the communication model and the SCA spec, we were very
interested the default binding and the possibilities of that binding for
providing interoperability between Java and C/C++ based components. The
spec suggested the default binding might become a runtime discriminator
on the basis of performance. This seemed very relevant. However Tuscany
implements Java component support and C/C++ component support in
separate runtimes and thus <I think> separate domains, so the
communication between these implementation types is limited to a binding
with high overhead (WS) which could be achieved in other frame works.
In addition having the separate domains eliminates the possibility of
using a very useful companion technology; SDO, between java and C++
components. Basically having separate runtimes for Java and C/C++ seems
to tarnish the promise of supporting multiple implementation types. Was
there a compelling reason for having separate runtimes?
Please note that while my response my seem adversarial, I am only
writing that way in order to hopefully get some great answers that I can
learn from and use with others.
Respectfully,
Chris Moreau
________________________________
From: Rich Smith Jr (rjsmith2) [mailto:rjsmith2@cisco.com]
Sent: Wednesday, February 18, 2009 1:47 PM
To: user@tuscany.apache.org
Subject: General selling point question (more, different questions)
Sorry in advance for the noise if this is not the correct forum for
this:
Our group is currently negotiating with another group in our company to
come to an
agreement on a platform for some common services.
The other team is pretty well set on EJB3 and JBoss, whereas we had been
leaning
toward SCA Java, in combination with at least Spring.
Stangely enough, there seems to be quite a bit of convergence between
the technologies,
and I know that implementation.ejb is actually one of the SCA component
implementation
types.
But, can anyone provide a pointer or some arguments in favor of or
against
Spring + Tuscany SCA Java ( + JBoss?) versus JBoss / EJB3.
As a starting point, the EJB3 argument goes something like this:
. JCP standards based
. Rich set of application services bundled with app server
. Built-in clustering capability (distributed coherent cache + JTA
provided
by app server)
I think the Spring / SCA argument would include:
. Supports heterogeneous components (EJB, Spring, OSGi...)
. More configurable (lighter weight deployments possible other than
full
app server).
The arguments against Spring / SCA include:
. Requires assembly of more parts (SCA, Spring, JTOM, Hibernate,
etc.)
. No built-in clustering capability (Terracotta looked promising, but
our legal department
will never approve their license, and we don't want "Powered by
Terracotta" all over our
application, and we're too cheap to pay for it ;-)
. Not JCP standard
My take on the EJB3 case is that while clustering comes bundled, it is
not clear that it
would really buy us anything. For our app, we don't need load-balanced,
symmetrical
pools of service instances running across multiple JVMs. We actually
need to carefully
configure which services run where, which are colocated, and which have
affinity to
certain servers. (Maybe it is possible to configure this with JBoss? I
know it is with
Tuscany SCA Java.)
Also, using EJB3 locks you into EJB-specific annotations, whereas using
SCA with
implementation.ejb, for example, would permit better interoperability
with non-EJB
components.
Does anyone want to weigh in on this, or just provide some links?
There's a lot of propaganda out there, and a lot of it is FUD or just
plain out of date.
It's hard to make a coherent argument one way or the other. Any help
would be
appreciated.
Thanks.
--Rich
________________________________
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Sunday, February 15, 2009 6:43 AM
To: user@tuscany.apache.org
Subject: Re: General selling point question
On Sat, Feb 14, 2009 at 5:51 AM, Moreau, Christopher
<Ch...@gdit.com> wrote:
This isn't a specific technical question, but rather more of a how to I
make the case for Tuscany SCA question. I am on a project with multiple
contributors. The SOA has an ESB. I am having a hard time figuring out
the key role for SCA. Many of capabilities seem like things available
via the ESB.
-C
Hi Christopher.
>From my point of view SCA's role is to provide consistency. For example,
consistency in the programming model used to expose services and exploit
references to other services, consistency in the way you describe the
assembly of components in your solution and consistency in the way that
policy is applied to control quality of service concerns. The SCA model
applies regardless of what implementation or communcation technology you
use.
In you're scenario how do the multiple contributors implement services
and communicate with the ESB? Do services only ever communicate via the
ESB?
Regards
Simon
Re: General selling point question (more, different questions)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Here are my 2 cents for the SCA vs. ESB discussion:
1) IMO, SCA and ESB are positioned differently. SCA is an application oriented service construction and assembly model while ESB is about the integration of middleware to facilitate application connectivity. In a way, SCA defines the logical structure and composition of an application. With SCA, developers can focus on the business logic without being puzzled by plumbing technologies. I have tried a JBI based ESB. To my limited experience, the application code has to deal with the normalized message to extract the request and package the response, the business logic is polluted and coupled with the technology API calls.
2) ESB can be the communication infrastructure between SCA components. SCA uses declarative bindings to configure how services communicate over various protocols. In SCA, the reference and service need to have the same bindings so that they can be wired. ESB can provide a universal binding for SCA to hide the communication details.
3) ESB can also provide technology-oriented SCA components to support the mediations between business components, for example, routing, protocol conversion, data mapping, data transformation and business rules.
There is also an interesting presentation from OASIS OpenCSA group:
http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files/SCA-ESB-v4.ppt
Thanks,
Raymond
From: Moreau, Christopher
Sent: Wednesday, February 18, 2009 3:57 PM
To: user@tuscany.apache.org
Subject: RE: General selling point question (more, different questions)
My impression after considering the same type of questions is that Tuscany is functionally another type of ESB.
Since there is no standard for ESBs (similar to the servlet standard for the app server) implementation and deployment of services and communication between them becomes specific to the stack you have committed to.
The theoretical benefit of the "SCA ESB" is that you have a standard. The standard based deployment descriptor (the .composite file) is an example benefit. You have more flexibility in binding (multiple contributors can communicate with the different bindings) and implementation types. That being said, you have still committed to a particular stacks way of doing things, in this case it's the Tuscany SCA ESB way which has its own collection of annotations, syntax, messaging, and deployment methods.
Based on my current work, I would love to see SCA as an obvious choice but what seems to complicate this choice even more is the various long standing bugs with, and/or limited implementation of what would seem to be very prominent binding types, namely web services, EJB, JMS:
For example: WS Related Issues (note the summary listing for each TR is mine, not in the actual listing)
TUSCANY-1758: Errors occur when referencing a WS created using Axis2 1.3
TUSCANY-1890: Conversations not support for components using WSDL interface
TUSCANY-1892: WSDL Generation does not support methods that throw Exceptions
TUSCANY-1912: Errors occur when promoting a reference that uses the WS binding and callback functionality
TUSCANY-2059: WS binding does not support methods with no parameters and a void return type
TUSCANY-2386: Errors occur when using the WS binding and arrays of XML bound objects
TUSCANY-2664: Errors occur when using the WS binding and Axis2 objects
TUSCANY-2757: Errors occur when using Tuscany generated WSDL containing nillable types
TUSCANY-2853: Cannot create WS clients from Tuscany generated WSDLs
Misc Issues
TUSCANY-2215: Destroy method not called when request scoped components are destroyed
TUSCANY-2824: WS binding does not apply the assigned WS security rules; full access is given to any caller
WRT:>From my point of view SCA's role is to provide consistency. For example, consistency in the programming model used to expose services and exploit references to other services, Don't I get this as soon as I commit to any stack? WRT:> consistency in the way you describe the assembly of components in your solution Again, don't I get this as soon as a pick my ESB stack(e.g. service chains in Mule or JBoss, or BPEL w. JBoss) >and consistency in the way that policy is applied to control quality of service concerns. The SCA model applies regardless of what implementation or communcation technology youuse.I would like to understand this more so I can defend this. We're still experimenting with application of policy. For QoS, am I just applying a constraint? E.g.: It can answer within 3 seconds or I'm not interested. We're investigating use of policy for identification and authorization (w. SAML), any pointers or places in the wiki you recommend we look? >In you're scenario how do the multiple contributors implement services and communicate with the ESB? Do services only ever communicate via the ESB?The various contributors are experimenting with this right now. Service chaining is used, UDDI is use for look up, etc. With regard to the communication model and the SCA spec, we were very interested the default binding and the possibilities of that binding for providing interoperability between Java and C/C++ based components. The spec suggested the default binding might become a runtime discriminator on the basis of performance. This seemed very relevant. However Tuscany implements Java component support and C/C++ component support in separate runtimes and thus <I think> separate domains, so the communication between these implementation types is limited to a binding with high overhead (WS) which could be achieved in other frame works. In addition having the separate domains eliminates the possibility of using a very useful companion technology; SDO, between java and C++ components. Basically having separate runtimes for Java and C/C++ seems to tarnish the promise of supporting multiple implementation types. Was there a compelling reason for having separate runtimes?
Please note that while my response my seem adversarial, I am only writing that way in order to hopefully get some great answers that I can learn from and use with others.
Respectfully,
Chris Moreau
--------------------------------------------------------------------------------
From: Rich Smith Jr (rjsmith2) [mailto:rjsmith2@cisco.com]
Sent: Wednesday, February 18, 2009 1:47 PM
To: user@tuscany.apache.org
Subject: General selling point question (more, different questions)
Sorry in advance for the noise if this is not the correct forum for this:
Our group is currently negotiating with another group in our company to come to an
agreement on a platform for some common services.
The other team is pretty well set on EJB3 and JBoss, whereas we had been leaning
toward SCA Java, in combination with at least Spring.
Stangely enough, there seems to be quite a bit of convergence between the technologies,
and I know that implementation.ejb is actually one of the SCA component implementation
types.
But, can anyone provide a pointer or some arguments in favor of or against
Spring + Tuscany SCA Java ( + JBoss?) versus JBoss / EJB3.
As a starting point, the EJB3 argument goes something like this:
. JCP standards based
. Rich set of application services bundled with app server
. Built-in clustering capability (distributed coherent cache + JTA provided
by app server)
I think the Spring / SCA argument would include:
. Supports heterogeneous components (EJB, Spring, OSGi...)
. More configurable (lighter weight deployments possible other than full
app server).
The arguments against Spring / SCA include:
. Requires assembly of more parts (SCA, Spring, JTOM, Hibernate, etc.)
. No built-in clustering capability (Terracotta looked promising, but our legal department
will never approve their license, and we don't want "Powered by Terracotta" all over our
application, and we're too cheap to pay for it ;-)
. Not JCP standard
My take on the EJB3 case is that while clustering comes bundled, it is not clear that it
would really buy us anything. For our app, we don't need load-balanced, symmetrical
pools of service instances running across multiple JVMs. We actually need to carefully
configure which services run where, which are colocated, and which have affinity to
certain servers. (Maybe it is possible to configure this with JBoss? I know it is with
Tuscany SCA Java.)
Also, using EJB3 locks you into EJB-specific annotations, whereas using SCA with
implementation.ejb, for example, would permit better interoperability with non-EJB
components.
Does anyone want to weigh in on this, or just provide some links?
There's a lot of propaganda out there, and a lot of it is FUD or just plain out of date.
It's hard to make a coherent argument one way or the other. Any help would be
appreciated.
Thanks.
--Rich
--------------------------------------------------------------------------------
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Sunday, February 15, 2009 6:43 AM
To: user@tuscany.apache.org
Subject: Re: General selling point question
On Sat, Feb 14, 2009 at 5:51 AM, Moreau, Christopher <Ch...@gdit.com> wrote:
This isn't a specific technical question, but rather more of a how to I make the case for Tuscany SCA question. I am on a project with multiple contributors. The SOA has an ESB. I am having a hard time figuring out the key role for SCA. Many of capabilities seem like things available via the ESB.
-C
Hi Christopher.
>From my point of view SCA's role is to provide consistency. For example, consistency in the programming model used to expose services and exploit references to other services, consistency in the way you describe the assembly of components in your solution and consistency in the way that policy is applied to control quality of service concerns. The SCA model applies regardless of what implementation or communcation technology you use.
In you're scenario how do the multiple contributors implement services and communicate with the ESB? Do services only ever communicate via the ESB?
Regards
Simon
RE: General selling point question (more, different questions)
Posted by "Moreau, Christopher" <Ch...@gdit.com>.
My impression after considering the same type of questions is that
Tuscany is functionally another type of ESB.
Since there is no standard for ESBs (similar to the servlet standard for
the app server) implementation and deployment of services and
communication between them becomes specific to the stack you have
committed to.
The theoretical benefit of the "SCA ESB" is that you have a standard.
The standard based deployment descriptor (the .composite file) is an
example benefit. You have more flexibility in binding (multiple
contributors can communicate with the different bindings) and
implementation types. That being said, you have still committed to a
particular stacks way of doing things, in this case it's the Tuscany SCA
ESB way which has its own collection of annotations, syntax, messaging,
and deployment methods.
Based on my current work, I would love to see SCA as an obvious choice
but what seems to complicate this choice even more is the various long
standing bugs with, and/or limited implementation of what would seem to
be very prominent binding types, namely web services, EJB, JMS:
For example: WS Related Issues (note the summary listing for each TR is
mine, not in the actual listing)
TUSCANY-1758 <https://issues.apache.org/jira/browse/TUSCANY-1758> :
Errors occur when referencing a WS created using Axis2 1.3
TUSCANY-1890 <https://issues.apache.org/jira/browse/TUSCANY-1890> :
Conversations not support for components using WSDL interface
TUSCANY-1892 <https://issues.apache.org/jira/browse/TUSCANY-1892> : WSDL
Generation does not support methods that throw Exceptions
TUSCANY-1912 <https://issues.apache.org/jira/browse/TUSCANY-1912> :
Errors occur when promoting a reference that uses the WS binding and
callback functionality
TUSCANY-2059 <https://issues.apache.org/jira/browse/TUSCANY-2059> : WS
binding does not support methods with no parameters and a void return
type
TUSCANY-2386 <https://issues.apache.org/jira/browse/TUSCANY-2386> :
Errors occur when using the WS binding and arrays of XML bound objects
TUSCANY-2664 <https://issues.apache.org/jira/browse/TUSCANY-2664> :
Errors occur when using the WS binding and Axis2 objects
TUSCANY-2757 <https://issues.apache.org/jira/browse/TUSCANY-2757> :
Errors occur when using Tuscany generated WSDL containing nillable types
TUSCANY-2853 <https://issues.apache.org/jira/browse/TUSCANY-2853> :
Cannot create WS clients from Tuscany generated WSDLs
Misc Issues
TUSCANY-2215 <https://issues.apache.org/jira/browse/TUSCANY-2215> :
Destroy method not called when request scoped components are destroyed
TUSCANY-2824 <https://issues.apache.org/jira/browse/TUSCANY-2824> : WS
binding does not apply the assigned WS security rules; full access is
given to any caller
WRT:
>>From my point of view SCA's role is to provide consistency. For
example, consistency in the programming model used to expose services
and exploit references to other services,
Don't I get this as soon as I commit to any stack?
WRT:
> consistency in the way you describe the assembly of components in your
solution
Again, don't I get this as soon as a pick my ESB stack(e.g. service
chains in Mule or JBoss, or BPEL w. JBoss)
>and consistency in the way that policy is applied to control quality of
service concerns. The SCA model applies regardless of what
implementation or communcation technology you
use.
I would like to understand this more so I can defend this. We're still
experimenting with application of policy. For QoS, am I just applying a
constraint? E.g.: It can answer within 3 seconds or I'm not interested.
We're investigating use of policy for identification and authorization
(w. SAML), any pointers or places in the wiki you recommend we look?
>In you're scenario how do the multiple contributors implement services
and communicate with the ESB? Do services only ever communicate via the
ESB?
The various contributors are experimenting with this right now. Service
chaining is used, UDDI is use for look up, etc...
With regard to the communication model and the SCA spec, we were very
interested the default binding and the possibilities of that binding for
providing interoperability between Java and C/C++ based components. The
spec suggested the default binding might become a runtime discriminator
on the basis of performance. This seemed very relevant. However Tuscany
implements Java component support and C/C++ component support in
separate runtimes and thus <I think> separate domains, so the
communication between these implementation types is limited to a binding
with high overhead (WS) which could be achieved in other frame works.
In addition having the separate domains eliminates the possibility of
using a very useful companion technology; SDO, between java and C++
components. Basically having separate runtimes for Java and C/C++ seems
to tarnish the promise of supporting multiple implementation types. Was
there a compelling reason for having separate runtimes?
Please note that while my response my seem adversarial, I am only
writing that way in order to hopefully get some great answers that I can
learn from and use with others.
Respectfully,
Chris Moreau
________________________________
From: Rich Smith Jr (rjsmith2) [mailto:rjsmith2@cisco.com]
Sent: Wednesday, February 18, 2009 1:47 PM
To: user@tuscany.apache.org
Subject: General selling point question (more, different questions)
Sorry in advance for the noise if this is not the correct forum for
this:
Our group is currently negotiating with another group in our company to
come to an
agreement on a platform for some common services.
The other team is pretty well set on EJB3 and JBoss, whereas we had been
leaning
toward SCA Java, in combination with at least Spring.
Stangely enough, there seems to be quite a bit of convergence between
the technologies,
and I know that implementation.ejb is actually one of the SCA component
implementation
types.
But, can anyone provide a pointer or some arguments in favor of or
against
Spring + Tuscany SCA Java ( + JBoss?) versus JBoss / EJB3.
As a starting point, the EJB3 argument goes something like this:
. JCP standards based
. Rich set of application services bundled with app server
. Built-in clustering capability (distributed coherent cache + JTA
provided
by app server)
I think the Spring / SCA argument would include:
. Supports heterogeneous components (EJB, Spring, OSGi...)
. More configurable (lighter weight deployments possible other than
full
app server).
The arguments against Spring / SCA include:
. Requires assembly of more parts (SCA, Spring, JTOM, Hibernate,
etc.)
. No built-in clustering capability (Terracotta looked promising, but
our legal department
will never approve their license, and we don't want "Powered by
Terracotta" all over our
application, and we're too cheap to pay for it ;-)
. Not JCP standard
My take on the EJB3 case is that while clustering comes bundled, it is
not clear that it
would really buy us anything. For our app, we don't need load-balanced,
symmetrical
pools of service instances running across multiple JVMs. We actually
need to carefully
configure which services run where, which are colocated, and which have
affinity to
certain servers. (Maybe it is possible to configure this with JBoss? I
know it is with
Tuscany SCA Java.)
Also, using EJB3 locks you into EJB-specific annotations, whereas using
SCA with
implementation.ejb, for example, would permit better interoperability
with non-EJB
components.
Does anyone want to weigh in on this, or just provide some links?
There's a lot of propaganda out there, and a lot of it is FUD or just
plain out of date.
It's hard to make a coherent argument one way or the other. Any help
would be
appreciated.
Thanks.
--Rich
________________________________
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Sunday, February 15, 2009 6:43 AM
To: user@tuscany.apache.org
Subject: Re: General selling point question
On Sat, Feb 14, 2009 at 5:51 AM, Moreau, Christopher
<Ch...@gdit.com> wrote:
This isn't a specific technical question, but rather more of a how to I
make the case for Tuscany SCA question. I am on a project with multiple
contributors. The SOA has an ESB. I am having a hard time figuring out
the key role for SCA. Many of capabilities seem like things available
via the ESB.
-C
Hi Christopher.
>From my point of view SCA's role is to provide consistency. For example,
consistency in the programming model used to expose services and exploit
references to other services, consistency in the way you describe the
assembly of components in your solution and consistency in the way that
policy is applied to control quality of service concerns. The SCA model
applies regardless of what implementation or communcation technology you
use.
In you're scenario how do the multiple contributors implement services
and communicate with the ESB? Do services only ever communicate via the
ESB?
Regards
Simon