|
|
|
|
|
|
|
|
|
|
|
|
|
Simon Laws wrote:Hi
Good questions.
1. Is SCA the same as SOA? If not, what exactly the differentiating factors?
For me they are not one and the same. SOA describes architectural patterns for building distributed systems from services. SCA describes and XML based programming model for describing components, the services they provide and how can be connected to other components. It does this independently of technology by allowing you to build components using your favourite language and connected them using your favourite binding technology. It just so happens that using SCA you can build systems that exploit the same architectural patterns that SOA recommends.
2. What is the core concept behind SCA?
The core concept is the SCA assembly model. An XML model that describes components and the way that they are connected. A quick example of this XML is probably the easiest way to describe it. Take the Payment composite from the book example;
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://tuscanyscatours.com/"
name="payment">
<component name="Payment">
<implementation.java class="com.tuscanyscatours.payment.impl.PaymentImpl" />
<service name="Payment">
<binding.ws uri="http://localhost:8081/Payment" />
<binding.sca />
</service>
<reference name="customerRegistry" target="CustomerRegistry" />
<reference name="creditCardPayment">
<binding.ws uri="http://localhost:8082/CreditCardPayment" />
</reference>
<reference name="emailGateway" target="EmailGateway" />
<property name="transactionFee">0.02</property>
</component>
<component name="CustomerRegistry">
<implementation.java class="com.tuscanyscatours.customer.impl.CustomerRegistryImpl" />
</component>
<component name="EmailGateway">
<implementation.java class="com.tuscanyscatours.emailgateway.impl.EmailGatewayImpl" />
</component>
</composite>
We've defined three components "Payment", "CustomerRegistry", "EmailGateway". Note that the components are implemented with Java classes using implementation.java in this case. This can be replaced with other implementation types, for example,
<component name="Payment">
<implementation.spring location="Payment-context.xml"/>
or
<component name="Payment">
<t:implementation.script script="payment/PaymentImpl.py"/>
or
<component name="Payment">
<implementation.bpel process="pp:Payment"/>
etc.
Note that the Payment component described service and references. Services are what other components connect to. References are how you connect to other components.
We use binding.ws in the service and in the "creditCardPayment" reference. This is saying that you want web services for the service and for that reference. If you want to use other protocols instead you just change these binding elements.
The property element is a way for configuring the component.
Regardless of which implementation type you use this approach to defining services and references and properties remains constant and hence we've disconnected the way that you build the business logic of a component from the way that components are joined together.
So you take this XML and fire it into Tuscany, along with the required resources such as the Java classes being used to implement the components, and Tuscany creates the components and makes the services available for you without you having to code web services apis (in this case).
3. Looks like the definition/introduction on SCA in the manning website (on your book) is resembling Cloud Computing. Is there any relationship between these two?
We've certainly started to look at making that the case. Imagine you want to build a cloud application. E.g. multiple components that are going to interact out there on some virtual infrastructure. Wouldn't it be good if there was some abstract description of the application that you could provide to the cloud infrastructure that tells is what to run. Sounds a bit like the assembly model. We've had a go at running Tuscany apps on various cloud infrastructures. I can point you at more info it you want to look in more detail.
4. Is there any speciality or meaning in the name being chosen as Tuscany?
It was chose before my time but I'm guessing that someone liked Italy so they found a place name with "sca" in the middle of it.
Simon
), so one can implement it in the .NET platform with C#? Is there any documentation that can be helpful in this regard.
Opher Etzion wrote:Hello Vladimir. The direction we are using in the book is exactly model-driven approach, by which the "event processing network" that contains the flow of events into the different agents that ,for example, detect patterns, is defined in the model level, and this model should be directly compilable into execution. What you mention - static analysis to detect possible deadlocks may be a specific application; there are, of course, a lot more application types that can use such an approach.
cheers,
Opher
. Is your EPN in the phase of conception or real tool?