Component Model draft
Here is the long promised Component Model draft specification. As agreed at last meeting, I have the following outstanding issues to resolve: 1) There is no mechanism for a component to know its own EPR, or to know the system EPR. So, to do a reference resolution, there is some undocumented magic. 2) As discussed with Steve, the current system requires all resolutions to be done by the system EPR. This may be a problem for scalability. 3) There is no mapping between WS-I endpoint or service EPRs and their host components. Presumably this matching is done outside of our scope, but it is unknown at this point. 4) There may be some conflicts in the definition of the CDL and CMP namespaces. Steve suggested that the component model by a namespace extension to the CDL namespace. I am not sure I like that, but have found no better alternative yet. Please take a chance to read the document, and I will schedule a review with Dejan. Stuart
Stuart Schaefer wrote:
Here is the long promised Component Model draft specification. As agreed at last meeting, I have the following outstanding issues to resolve:
Thanks, I will look at it more on thursday. In the meantime, I have not forgotten that I have a more complete draft of the deployment API to send out before wednesdays call. I am busy doing it, including all the changes to WSDL that WS-RF implies. -steve
This is the version of the deployment API I'd like to discuss on wednesday. It is not ready yet, because the WSDL is still unfinished. Note the lack of faults in the typedefs, and the new WSDL that uses all these types is still to be done. I need to build up a system that processes WSRF to make sure that the API is actually valid. But the text of the deployment API is what I intend to do, so that's what we can review. Notice the limited file upload mechanism I've implemented, which leads to a use pattern of system=portal.create(options) length=system.addFile("nap:chemical+brothers","application/binary",databaseRpm); assert(length==databaseRpm.length()); system.init(jsdl,deploymentDescriptor); system.run(); That is, you dont pass up the JSDL or deployment descriptor at create time, only when you initialise it. And you can add files before you initialise it, so their URIs are resolvable during initialisation. For this to work we need to mandate that URIs of added files are resolved in deployment descriptor (and jsdl descriptor) processing before going out to the rest of the network; a small bit of XML parser configuration. To actually use the URIs in apps is another issue; I dont want to even think that actual running apps in their own processes have access to this uri->file mapping. We'll need a component that copies stuff from remote URIs to local filesystem (which, for this uploaded stuff, may be just a copy, not a download) I'm offline for the next 24 hours, but will speak to you all on Wednesday. -steve
Hi Steve, Is it worth utilizing WSDM MUWS spec in addition to WSRF/WSN? Thanks, ---- Hiro Kishimoto
-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Steve Loughran Sent: Tuesday, January 25, 2005 7:30 AM To: cddlm-wg@ggf.org Subject: [cddlm] Draft of deployment API
This is the version of the deployment API I'd like to discuss on wednesday. It is not ready yet, because the WSDL is still unfinished. Note the lack of faults in the typedefs, and the new WSDL that uses all these types is still to be done. I need to build up a system that processes WSRF to make sure that the API is actually valid.
But the text of the deployment API is what I intend to do, so that's what we can review. Notice the limited file upload mechanism I've implemented, which leads to a use pattern of
system=portal.create(options)
length=system.addFile("nap:chemical+brothers","application/binary",databaseRpm);
assert(length==databaseRpm.length()); system.init(jsdl,deploymentDescriptor); system.run();
That is, you dont pass up the JSDL or deployment descriptor at create time, only when you initialise it. And you can add files before you initialise it, so their URIs are resolvable during initialisation.
For this to work we need to mandate that URIs of added files are resolved in deployment descriptor (and jsdl descriptor) processing before going out to the rest of the network; a small bit of XML parser configuration.
To actually use the URIs in apps is another issue; I dont want to even think that actual running apps in their own processes have access to this uri->file mapping. We'll need a component that copies stuff from remote URIs to local filesystem (which, for this uploaded stuff, may be just a copy, not a download)
I'm offline for the next 24 hours, but will speak to you all on Wednesday.
-steve
Hiro Kishimoto wrote:
Hi Steve,
Is it worth utilizing WSDM MUWS spec in addition to WSRF/WSN?
Thanks, ---- Hiro Kishimoto
I've been trying hard to reduce dependencies on the specification. this iteration has gone from one known to work to one that will depend on early implementations of WSRF+WSN, such as GT4, the HP/Globus donation to Apache (Apollo & Hermes), or an equivalent. Even then we are now more dependent on changing specifications, instability of foundational things like WS-Addressing, and so it is that much harder from interoperable implementations. MOWS/MUWS adds more complexity. This does not mean that I am against writing manageable code, but think we can get away with it being implementation specific. For example, a Java implementation just needs to use the JMX APIs, and when a MUWS binding to JMX comes out, then it gets MUWS for free. Till then, we get SNMP amongst others. What opinions does anyone else have? -steve
participants (3)
-
Hiro Kishimoto -
Steve Loughran -
Stuart Schaefer