Home » Archived » Service Component Architecture (SCA) Tools » Service term in SCA
| Service term in SCA [message #468212] |
Tue, 04 August 2009 14:52  |
Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
I have a problem with the term of service in SCA. What is meant with a
service here? Is it a service in terms of a service that should be
published within a service inventory (as for instance UDDI) that other
interested parties can use it? Should these services be designed that
they can be used from other parties too?
Or is this service for internal use only? This would mean that it is
simply an interface for a component?
Best regards
Michael
|
|
|
| Re: Service term in SCA [message #468355 is a reply to message #468212] |
Wed, 05 August 2009 08:44  |
 Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
Michael Gebhart a écrit :
> Hi,
>
> I have a problem with the term of service in SCA. What is meant with a
> service here? Is it a service in terms of a service that should be
> published within a service inventory (as for instance UDDI) that other
> interested parties can use it? Should these services be designed that
> they can be used from other parties too?
>
> Or is this service for internal use only? This would mean that it is
> simply an interface for a component?
>
> Best regards
>
> Michael
Hi Michael,
I think that your misunderstanding is prompted by the fact that SCA
wants to unify 2 visions of distributed systems: (a) the
architecture-based and (b) the service-oriented visions.
In vision (a), a distributed system is organized as an architecture
built as an assembly of components with well defined interfaces. In
vision (b), a distributed system is organized as a set of independent
services used by different clients. Moreover, the main idea behind the
term service is the possibility to re-use them (services must be
designed for that : autonomy, loose coupling, stateless,...) and to
aggregate them to construct other services. You can find more
information here [0] (page 5) and an interesting article about service
granularity here [1].
So, to answer your question, SCA services
- can be used by other interested parties : a service promoted at the
composite level with a web service binding can be used by non SCA clients,
- can be used to construct an assembly of components. In this case, the
service can or not (internal use only) be promoted outside the composite.
Regards,
Stephane Drapeau
Obeo
[0]:
http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
[1]:
http://www.ibm.com/developerworks/webservices/library/ws-soa -granularity/
|
|
|
| Re: Service term in SCA [message #468390 is a reply to message #468355] |
Wed, 05 August 2009 11:33 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
thanks for your answer. I try to formalize my question in a differnt way:
Assuming a distributed system developed with SCA (S1). We have 5
components (A, B, C, D, E).
Now, another system is developed, also with SCA (S2). It requires
functionality that is already implemented in S1, more precisely
component A and B.
What happens? The developer who develops S2 does not know about A and B.
They are not provided as Webservice and are not registered within a
service registry.
How does the developer find A and B? Should A and B be exposed as web
service from the beginning and published into a service registry?
Or are they exposed as web service only on demand? But in this case: How
does the developer know about A and B?
Next problem: A third system has to be developed, S3. It requires
functionality that is part of S1, but not A, B, C, D or E.
The developer of S1 declares himself ready to comply with exposing the
required functionality as a component F. This can be used by S1 and S3.
But there are other ways possible: F could also be part of S3 and S1
uses this component as part of S3. Or should F be a completely new
application? What is the right way to expose shared functionality?
Best regards
Michael
|
|
|
| Re: Service term in SCA [message #468397 is a reply to message #468390] |
Wed, 05 August 2009 12:14 |
Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
The SCA specifications don't address these problems.
If a developer wants to be aware of the services already developed and
how to re-use them, then, a service repository or something like that is
needed.
The SCOrWare project has developed a semantic trader [0] (page 65),
which, I think, can be an interesting solution. We can imagine using it
at development time or at runtime.
Stephane
[0]:
http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
Michael Gebhart a écrit :
> Hi,
>
> thanks for your answer. I try to formalize my question in a differnt way:
>
> Assuming a distributed system developed with SCA (S1). We have 5
> components (A, B, C, D, E).
>
> Now, another system is developed, also with SCA (S2). It requires
> functionality that is already implemented in S1, more precisely
> component A and B.
>
> What happens? The developer who develops S2 does not know about A and B.
> They are not provided as Webservice and are not registered within a
> service registry.
>
> How does the developer find A and B? Should A and B be exposed as web
> service from the beginning and published into a service registry?
>
> Or are they exposed as web service only on demand? But in this case: How
> does the developer know about A and B?
>
>
> Next problem: A third system has to be developed, S3. It requires
> functionality that is part of S1, but not A, B, C, D or E.
>
> The developer of S1 declares himself ready to comply with exposing the
> required functionality as a component F. This can be used by S1 and S3.
>
> But there are other ways possible: F could also be part of S3 and S1
> uses this component as part of S3. Or should F be a completely new
> application? What is the right way to expose shared functionality?
>
>
> Best regards
>
> Michael
>
|
|
|
| Re: Service term in SCA [message #468398 is a reply to message #468397] |
Wed, 05 August 2009 12:19 |
Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
You can easily add SAWSDL annotations on composite files with the
Composite Designer [0].
Stephane
[0]: http://wiki.eclipse.org/STP/SCA_Project/Ontology
Stephane Drapeau a écrit :
> The SCA specifications don't address these problems.
> If a developer wants to be aware of the services already developed and
> how to re-use them, then, a service repository or something like that is
> needed.
> The SCOrWare project has developed a semantic trader [0] (page 65),
> which, I think, can be an interesting solution. We can imagine using it
> at development time or at runtime.
>
> Stephane
>
> [0]:
> http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
>
>
>
> Michael Gebhart a écrit :
>> Hi,
>>
>> thanks for your answer. I try to formalize my question in a differnt way:
>>
>> Assuming a distributed system developed with SCA (S1). We have 5
>> components (A, B, C, D, E).
>>
>> Now, another system is developed, also with SCA (S2). It requires
>> functionality that is already implemented in S1, more precisely
>> component A and B.
>>
>> What happens? The developer who develops S2 does not know about A and
>> B. They are not provided as Webservice and are not registered within
>> a service registry.
>>
>> How does the developer find A and B? Should A and B be exposed as web
>> service from the beginning and published into a service registry?
>>
>> Or are they exposed as web service only on demand? But in this case:
>> How does the developer know about A and B?
>>
>>
>> Next problem: A third system has to be developed, S3. It requires
>> functionality that is part of S1, but not A, B, C, D or E.
>>
>> The developer of S1 declares himself ready to comply with exposing the
>> required functionality as a component F. This can be used by S1 and S3.
>>
>> But there are other ways possible: F could also be part of S3 and S1
>> uses this component as part of S3. Or should F be a completely new
>> application? What is the right way to expose shared functionality?
>>
>>
>> Best regards
>>
>> Michael
>>
|
|
|
| Re: Service term in SCA [message #468431 is a reply to message #468390] |
Wed, 05 August 2009 13:58 |
|
Hi Mickael,
Michael Gebhart a écrit :
>
> Assuming a distributed system developed with SCA (S1). We have 5
> components (A, B, C, D, E).
>
> Now, another system is developed, also with SCA (S2). It requires
> functionality that is already implemented in S1, more precisely
> component A and B.
>
> What happens? The developer who develops S2 does not know about A and B.
> They are not provided as Webservice and are not registered within a
> service registry.
A and B are components.
If their services are not promoted, they cannot be used outside the
composite.
If they are promoted, then they can be used by any client.
The way this client will find these services is undefined (registry or
another solution).
>
> How does the developer find A and B? Should A and B be exposed as web
> service from the beginning and published into a service registry?
>
> Or are they exposed as web service only on demand? But in this case:
> How does the developer know about A and B?
That would be the best solution if you want to use existing products.
Another solution is to implement an SCA registry, which will distinguish
composite services from component services.
As Stéphane mentionned it, the SCOrWare project proposed a prototype of
semantic trader and registry to deal with this case.
>
> Next problem: A third system has to be developed, S3. It requires
> functionality that is part of S1, but not A, B, C, D or E.
If the feature is not exposed as a service, then you cannot know it.
Unless you developped the system (S1) yourself.
That's the basis of SOA: you can only know and rely on the interface
(and possibly on meta-data if you have a registry).
>
> The developer of S1 declares himself ready to comply with exposing the
> required functionality as a component F. This can be used by S1 and S3.
Exposing a feature as a component in SCA makes no sense.
You expose services (=> a component with at least one service that will
be promoted at the composite level).
>
> But there are other ways possible: F could also be part of S3 and S1
> uses this component as part of S3. Or should F be a completely new
> application? What is the right way to expose shared functionality?
One solution could be to make F a composite.
You may have one component F' in (S1), having the composite F as the
implementation, and F'' in (S3), having another component with the same
implementation F.
The usual solution will be to create a new component having the same
implementation.
In general, you do not share components in SCA. But you can share
interfaces and / or implementations. The goal of component types and SCA
Java annotations is to facilitate the reuse of implementations in SCA. A
component by itself is only "the configuration of an implementation"
(that's what is stated by the OSOA specification).
Eventually, the governance of SCA artifacts is not part of the SCA
specification. For the moment, you can only rely on the SOA governance
principles (meaning interface + meta-data).
Regards,
Vincent.
--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 91 72
|
|
|
| Re: Service term in SCA [message #479238 is a reply to message #468431] |
Mon, 10 August 2009 12:11 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
thanks for your answers.
Thus, in general it can be said that services in SCA do not have
anything in common with the services within an SOA unless they are
exposed as webservices.
Services within an SOA are governed by an SOA governance. This is not
the case for services within an SCA application.
Thus, SCA is more something like EJB++. Components with different
languages and different inerfaces. But only as webservice and part of
the SOA governance it is part of an entire SOA solution.
Best regards
Michael
|
|
|
| Re: Service term in SCA [message #479263 is a reply to message #479238] |
Mon, 10 August 2009 13:41 |
|
Hi,
Michael Gebhart a écrit :
> Hi,
>
> thanks for your answers.
>
> Thus, in general it can be said that services in SCA do not have
> anything in common with the services within an SOA unless they are
> exposed as webservices.
I would not say that.
Web services by default do not imply governance.
You can see web services only as technical services. You do not have to
use a registry when you create a web service. It can work without it.
Governance is part of best practices.
You can apply these best practices to SCA services too.
>
> Services within an SOA are governed by an SOA governance. This is not
> the case for services within an SCA application.
You can use SCA for your SOA. But that is not mandatory.
You can do SOA without SCA and use SCA without making SOA. There is a
small space frame for having both at the same time.
Regards,
Vincent.
>
> Thus, SCA is more something like EJB++. Components with different
> languages and different inerfaces. But only as webservice and part of
> the SOA governance it is part of an entire SOA solution.
>
> Best regards
>
> Michael
--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 91 72
|
|
|
| Re: Service term in SCA [message #575467 is a reply to message #468212] |
Wed, 05 August 2009 08:44 |
Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
Michael Gebhart a écrit :
> Hi,
>
> I have a problem with the term of service in SCA. What is meant with a
> service here? Is it a service in terms of a service that should be
> published within a service inventory (as for instance UDDI) that other
> interested parties can use it? Should these services be designed that
> they can be used from other parties too?
>
> Or is this service for internal use only? This would mean that it is
> simply an interface for a component?
>
> Best regards
>
> Michael
Hi Michael,
I think that your misunderstanding is prompted by the fact that SCA
wants to unify 2 visions of distributed systems: (a) the
architecture-based and (b) the service-oriented visions.
In vision (a), a distributed system is organized as an architecture
built as an assembly of components with well defined interfaces. In
vision (b), a distributed system is organized as a set of independent
services used by different clients. Moreover, the main idea behind the
term service is the possibility to re-use them (services must be
designed for that : autonomy, loose coupling, stateless,...) and to
aggregate them to construct other services. You can find more
information here [0] (page 5) and an interesting article about service
granularity here [1].
So, to answer your question, SCA services
- can be used by other interested parties : a service promoted at the
composite level with a web service binding can be used by non SCA clients,
- can be used to construct an assembly of components. In this case, the
service can or not (internal use only) be promoted outside the composite.
Regards,
Stephane Drapeau
Obeo
[0]:
http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
[1]:
http://www.ibm.com/developerworks/webservices/library/ws-soa -granularity/
|
|
|
| Re: Service term in SCA [message #575500 is a reply to message #468355] |
Wed, 05 August 2009 11:33 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
thanks for your answer. I try to formalize my question in a differnt way:
Assuming a distributed system developed with SCA (S1). We have 5
components (A, B, C, D, E).
Now, another system is developed, also with SCA (S2). It requires
functionality that is already implemented in S1, more precisely
component A and B.
What happens? The developer who develops S2 does not know about A and B.
They are not provided as Webservice and are not registered within a
service registry.
How does the developer find A and B? Should A and B be exposed as web
service from the beginning and published into a service registry?
Or are they exposed as web service only on demand? But in this case: How
does the developer know about A and B?
Next problem: A third system has to be developed, S3. It requires
functionality that is part of S1, but not A, B, C, D or E.
The developer of S1 declares himself ready to comply with exposing the
required functionality as a component F. This can be used by S1 and S3.
But there are other ways possible: F could also be part of S3 and S1
uses this component as part of S3. Or should F be a completely new
application? What is the right way to expose shared functionality?
Best regards
Michael
|
|
|
| Re: Service term in SCA [message #575528 is a reply to message #468390] |
Wed, 05 August 2009 12:14 |
Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
The SCA specifications don't address these problems.
If a developer wants to be aware of the services already developed and
how to re-use them, then, a service repository or something like that is
needed.
The SCOrWare project has developed a semantic trader [0] (page 65),
which, I think, can be an interesting solution. We can imagine using it
at development time or at runtime.
Stephane
[0]:
http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
Michael Gebhart a écrit :
> Hi,
>
> thanks for your answer. I try to formalize my question in a differnt way:
>
> Assuming a distributed system developed with SCA (S1). We have 5
> components (A, B, C, D, E).
>
> Now, another system is developed, also with SCA (S2). It requires
> functionality that is already implemented in S1, more precisely
> component A and B.
>
> What happens? The developer who develops S2 does not know about A and B.
> They are not provided as Webservice and are not registered within a
> service registry.
>
> How does the developer find A and B? Should A and B be exposed as web
> service from the beginning and published into a service registry?
>
> Or are they exposed as web service only on demand? But in this case: How
> does the developer know about A and B?
>
>
> Next problem: A third system has to be developed, S3. It requires
> functionality that is part of S1, but not A, B, C, D or E.
>
> The developer of S1 declares himself ready to comply with exposing the
> required functionality as a component F. This can be used by S1 and S3.
>
> But there are other ways possible: F could also be part of S3 and S1
> uses this component as part of S3. Or should F be a completely new
> application? What is the right way to expose shared functionality?
>
>
> Best regards
>
> Michael
>
|
|
|
| Re: Service term in SCA [message #575544 is a reply to message #468397] |
Wed, 05 August 2009 12:19 |
Stephane Drapeau
Messages: 199
Registered: July 2009 |
Senior Member |
|
|
You can easily add SAWSDL annotations on composite files with the
Composite Designer [0].
Stephane
[0]: http://wiki.eclipse.org/STP/SCA_Project/Ontology
Stephane Drapeau a écrit :
> The SCA specifications don't address these problems.
> If a developer wants to be aware of the services already developed and
> how to re-use them, then, a service repository or something like that is
> needed.
> The SCOrWare project has developed a semantic trader [0] (page 65),
> which, I think, can be an interesting solution. We can imagine using it
> at development time or at runtime.
>
> Stephane
>
> [0]:
> http://www.scorware.org/projects/rsc/deliverables/SCOrWare-L 1-Specifications-V2-0-20090414_pdf?action=download&nodec orator
>
>
>
> Michael Gebhart a écrit :
>> Hi,
>>
>> thanks for your answer. I try to formalize my question in a differnt way:
>>
>> Assuming a distributed system developed with SCA (S1). We have 5
>> components (A, B, C, D, E).
>>
>> Now, another system is developed, also with SCA (S2). It requires
>> functionality that is already implemented in S1, more precisely
>> component A and B.
>>
>> What happens? The developer who develops S2 does not know about A and
>> B. They are not provided as Webservice and are not registered within
>> a service registry.
>>
>> How does the developer find A and B? Should A and B be exposed as web
>> service from the beginning and published into a service registry?
>>
>> Or are they exposed as web service only on demand? But in this case:
>> How does the developer know about A and B?
>>
>>
>> Next problem: A third system has to be developed, S3. It requires
>> functionality that is part of S1, but not A, B, C, D or E.
>>
>> The developer of S1 declares himself ready to comply with exposing the
>> required functionality as a component F. This can be used by S1 and S3.
>>
>> But there are other ways possible: F could also be part of S3 and S1
>> uses this component as part of S3. Or should F be a completely new
>> application? What is the right way to expose shared functionality?
>>
>>
>> Best regards
>>
>> Michael
>>
|
|
|
| Re: Service term in SCA [message #575568 is a reply to message #468390] |
Wed, 05 August 2009 13:58 |
|
Hi Mickael,
Michael Gebhart a écrit :
>
> Assuming a distributed system developed with SCA (S1). We have 5
> components (A, B, C, D, E).
>
> Now, another system is developed, also with SCA (S2). It requires
> functionality that is already implemented in S1, more precisely
> component A and B.
>
> What happens? The developer who develops S2 does not know about A and B.
> They are not provided as Webservice and are not registered within a
> service registry.
A and B are components.
If their services are not promoted, they cannot be used outside the
composite.
If they are promoted, then they can be used by any client.
The way this client will find these services is undefined (registry or
another solution).
>
> How does the developer find A and B? Should A and B be exposed as web
> service from the beginning and published into a service registry?
>
> Or are they exposed as web service only on demand? But in this case:
> How does the developer know about A and B?
That would be the best solution if you want to use existing products.
Another solution is to implement an SCA registry, which will distinguish
composite services from component services.
As Stéphane mentionned it, the SCOrWare project proposed a prototype of
semantic trader and registry to deal with this case.
>
> Next problem: A third system has to be developed, S3. It requires
> functionality that is part of S1, but not A, B, C, D or E.
If the feature is not exposed as a service, then you cannot know it.
Unless you developped the system (S1) yourself.
That's the basis of SOA: you can only know and rely on the interface
(and possibly on meta-data if you have a registry).
>
> The developer of S1 declares himself ready to comply with exposing the
> required functionality as a component F. This can be used by S1 and S3.
Exposing a feature as a component in SCA makes no sense.
You expose services (=> a component with at least one service that will
be promoted at the composite level).
>
> But there are other ways possible: F could also be part of S3 and S1
> uses this component as part of S3. Or should F be a completely new
> application? What is the right way to expose shared functionality?
One solution could be to make F a composite.
You may have one component F' in (S1), having the composite F as the
implementation, and F'' in (S3), having another component with the same
implementation F.
The usual solution will be to create a new component having the same
implementation.
In general, you do not share components in SCA. But you can share
interfaces and / or implementations. The goal of component types and SCA
Java annotations is to facilitate the reuse of implementations in SCA. A
component by itself is only "the configuration of an implementation"
(that's what is stated by the OSOA specification).
Eventually, the governance of SCA artifacts is not part of the SCA
specification. For the moment, you can only rely on the SOA governance
principles (meaning interface + meta-data).
Regards,
Vincent.
--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 91 72
|
|
|
| Re: Service term in SCA [message #575723 is a reply to message #468431] |
Mon, 10 August 2009 12:11 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
thanks for your answers.
Thus, in general it can be said that services in SCA do not have
anything in common with the services within an SOA unless they are
exposed as webservices.
Services within an SOA are governed by an SOA governance. This is not
the case for services within an SCA application.
Thus, SCA is more something like EJB++. Components with different
languages and different inerfaces. But only as webservice and part of
the SOA governance it is part of an entire SOA solution.
Best regards
Michael
|
|
|
| Re: Service term in SCA [message #575743 is a reply to message #479238] |
Mon, 10 August 2009 13:41 |
|
Hi,
Michael Gebhart a écrit :
> Hi,
>
> thanks for your answers.
>
> Thus, in general it can be said that services in SCA do not have
> anything in common with the services within an SOA unless they are
> exposed as webservices.
I would not say that.
Web services by default do not imply governance.
You can see web services only as technical services. You do not have to
use a registry when you create a web service. It can work without it.
Governance is part of best practices.
You can apply these best practices to SCA services too.
>
> Services within an SOA are governed by an SOA governance. This is not
> the case for services within an SCA application.
You can use SCA for your SOA. But that is not mandatory.
You can do SOA without SCA and use SCA without making SOA. There is a
small space frame for having both at the same time.
Regards,
Vincent.
>
> Thus, SCA is more something like EJB++. Components with different
> languages and different inerfaces. But only as webservice and part of
> the SOA governance it is part of an entire SOA solution.
>
> Best regards
>
> Michael
--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 91 72
|
|
|
Goto Forum:
Current Time: Tue Apr 23 12:11:21 GMT 2024
Powered by FUDForum. Page generated in 0.04602 seconds |
] 
Search
Help
Register
Login
Home
