Jean-Sebastien Delfino ha scritto:
OK I'm starting to understand. That looks like a pretty useful
component to have!
One more question, after which I may make some suggestions.
What does the WSDL portType describing your Web Service look like?
Like that?
<definitions...>
<types>
<schema ...>
<element name="computeTask">
<complexType>
<sequence>
<element name="job" type="xs:base64Binary"/>
</sequence>
</complexType>
</element>
<element name="computeTaskResponse">
<complexType>
<sequence>
<element name="return" type="xs:base64Binary"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name="computeTaskRequest">
<part name="parameters" element="computeTask"/>
</message>
<message name="computeTaskResponse">
<part name="parameters" element="computeTaskResponse"/>
</message>
<portType name="WorkerServicePortType">
<operation name="computeTask">
<input message="computeTaskRequest"/>
<output message="computeTaskResponse"/>
</operation>
</portType>
</definitions>
I guessed the above as you said you were flowing base64 encoded bytes,
and I didn't know what your WorkerManager interface looked like so
assumed it was like your WorkerService.
Or something else?
Hi,
I don't know how it's my WSDL, because it's automatically generated by
Tuscany Runtime whereas I use binding-sca-axis2 module, but the
WorkerService and the WorkerManager have different interfaces. By now
jobs are sent by my custom binding which uses xstream, so a lot of xml
serialization, but it's going to change due performance problems
inherent to xml. The WorkerManager has the task to control a group of
worker components in a node. So its business intefaces looks like that:
import org.apache.tuscany.sca.core.context.CallableReferenceImpl;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface WorkerManager {
CallableReferenceImpl<WorkerService> addWorker();
boolean removeWorker(String workerName);
boolean removeWorkers(int k);
boolean removeAllWorkers();
double getNodeLoad();
int activeWorkers();
void start();
}
You can add one or more components at runtime with the composite updater
ad then give away to the WorkpoolManager its CallableReference (i use
CallableReferenceImpl because my Tuscany runtime is not current patched
svn, but an old one). I'll show you a common use case:
Use case 1: The WorkpoolManager's polls different WorkerManagers in a
SCA domain, then it collects all nodes load with getNodeLoad(), if these
loads break some rule in the WorkpoolManager's engine. For example if
the system is "run down", then the WorkpoolManager could add a new
worker by selecting a node, invoking its WorkerManager and adding a new
Worker Component at runtime on that node. After that, the
WorkpoolManager receives from that node's WorkerManager, a
CallableReference and it sends that reference to the WorkpoolService
which has the following interface:
@Remotable
public interface WorkpoolService {
@OneWay
void submit(Job i);
double getServiceTime();
@OneWay
void PostWorkerName(String referenceName);
@OneWay
void PostWorkerReference(CallableReferenceImpl<WorkerService> worker);
void start();
@OneWay
void handleResult(Job j, boolean reuse,
CallableReferenceImpl<WorkerService> worker);
}
In this case it uses a PostWorkerReference. In this interface you also
notice handleResult and PostWorkerName, this are my two hacks because i
wasn't able to inject dynamically a new component reference throught the
WorkpoolManager, so I use PostWorkerReference instead of the
PostWorkerName and handleResult instead of standard Tuscany Callbacks.
That's all hope it helps.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
