On Dec 13, 2007 3:04 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
> 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]
>
> Hi Giorgio. As you know I think we should get this checked in as an
sca/demo (is that the right place?). Are you happy that 1907 and 1863 are in
a suitable state to do that. We don't have to include it in the build
necessarily but it would be good if we can check out the code and look at
it.
It would be interesting (to me at least ;-) to see how the domain could
handle some of the issues of deploying the new components for you. I'm
wondering if you could split the function of the WorkManager in two
1/ A component that you use that to determine information about the load of
the node. In fact we could reuse the WorkManager component/service as part
of the set of node management services.
2/ When you need a new Worker component on a node use the domain services to
start a new composite there containing the component. The composite could be
created on the fly. We need two features to make this work
A) addDeploymentComposite() which allows a composite to be added to an
existing contribution. Method is there in the domain but I haven't
implemented it yet.
B) a startComposite(compositeName, nodeName) that allows a composite to be
targetted specifically at named node, i.e the node you have decided is not
heavily loaded. This you be trivial to add and I think it would be useful
anyhow.
Just some thoughts ;-)
Regards
Simon
