Simon Laws ha scritto:
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.
The code needs some cleanups, but until next year i'll not be able to do
such cleanups, because i'm quite busy
in testing. So I need more time, and JIRA1907 needs some changes in your
current activator composite and builder. I'll use Xmas holiday or a part of
to update JIRA1863 and JIRA1907 to your current rc-1.1. I don't want to
risk moving my code to something that's not well tested because i'm not
preparing for headaches :).
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.
For me it's ok..but remember that it needs some fixes.
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.
the load detection is Linux based, you'll need an JNI extension for
other platforms like Win32 or Solaris that i'm going to provide you in
the future.
Now it's a function which reads /proc/loadavg and it does some checks.
2/ When you need a new Worker component on a node use the domain services to
start a new composite there containing the component.
It works in a bit different way, the WorkerManager updates an existing
composite instead of creating a new one. This was done by modifing your
activator,
and your wirebuilder and using your composite api, copying part of that
code and adapting to a single component. The whole workpool composite,
from an external point of view could be seen as a single managed
component. However it still could be seen as a *hierarchical* composite
component where each new worker is ,if this in your opinion fits
better into SCA model.
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.
The solution here, is to use XML processor, to add a composite, isn't it?
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.
Yes. It will be useful for me having some advice on how to work with
callbacks between different composites.
Just some thoughts ;-)
Thoughts are food for mind :).
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
