Home » Archived » Service Component Architecture (SCA) Tools » Service vs. Component
| Service vs. Component [message #501476] |
Wed, 02 December 2009 13:55  |
Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
when looking at SCA, of course I see some benefits compared to common
component models. SCA is platform and language neutral. It supports a
lot of bindings etc.
But what is the difference between a component / service in SCA and for
example EJBs or COM etc.? Is a component in SCA a service or more a
component? Since it is not public it seems to be a component. Or could
it be called private service? This results in the central question: What
in SCA is the difference between a component and a service? In SOA,
typically a service is a functionality that is public, coarse grained,
business aligned, autonomous etc. In SCA the service seems to be the
access to a distributed component that does not have to be coarse
grained, public etc.
So, SCA seems to be a more comfortable way to build component based
applications. Only, it is called service now.
Maybe you can help me to understand the benefit here.
Best regards
Michael
|
|
|
| Re: Service vs. Component [message #501965 is a reply to message #501476] |
Fri, 04 December 2009 15:26  |
|
Hi Mickael,
Michael Gebhart a écrit :
> Hi,
>
> when looking at SCA, of course I see some benefits compared to common
> component models. SCA is platform and language neutral. It supports a
> lot of bindings etc.
>
> But what is the difference between a component / service in SCA and for
> example EJBs or COM etc.? Is a component in SCA a service or more a
> component?
That's hard to say honestly.
Personally, I don't think about SCA components but about SCA composites.
A SCA composite is an application.
When I look inside the composite, I think in terms of components.
But when I look at it from the outside, I think in terms of services.
> Since it is not public it seems to be a component. Or could
> it be called private service? This results in the central question: What
> in SCA is the difference between a component and a service?
Well, like I said: component is inside the application (composite).
Service is outside. Meaning SOA governance is outside. The way I should
manage my code (and thus the components, which are only "configurations
of code" - see the specifications) only concerns the inside part of the
composite.
> In SOA,
> typically a service is a functionality that is public, coarse grained,
> business aligned, autonomous etc. In SCA the service seems to be the
> access to a distributed component that does not have to be coarse
> grained, public etc.
>
> So, SCA seems to be a more comfortable way to build component based
> applications. Only, it is called service now.
One advantage of components is their reusability among several
applications. Reusablity meaning reusing the code (interfaces,
implementations). If you just want to reuse the functionality, reference
a service instead.
That also depends on who wrote and provided a composite or a service.
The discussion only becomes interesting if you consider several actors
(several application providers and service consumers).
At least, this is my opinion.
I'm not sure, however, that it answers exactly your questions.
Best regards,
Vincent.
|
|
|
| Re: Service vs. Component [message #502213 is a reply to message #501965] |
Mon, 07 December 2009 09:24 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi Vincent,
> A SCA composite is an application.
> When I look inside the composite, I think in terms of components.
> But when I look at it from the outside, I think in terms of services.
I totally agree with this. But how does this fit to the use of
"services" at components within a SCA assembly?
These services are not accessible from outside the application. They are
internal only.
In my opinion, the services within an SCA assembly are services with
restricted visibility. I call this private service. They are for
internal use only, but can simply be replaced (re-wired) with public,
already available services. Components are hard-wired. They can not be
restructured. With services on the SCA level, we have functionality,
that can be restructured when deploying or running the application. This
differs from the component-oriented software.
Best regards
Michael
|
|
|
| Re: Service vs. Component [message #576654 is a reply to message #501476] |
Fri, 04 December 2009 15:26 |
|
Hi Mickael,
Michael Gebhart a écrit :
> Hi,
>
> when looking at SCA, of course I see some benefits compared to common
> component models. SCA is platform and language neutral. It supports a
> lot of bindings etc.
>
> But what is the difference between a component / service in SCA and for
> example EJBs or COM etc.? Is a component in SCA a service or more a
> component?
That's hard to say honestly.
Personally, I don't think about SCA components but about SCA composites.
A SCA composite is an application.
When I look inside the composite, I think in terms of components.
But when I look at it from the outside, I think in terms of services.
> Since it is not public it seems to be a component. Or could
> it be called private service? This results in the central question: What
> in SCA is the difference between a component and a service?
Well, like I said: component is inside the application (composite).
Service is outside. Meaning SOA governance is outside. The way I should
manage my code (and thus the components, which are only "configurations
of code" - see the specifications) only concerns the inside part of the
composite.
> In SOA,
> typically a service is a functionality that is public, coarse grained,
> business aligned, autonomous etc. In SCA the service seems to be the
> access to a distributed component that does not have to be coarse
> grained, public etc.
>
> So, SCA seems to be a more comfortable way to build component based
> applications. Only, it is called service now.
One advantage of components is their reusability among several
applications. Reusablity meaning reusing the code (interfaces,
implementations). If you just want to reuse the functionality, reference
a service instead.
That also depends on who wrote and provided a composite or a service.
The discussion only becomes interesting if you consider several actors
(several application providers and service consumers).
At least, this is my opinion.
I'm not sure, however, that it answers exactly your questions.
Best regards,
Vincent.
|
|
|
| Re: Service vs. Component [message #576693 is a reply to message #501965] |
Mon, 07 December 2009 09:24 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi Vincent,
> A SCA composite is an application.
> When I look inside the composite, I think in terms of components.
> But when I look at it from the outside, I think in terms of services.
I totally agree with this. But how does this fit to the use of
"services" at components within a SCA assembly?
These services are not accessible from outside the application. They are
internal only.
In my opinion, the services within an SCA assembly are services with
restricted visibility. I call this private service. They are for
internal use only, but can simply be replaced (re-wired) with public,
already available services. Components are hard-wired. They can not be
restructured. With services on the SCA level, we have functionality,
that can be restructured when deploying or running the application. This
differs from the component-oriented software.
Best regards
Michael
|
|
|
Goto Forum:
Current Time: Sat Dec 21 16:07:16 GMT 2024
Powered by FUDForum. Page generated in 0.03635 seconds |
] 
Search
Help
Register
Login
Home
