[news.eclipse.stp.sca-tools] Re: Service term in SCA

[Vincent Zurczak <vincent.zurczak@xxxxxxxxxxxxxxxxxx>]

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