Re: Can't generate a Java interface from a WSDL portType
Folks, I tend to agree with Simon, that the package name would rightly be derived from the target namespace of the wsdl:definitions/ containing the portType definition, since it's the port type that defines the interface. So +1 to the CXF interpretation. On the other hand, there is a JAX-WS TCK. Does it test this piece of function I wonder...? Yours, Mike. Simon Nash wrote: Scott Kurz wrote: Simon, The question is do we look at the definitions of the WSDL document defining the imported portType or the definitions of the document defining a WSDL service in terms of the imported portType (since the TNS of each are different). I haven't read all of JAX-WS either but agree that the CXF behavior makes more sense. If you consider the question which definitions? it seems you'd naturally pick the one in which the portType is actually DEFINED as opposed to merely IMPORTED From what I can see the WSDL spec doesn't say anything particular about the import behavior either. On the one hand this isn't too critical since, with either choice, we generate a just-as-legal @WebService(targetNamespace) into the Java to capture the original TNS. Doesn't this raise the same question? The @WebService annotation for the generated Java interface should have the targetNamespace of the portType. It seems an extremely reasonable assumption that this is the same targetNamespace of the portType (whatever that means) that will be used to derive the package name. I tried this with the Sun RI and was surprised that it took the targetNamespace for the @WebService annotation from the portType's wsdl:definitions, even though it took the targetNamespace for the package name from the service's wsdl:definitions. This inconsistency seems wrong to me. My conclusion is that CXF has got this right. On the other hand, JAX-WS could have been clearer on this... I agree. And this seems like a warning that in cases where the spec is ambiguous, we should not assume that we can use the Sun RI's behaviour to determine which interpretation is correct. Simon On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Scott Kurz wrote: Sebastien, I'm surprised the package names would be different. What is the namespace you're using that isn't mapping to the same package in each tool? Just curious... My app is an order processing app with the following: WSDL service namespace: http://sample/Order/Binding WSDL Order portType namespace: http://sample/Order The CXF tool generates interface sample.order.Order The JAXWS RI tool generates interface sample.order.binding.Order I gave the same WSDL file (containing the WSDL service) to both tools. One could argue that both are correct vs the JAX-WS spec as they generate a correct package name from the namespace of 'the' WSDL definition, but the funny thing is that they do not pick the same WSDL definition... JAXWS-RI picks the input definition given to the tool and CXF the definition that actually contains the portType... and the JAXWS spec doesn't seem to state which one should be picked (at least I couldn't find it). IMHO the CXF behavior is better, but I've not read all 150 pages of the JAX-WS spec so I may be missing something :) From section 2.2 of the JAX-WS spec: A wsdl:portType element is mapped to a Java interface in the package mapped from the wsdl:definitions element (see section 2.1 for a description of wsdl:definitions mapping). Section 2.1 says: A wsdl:definitions element and its associated targetNamespace attribute is mapped to a Java package. JAXB[10] (see appendix D) defines a standard mapping from a namespace URI to a Java package name. By default, this algorithm is used to map the value of a wsdl:definitions element's targetNamespace attribute to a Java package name. } Conformance (Definitions mapping): In the absence of customizations, the Java package name is mapped from the value of a wsdl:definitions element's targetNamespace attribute using the algorithm defined by JAXB[10]. So IMO the Java package name that's used to map the portType should be derived from the targetNamespace of the wsdl:definitions element. What was this targetNamespace? Simon
Re: Sun is asking for proof that users want Sun support for SCA, A call to arms!
Folks, I think that SCA is a significant advance in application development technologies which is directed to simplifying the building of agile and adaptable business systems. Organisations are already reaping benefits from using SCA - IBM customers in particular have been able to exploit an version of SCA in the WebSphere Process Server and in the WebSphere ESB products for a couple of years now. We also have customers who are excited about the latest SCA functionality that is found in the Tuscany project and which IBM has made available as part of the WebSphere 6.1 SOA Feature Pack. I talked about one of these customers (anonymously) at the recent OASIS Symposium in Santa Clara - the talk is now posted on the OSOA site here: http://www.osoa.org/download/attachments/250/Flexible_Agile_Composition_01.pdf I am sure that many more businesses will benefit as SCA implementations become available from a wider range of suppliers - TIBCO, Oracle, BEA and Rogue Wave all have products either available or in late beta stage. As far as Sun are concerned, I encourage them to provide support for SCA in their products. If they need to hear more about what users want - they could do well to listen to Steve Jones of CapGemini who was on that SCA Panel at JavaOne and who spoke eloquently about SCA as being of great value in unifying activities on the large projects that they undertake. It is curious in some ways that Sun saw value in building runtimes for composite applications and have pursued the JBI specification for about the same length of time as the OSOA collaboration of companies developed the SCA specifications. The hole in that approach is that JBI is really a specification for runtime builders (read vendors), providing little in the way of a model for building applications, which is what customers really care about. Sun would do well to recognise this and adopt SCA as the application layer which can sit above a JBI runtime. Interestingly, a couple of guys from Atos Origin gave a talk at JavaOne about their work on exactly this topic - “The Best Of Both Worlds with Java Business Integration and Service Component Architecture” presented by Jos Dirksen and Tijs Rademakers. To me, this showed the value and power of the combination. I think that the evidence is there that customers already see the benefits of SCA - and that interest is continuing to grow and should expand rapidly once there is a good range of runtimes and tools that support the SCA model across the industry. Whether Sun want to see this evidence is another matter, which I will leave them to think about. Yours, Mike. Jeff Anderson wrote: To everybody out there interested in seeing SCA being more widely adopted. Recently I posted a general overview of SCA coverage at JavaWorld last week in San Francisco. Which can be found at http://agileconsulting.blogspot.com/2008/05/highlights-of-sca-at-javaworld-2008.html I spoke briefly about the SCA panel that was attended by members of IBM, Sun SAP and MCd by David Chapelle. After the panel, I had the chance to briefly speak with Peter Walker of Sun Microsystems concerning Sun support for SCA. In his opinion, Sun will probably not support SCA, because in his mind there is no user demand. Peter has actually invited me to tell him more about what users want directly on my above-mentioned blog entry. I personally think that having Sun support SCA in a more active fashion, and incorporating it into the JavaEE world would do a lot to reduce the noise around fractures within the Java community (especially from Microsoft) and would be excellent for the Java platform in general. Is anybody else concerned with Sun's lack of support? Please provide your comments at http://agileconsulting.blogspot.com/2008/05/highlights-of-sca-at-javaworld-2008.html I will make sure to forward your comments over to Peter. Feel free to share any evidence of the real world adoption of SCA and the value that it has provided. Be generic when referring to specific clients or projects if you need to protect the innocent :-). It would be great if we can provide hard evidence to convince Sun that SCA is real, valuable, and worth considering. Of course, I will also share the results of this with the community.
Re: How do I expose my BPEL component as a webservice?
Dalys,
Can you post the contents of the following files, please:
- composite file
- BPEL process file
- WSDL file
The WSDL file is especially important here - it defines the interface that the BPEL process is using
and also any policies that may apply.
It appears as if there is a failure at the point where Tuscany processes your componentType file and
follows the interface.wsdl/ to the WSDL file. The error message is VERY unfriendly and we
must improve it, but it will be helpful to see what error is being caught.
Yours, Mike.
Dalys Sebastian wrote:
Hi,
I was missing the axis2-ws binding in the WEB-INF/lib. I added those libs and
verified
the dependencies with other working webapps and now the error has migrated to
the
following:
Any idea what's going wrong? (I don't get any errors if I omit binding.ws/
in the
componentType file.)
Caused by: java.lang.NullPointerException
at
org.apache.tuscany.sca.assembly.xml.PolicyAttachPointProcessor.resolvePolicies(PolicyAttachPointProcessor.java:243)
at
org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:310)
at
org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:59)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcess
orExtensionPoint.java:252)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
at
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:362)
at
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:311)
at
org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:340)
at
org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:57)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
at
org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:112)
at
org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:44)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:454)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348)
Thanks,
Dalys
--- Luciano Resende [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 10:37 PM, Dalys Sebastian
[EMAIL PROTECTED] wrote:
Hi everyone,
This may probably be a very basic question. But I had been trying for quite
sometime
and
could not find an example on it, so I thought I will post it.
How do I expose my component (BPEL implementation) as a webservice URI? Do I
modify
the
componentType file?
I tried modifying both the componentType and the composite file and introduced
binding.ws/ in both, but it does not seem to pick it up.
For e.g., my componentType file looks like:
componentType xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
service name=HelloService promote=BPELHelloWorldComponent
interface.wsdl
interface=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl#wsdl.interface(HelloPortType)
/
binding.ws/
/service
/componentType
I have deployed it as a webapp on Tomcat. And during startup, Tuscany throws a
warning
like:
WARNING: Element {http://www.osoa.org/xmlns/sca/1.0}binding.ws cannot be
processed.
([row,col,system-id]:
Looks like you are missing the axis-ws binding dependency jar in your
app. Could you please verify your dependencies ?
[27,9,file:/C:/apache-tomcat-5.5.25/webapps/sample-helloworld-bpel/WEB-INF/classes/helloworld.componentType])
What am I doing wrong?
Thanks,
Dalys
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Any update in BPEL implementation?
Ashwini Kumar Jeksani wrote: Hi, I am having problems in invoking a webservice from the BPEL. This line is printed in the console and nothing is happening beyond this : [java] Invoking a partner operation: approveDataLoad Could anyone tellme if there is any update done on the BPEL implementation in tuscany and share the latest code if any as I am unable to download the nightly-builds. I would be thankful for any help in this regard. Thanks Regards, Ashwini Kumar Jeksani CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** Ashwini, I'll aim to help you - I am travelling and at JavaOne this week. My main talk is today (yes, on SCA!), but I hope that I will be able to devote more time to BPEL / Tuscany tomorrow. As far as I know, the latest code is there in SVN. I have a load of updates on my system related to introspecting the BPEL process to generate the componentType, but these are not yet working to my satisfaction and I haven't committed them. Yours, Mike.
Re: Reg: Asynchronous Webservice in BPEL
Ashwini Kumar Jeksani wrote:
Hi,
I'm trying to create a BPEL for asynchronous web service call. A snippet of it
is shown below:
!-Receive request from client --
receive createInstance=yes operation=initiate partnerLink=ApprovalProcessClient
portType=ns1:approvalProcessPT variable=approvalProcessRequestMessage/
!-Asynchronous Web Service Invoke --
invoke inputVariable=asyncApprovalRequest operation=submitForApproval
partnerLink=AsyncApprovalPartner portType=ns2:asyncApprovalServicePT
correlations
correlation initiate=yes pattern=request set=CS1/
/correlations
/invoke
!-Receive Response from Asynchronous Web Service invoked above --
receive operation=onResult partnerLink= AsyncApprovalPartner
portType=ns1:asyncApprovalCallbackPT variable=asyncApprovalResponse
correlations
correlation initiate=no set=CS1/
/correlations
/receive
The first receive in the above BPEL snippet is called by a client and therefore
I have declared it as a 'service' in componentType file.
The invoke is for invoking an asynchronous web service operation. The portType
of that I have declared as 'reference' in the componentType file.
The second receive in the above BPEL snippet acts as a callback to receive
response from an asynchronous web service. Where and How do I specify that this
is a callback? Is there way of specifying callbacks in componentType file.?
Thanks Regards
Ashwini Kumar Jeksani
Ashwini,
** WARNING - Long Post **
You're certainly going in the right direction here.
One way of specifying that a callback interface is in use is to declare
it in the SCDL files - in particular in the componentType file, using
something like this:
interface.java interface=services.invoicing.ComputePrice
callbackInterface=services.invoicing.InvoiceCallback/
This isn't the only way of specifying the callback, at least for Java
interfaces, since it is possible to use annotations within the interface
files, such as:
@Remotable
@Callback(MyServiceCallback.class)
public interface MyService {
@OneWay
void someMethod(String arg);
}
...and...
@Remotable
public interface MyServiceCallback {
void receiveResult(String result);
}
Note the @Callback annotation in the forward call interface, which
points at the callback interface.
However, there is nothing like this available in WSDL.
Instead, a WSDL file can contain multiple service definitions (ie
PortTypes) - and so a single WSDL can hold both the forward and callback
interfaces, which might look something like this:
wsdl:portType name=MyService
wsdl:operation name=someMethod
wsdl:input message=tns:someMethodRequest
name=someMethodRequest/
/wsdl:operation
/wsdl:portType
wsdl:portType name=MyServiceCallback
wsdl:operation name=receiveResult
wsdl:input message=tns:receiveResultRequest
name=receiveResultRequest/
wsdl:output message=tns:receiveResultResponse
name=receiveResultResponse/
/wsdl:operation
/wsdl:portType
In the SCDL which references a WSDL like this, in the component type and
in any relevant composite file, then it would look like this:
interface.wsdl
interface=http://simplecallback#wsdl.interface(MyService)
callbackInterface=http://simplecallback#wsdl.interface(MyServiceCallback)
/
When you set up a component which uses Web services the SCDL will look
something like this:
component name=MyServiceComponent
implementation.java class=simplecallback.MyServiceImpl /
service name=MyService
interface.wsdl
interface=http://simplecallback#wsdl.interface(MyService)
callbackInterface=http://simplecallback#wsdl.interface(MyServiceCallback)/
binding.ws
wsdlElement=http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort)/
callback
binding.ws
wsdlElement=http://simplecallback#wsdl.port(MyServiceCallbackSoapService/MyServiceCallbackSoapPort)/
/callback
/service
/component
Excuse the formatting - it does not fit well into the width limits.
Of course, the WSDL that you produce will also have to have the BPEL
PartnerLinkType elements pointing to the appropriate PortType elements.
I think that's it...
...you can see an example of this in the simple-callback-ws sample in
Tuscany.
BTW, what I am working on right now is the code to eliminate the need to
build the componentType file. The BPELDocumentProcessor code is bing
modified to read the BPEL process file and also to follow the links to
the WSDL files and to resolve the PartnerLink - PartnerLinkType -
PortType chains. This will result in the generation of the component
type interface definition as above, with a reference to the PortType for
forward and callback interfaces.
I should post some code in the next couple of days.
Yours, Mike.
Re: wsdl reference question
Abraham Washington wrote:
hi all, i have a service that has a reference to another service.� so,
in my impl class there's a setter method for the reference.�� when the
app is deployed, the wsdl generates the setter method operation, thus
making it available to be invoked (not a good thing).�
is there a way around this ?
thx abe
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hi Abe,
Can you explain what your app is doing in some more detail - maybe post
some code and the composite file?
If you have declared a reference in your code, with a setter method,
then I would expect the setter method to get called at runtime with the
reference proxy for the target service that you configure in your
composite file.
For the setter method to get included in the WSDL generated for the
service offered by the component, then:
a) presumably you are not marking the service offered by the
implementation code, so that the defaulting process is happening
- you do this by using the @Service annotation
b) also, I suspect that your class does not say something like
public fooClass implements barInterface {
...
}
- since the default service generation will look at the barInterface to
generate the WSDL for the service. If there is no implements clause
then the SCA code has little to go on as to which methods should be
included. In this case, as the SCA Java Client Implementation
specification says:
If none of the implemented interfaces is remotable, then by default the
implementation offers a single service whose type is the implementation
class.
I recommend that you consider using one of the above techniques to
control which class methods are used for the operations of the Service
interface.
Yours, Mike.
Re: What's next for SCA BPEL Integration
Luciano Resende wrote: Now that we are making more progress with the SCA BPEL integration and have figured out how to make References to work, let's discuss what could be the next steps on this area. Below are couple examples of what we could do next - WS-BPEL Process Introspection : Currently we are requiring SCA componentType files, we could introspect the BPEL process file to generate the component type information from it. - Integrate BEPL with the store scenario tutorial : We could add a OrderProcessing step to the store checkout, and illustrate a more real integration scenario. Other then these, we could review the SCA_ClientAndImplementationModelFor BPEL and identify other areas that we might need enhancements. Scenarios / Samples / Demos are always welcome too. Or if you have other suggestions, feel free to jump to the discussion. BTW: Copying the ODE list in case they want to jump and help, or in case they have other ideas. Luciano, WS_BPEL Process introspection is top of my list. Having to write componentType side files is a miserable business, particularly when all the information you need is sitting there in the BPEL Process XML. The Spring implementation is a good model - the Spring application context is ripped through to produce the componentType and so side file is ever needed. A good BPEL sample is called for. One based on some order process seems good to me. It should also involve the BPEL process making asynchronous calls to back end services, which means stretching the support on references to include callbacks. We should consider integrating with the tutorial after building a good standalone BPEL sample. Yours, Mike.
Re: Referencing CONVERSATION-scoped component from COMPOSITE-scoped
Ivan Dubrov wrote: Hi, Is that possible to refer to the CONVERSATION-scoped component from COMPOSITE-scoped? What I want to achieve, is to make singleton component (COMPOSITE-scoped) retrieve some session data (which I want to model as a CONVERSATION-scoped component) during the request processing. Ivan, Yes, this should work fine. I assume that your conversation scoped component has a conversational interface of some kind? If this is the case, then when the composite scoped component calls it, a new conversation will be started with the comversation scoped component and the composite scoped component can continue to use this until the conversation session is explicitly ended (eg by calling an @EndsConversation method.) Yours, Mike.
Re: Should we move to SDO 1.1-incubating version for SCA Java?
Raymond Feng wrote: Hi, Now the SDO 1.1-incubating has been released. Should we adjust the pom.xml in SCA Java to reference this release? ATM, we have SDO 1.0-incubating-SNAPSHOT in trunk. And SCA projects either reference SDO 1.0-incubating or 1.0-incubating-SNAPSHOT. I think it's better to have SCA depends on a released SDO version consistently across the modules. What do you think? Thanks, Raymond I think we should move up to the released version of SDO in trunk, so that this is the basis of our next release. So +1. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: State of BPEL implementation type?
Luciano Resende wrote: Thanks for your interest Juergen. I was very busy with SCA 1.2 release, so I haven't worked on this on the last couple weeks. I have local changes that can make the reference invocation, but looks like there are still some issues with the ODE integration and I keep getting erros that ODE cannot see the response (this is probably related to the changes not being committed by the transaction). Once I can get this working, at least not breaking the service support, I can get this committed and the basic reference support will be ready. On Wed, Apr 16, 2008 at 2:18 AM, [EMAIL PROTECTED] wrote: Luciano, I'd like to help on the BPEL implementation. How can I get involved with building a new version of the BPEL implementation with additional function? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release schedule
Stanislaw Findeisen wrote: What is the release schedule for Tuscany projects? In particular, when do you plan to release the next SDO Java implementation? Thanks! STF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Stanislaw, SCA 1.2 is also imminent - folks are working through some final bugs in the release candidate code Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSD schemas on osoa.org is broken
Joshua, I'll take a look at this. Yours, Mike. Joshua Jackson wrote: * ws-policy.xsd is now located at http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd * ws-addr.xsd is now located at http://www.w3.org/2005/08/addressing/ws-addr.xsd On 3/18/08, Joshua Jackson [EMAIL PROTECTED] wrote: Dear all, When I refer http://www.osoa.org/xmlns/sca/1.0/sca.xsd from my .composite files, it isn't able to download other schemas it depends on because the files is not there such as: * Inside http://www.osoa.org/xmlns/sca/1.0/sca-policy.xsd: the file http://schemas.xmlsoap.org/ws/2004/09/ws-policy.xsd is not there * Inside http://www.osoa.org/xmlns/sca/1.0/sca-binding-webservice.xsd the file http://www.w3.org/2004/12/addressing/ws-addr.xsd is not there - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSD schemas on osoa.org is broken
Joshua Jackson wrote: * ws-policy.xsd is now located at http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd * ws-addr.xsd is now located at http://www.w3.org/2005/08/addressing/ws-addr.xsd On 3/18/08, Joshua Jackson [EMAIL PROTECTED] wrote: Dear all, When I refer http://www.osoa.org/xmlns/sca/1.0/sca.xsd from my .composite files, it isn't able to download other schemas it depends on because the files is not there such as: * Inside http://www.osoa.org/xmlns/sca/1.0/sca-policy.xsd: the file http://schemas.xmlsoap.org/ws/2004/09/ws-policy.xsd is not there * Inside http://www.osoa.org/xmlns/sca/1.0/sca-binding-webservice.xsd the file http://www.w3.org/2004/12/addressing/ws-addr.xsd is not there Joshua, These files are fixed now. The problems had been spotted in the ongoing specification work at OASIS, but the fixes had not been put back into the online versions of the XSDs on www.osoa.org Thanks for reporting the problem. Hope it all works for you now. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Framework - Move the Spring Implementation up to Version 2.5 of the Spring Framework?
Folks, Are users of the Spring Implementation ready for us to move up to use the 2.5 version of the Spring Framework? Please let us know. Yours, Mike. Kapish Aggarwal wrote: Just a quick general question, are there plans to move the core-spring and implementation-spring modules to utilize the 2.5 Spring Framework? Kapish Aggarwal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build process fails on german system
Hmm, this looks like one of the those flaws in Java exceptions - there
is no way of having something like a number to uniquely identify an
exception beyond its class - using strings is a bad idea, for exactly
this issue with language conversions.
This has led to the message string being used to identify sub-cases for
exception types, with nasty consequences as found here.
I suppose the pure way of doing it would be for there to be a subclass
of SecurityException that deals with the case of not being able to find
a LoginConfiguration. But I can understand that it quickly gets tedious
to create ever more new exception classes. So people don't.
Yours, Mike.
[EMAIL PROTECTED] wrote:
Hi,
Could you please let me know what was the exception you had to modify ?
Of course. Here's the diff, the file is in
java\sca\samples\calculator-implementation-policies\src\test\java\calculator\
Index: CalculatorTestCase.java
===
--- CalculatorTestCase.java (revision 629059)
+++ CalculatorTestCase.java (working copy)
@@ -38,7 +38,7 @@
try {
Configuration secConf = Configuration.getConfiguration();
} catch ( java.lang.SecurityException e ) {
-if ( e.getMessage().equals(Unable to locate a login
configuration) ) {
+if ( e.getMessage().equals(Anmeldekonfiguration kann nicht gefunden
werden.) ) {
System.setProperty(java.security.auth.login.config,
target/classes/CalculatorJass.config);
} else {
throw e;
Cheers,
Jürgen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spring] Does the Spring support provide capability described in the spec?
Kevin, Comments inline Kevin Williams wrote: Does the current Spring support provide the basic capabilities outlined in the specification? The basic function boils down to these 4 items: 1. Spring Applications Contexts may be used as implementations for SCA composite components Yes, this is supported 2. A component that uses Spring for an implementation can wire services and references without introducing SCA-specific metadata into the Spring configuration Yes, this is supported (there are tests for this in the code) 3. Explicit references to SCA services may be made within a Spring application context by use of the three elements provided by Spring SCA namespace support Yes, supported, with tests. 4. Policy enforcement occurs in the SCA runtime and does not enter into the Spring space Haven't looked at this at all yet. Not saying that it will not work, although the transactions stuff will almost certainly require integration work. I suppose security and other interaction intents that apply to the wires should work without any special coding, since this is done in the proxies that are passed to the Spring Beans. I took a quick look at the related itests and they seem to exercise 1-3. Thanks in advance for any help. --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Tuscany?
Joshua, Let me see if I can help explain some: Joshua Jackson wrote: Thanks for the article. I kind of get idea now. This is what I get from it: SCA is a kind of glue code for glueing pool of apps to be used by another apps. So our new apps will connect to SCA and SCA will connect to these pool of apps. CMIIW. Yes, SCA is at one level a way of connecting together sets of components to build up your overall application. One of the great things is that you don't have to code any information about what is connected to what into your code. This is applied as configuration data - and so it allows the data to be changed without changing the code - and it allows the code to be reused in different configurations. I don't quite understand. People out there compares SCA with JBI, which is an ESB. :( And that's an insight that I get from those articles you gave me too. JBI is largely a way of putting a runtime together - where the runtime involves components written using different technologies (eg BPEL and Java). SCA is a way of putting applications together - where there are potentially components written in different technologies and connected by different technologies. It happens that you could envisage running SCA applications on a JBI runtime - ie JBI can provide the sort of runtime that SCA applications can use. HOWEVER, SCA does not depend on JBI at all - Tuscany, for example, does not use JBI at all. Further - SCA can describe applications that aren't written in Java and don't use a Java based runtime either (eg there is a C++ runtime in Tuscany that can run components written in C++, Ruby and other scripting languages). One way to look at SCA is that it CAN be used as a programming model for ESBs. SCA describes the components that run on the ESB and their connectivity. You can have components that are message transformations or the selection of a target service based on some rule, for example. These are the sorts of things that ESBs do. That doesn't mean that SCA is an ESB - just that it can be used to build applications that run on an ESB. Is Tuscany an ESB? Well, it could be ;-) - a funny half-answer. I can do some of the things that an ESB does. But ESBs usually have specialized component types that do things like message mapping - Tuscany only has some of these today. On the other hand, anyone can write new component types for SCA, so that anything needed could be added to SCA. One other point about SCA is that it is about distributed systems - most ESBs are not like that. In other words, for SCA, different components can run on different nodes in a network. Is there anything I need to know in order for Tuscany to connect to AS400 ? You need to know which communication protocol(s) you can use to talk with the AS/400 - plus the appropriate addresses of endpoints relating to the AS/400. So, maybe you're using JMS over MQSeries, or Web services, or . Thanks in advance Yours, Mike Edwards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA Webinars running in the Week of December 10th
Folks, OASIS is organising a series of free webinars on SCA. Here is the announcement from OASIS: - Open CSA hosts five webinars on the role of SCA in SOA Beginning 10 Dec, the OASIS Open CSA Member Section will present five webinars on the Service Component Architecture (SCA) and its role in SOA. SCA encompasses a family of royalty-free specifications based on the idea that business function is provided as a series of services, which can be assembled together to create solutions that serve a particular business need. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA compositions. The webinars are free, but registration is required. http://www.oasis-open.org/events/webinars/sca-2007.php - All the webinars are at 15:00 UK / 10:00 Eastern / 07:00 Pacific: SCA (Service Component Architecture) Overview Monday, 10 December, 2007 Reserve your Webinar seat now at: https://www.gotomeeting.com/register/651591088 SCA Policy Framework Tutorial Tuesday, 11 December, 2007 Reserve your Webinar seat now at: https://www.gotomeeting.com/register/318244138 SCA Assembly Model Wednesday, 12 December, 2007 Reserve your Webinar seat now at: https://www.gotomeeting.com/register/230174827 SCA for C++, C and COBOL Thursday, 13 December, 2007 Reserve your Webinar seat now at: https://www.gotomeeting.com/register/151160612 OASIS Service Component Architecture / BPEL (SCA-BPEL) Overview Friday, 14 December, 2007 Reserve your Webinar seat now at: https://www1.gotomeeting.com/register/209375873 Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA: OSOA Compliant Implementation?
Barb, (Speaking as one of the OSOA SCA Spec Authors) The OSOA SCA spec terms do talk about compliant implementations - but this is a piece of legalese that has no force, since the specifications themselves nowhere define what compliance is. The OSOA SCA specs in fact deliberately left things loose in terms of compliance. Now that the SCA specs are being taken forward for standardization in OASIS, then compliance and test suites are part of the work plan. However, this is an item that will complete in the future. Regarding Tuscany, it is intended to faithfully implement the functions described in the OSOA SCA 1.0 specifications. It isn't complete yet, but the Tuscany team are working hard to implement all the functions described in the specifications. There are also pieces of Tuscany that (legitimately) go beyond the specifications, such as supporting useful and interesting implementation types and binding types that are not currently specified. Yours, Mike. Chair, OSOA SCA Assembly working group. Barb Cochrane wrote: I have a quick question I hope one of the Apache team can help me with: is Tuscany's SCA 1.0 API a compliant implementation of OSOA's Service Component Architecture Specification? I'm asking because of the OSOA SCA Spec license terms. Thanks in advance! Cheers, Barb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What happened to mustSupply?
Folks, It's fixed now - the online sca-core.xsd matches the XSD published in the SCA Assembly 1.0 spec. Yours, Mike. Mike Edwards wrote: Folks, This is a screw-up in the online versions of the XSDs on www.osoa.org - they don't match the spec declarations for the XSDs. I'll go fix that, since those online files have no business failing to match the spec. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation of composite file
Florian, I'd point out that the recommended way of doing things is to add things in your own namespace. Adding stuff to the OSOA XSDs is not encouraged. If using your own namespace does not work, then we have some work to do to fix that... Yours, Mike. Jean-Sebastien Delfino wrote: Florian Rosenberg wrote: hi, I have my compoent type implementation and provided an XSD to use XML validation. Are there any specific steps I have to do. I'm currently using the version 1.0 binaries and I don't really where to put my XSD file. I checked the code and found the tuscany-assembly-xsd project, where I added my XSD to the tuscany-sca.xsd to check if it is working. All the validation errors on the console go away, nevertheless it does not really report an error if for example a mandatory attribute is missing in my XML tags. Could someone give us a brief description how the resolving works and how to enable it if I work with the Tuscany binary distribution and do not want to rebuild the tuscany-assembly-xsd to get it to work. Thanks, -Florian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The runtime currently loads: tuscany-assembly-xsd/src/main/resources/tuscany-sca-include.xsd - defining the SCA namespace http://www.osoa.org/xmlns/sca/1.0 tuscany-assembly-xsd/src/main/resources/tuscany-sca.xsd - defining the Tuscany namespace http://tuscany.apache.org/xmlns/sca/1.0 If you want to add your extension schema to the http://tuscany.apache.org/xmlns/sca/1.0 namespace you need to include it in tuscany-sca.xsd, and rebuild that module. This is not dynamic, but it's intentional as we need to provide application developers with a single central XSD file completely defining that namespace anyway... as this is what most XML schema validation tools and editors out there expect. If you want to define your extension schema in a different namespace, you can either: - Try to add the following to your composite element: composite ... xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=yourNamespace locationOfyourXSDFile ... not great but it should work. - Or just package the XSD file defining that namespace in your extension JAR and I'll add a few lines of code to look for and automatically load extension XSDs in extension JARs. I will post again here when it's ready for you to try. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: retrieve name of component in artifact processor
Florian, This isn't quite the way that componentType is intended to work. Let me try to explain. A componentType file is something that is really associated with an implementation, not with the component that uses the implementation. In effect, componentType is really a description of the external characteristics of the implementation, which can then be configured by the component which uses the implementation. (ie a listing of the services, references, properties, of the implementation). Some folks have even suggested a better name for the file of implementationInfo, just to drive the point home... In many ways, the ideal situation is where the componentType of an implementation is derived through inspection / introspection of the implementation artifact(s). This is generally the case for Java classes, for example. SCA allows for the case where implementation types cannot be introspected - and this is where the componentType file comes in. The componentType file allows the developer of the implementation to describe the external characteristics of the implementation in an XML file. The componentType file is usually placed in a location associated with the implementation artifact(s) (eg in the same directory) and usually has a name directly related to the name of the implementation artifact. So, let me take a guess that the Splice implementation artifact in your example is a file called echo.splice in the src/test/resources/flowdir/ directory. In this case, if you need to supply a componentType file with this, it could be called echo.componentType and placed in that same directory alongside the echo.splice file. Then, when your implementation processor is told to go retrieve the echo.splice implementation, you can find the echo.componentType file by a simple search in the same directory... All this assumes that you can't introspect the splice implementations for the relevant information, of course... After all this, I still hope that you can have some tools generate the componentType file - it's not much fun building these files by hand. An example where tools do generate the componentType files is in the case of C++ implementations - there are annotations in the source code which can be read by a compile-time processor and used to generate the componentType file at that point, since runtime introspection of C++ objects is not feasible. Happy to help further if I can. Yours, Mike. Florian Rosenberg wrote: folks, I'm writing a component impl type and in my artifact processor I would need the name attribute from a component defined in the composite file to be able to use a constistant resolving mechanism for my componentType files that describe the component. Example: component name=FooComponent tuscany:implementation.splice baseDir:=src/test/resources/flowdir/ path=echo url=echo contentType=text/plain / reference name=... / /component Is there a way to get that name (FooComponent) in the read() or resolve() method of the StAXArtifactProcessor implementation reading the implementation.splice attribute? The FooComponent.componentType is then used to describe the component, its references, etc. I could not figure out a way to retrieve it, probably I missed something. Thanks, -Florian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Specifications starting up in OASIS
haleh mahbod wrote: great idea. It'll make it easier for everyone to find this information. I'll add it if others agreeing. +1 from me. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning complex types from a service
Rob, I'm having a bit of trouble understanding exactly what you are trying to do. Could you post some of your code so that we get a better idea of what is going on, please? Yours, Mike. Robert Young wrote: Hi, I am running Tuscany within a Tomcat web project and I am getting the following exception Caused by: java.lang.NullPointerException at commonj.sdo.impl.HelperProvider.getDefaultContext(HelperProvider.java:379) ... I am guessing this is to do with trying to return a complex type from one of my services which is being exposed over JSONRPC. In this situation do I have to use SDO or are there other, simpler options? Cheers Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO] Sample re-arrangement
Folks, Having a central place with detailed descriptions of the samples in an organized fashion is a great idea. But this has nothing to do with the structuring on disk, in my opinion. Some folks will read the detailed docs. Others will simply get the code and start playing. For the latter folk, the simple / intermediate / advanced split is a crude guide, but useful for all that. It will also help sample writers think about the kind of sample that they are building - just how much prior knowledge and experience is required in order to tackle the sample? Thinking about samples in terms of graded steps is a very good idea. Cover the basics in one, add features in another and get into the rocket science in yet a third. Yours, Mike. haleh mahbod wrote: Kelvin, As a user, I would like to see a general ample index file that briefly explains what each sample does rather than the categorization that is mentioned here since the terms basic, intermediate, etc. are not well defined and are open to interpretation. Instead I would like to go to a central location that I can get enough information to decide which sample fits my requirements or decide for myself if I am ready to look at a sample. For example, 1. 'sample name' demonstrates the following a) create data object, update, retrieve b) How to use change history 2. 'sample name' demonstrates the following a) b) my 2 cents.. What do other users think? Haleh On 7/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Kelvin, I think basic may read better than novice, but otherwise this is a good idea. Yours, Mike. kelvin goodson wrote: I just checked in another sample which I'd be happy to take feedback on -- [1] (output appended as in my previous posts) I would like to rearrange the packages of the samples, as I think the current arrangement is not very helpful to someone trying to explore SDO (specCodeSnippets, specExampleSecstion andotherSources). I have recently been categorizing the samples with a flag to say whether they are at the novice, intermediate or advanced level. I think perhaps this would be a better way to package the samples too. So I propose to create the packages org.apache.tuscany.samples.sdo.novice org.apache.tuscany.samples.sdo.intermediate org.apache.tuscany.samples.sdo.advanced and move all sample programs out of the current packages into one of these new packages. The javadoc for the samples would still reference the original source material where appropriate, so that information wouldn't be lost. Comments? Regards,Kelvin. [1] http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/MedicalScenario.java?view=markup -- - Running with commentary level for a novice user- - Edit the sample program's constructor argument to one from - - COMMENTARY_FOR_NOVICE - - COMMENTARY_FOR_INTERMEDIATE or - - COMMENTARY_FOR_ADVANCED- - in order to alter the level of commentary you are seeing - -- --- - Tuscany SDO Java Sample org.apache.tuscany.samples.sdo.intermediate.MedicalScenario - - This sample is aimed at a intermediate user - --- - In this execution of the sample we use Types created - - using the SDO API- - The DataFactory associated with the scope that the types were created within - - can be used to create an instance of the Person Type - - - - DataFactory dataFactory = scope.getDataFactory(); - - DataObject person1 = dataFactory.create(www.example.org/people, Person); - - - The setString() of dataObject method is used to set the properties of the - - new Person DataObject, including a unique identifier reference value - - for the Person instance. - - - - person1.setString(id, 1); - - person1.setString(name, Joe Johnson Snr.); - - person1.setString(gender, male);); - - - - An alternative approach to using
Re: [Java-SCA] Running the example
Jean, Are you running with Java 6? We have had a report of this problem previously when people were running Tuscany with Java 6. Without having checked in detail, I suspect that this problem is caused because we build and test Tuscany on Java 5. In Java 5, the XML stream API is not part of the JDK and so Tuscany adds it in through the use of the the Woodstox streaming parser. In Java 6, there is an implementation of the XML stream API built into the base JDK. I suspect that there must be a clash between the Woodstox parser and the built-in parser. We shall have to investigate further to find a fix. In the short run, I'd recommend running Tuscany with some version of Java 5. Yours, Mike. Jean Georges Perrin wrote: Hi, Downloaded SCA v0.9 / Java. When I try the calculator example, I get: C:\...\org.apache.tuscany.sca\samples\calculatorant run Buildfile: build.xml run: [java] Exception in thread main javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException [java] at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl. init(ContributionRepositoryImpl.java:88) [java] at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createCo ntributionService(ReallySmallRuntimeBuilder.java:184) [java] at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySma llRuntime.java:93) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCA Domain.java:86) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.j ava:229) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68 ) [java] at calculator.CalculatorClient.main(CalculatorClient.java:31) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 12 seconds I guess I miss something in the classpath, but I am a little lost. jgp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple use case problem
Patrick, One point to make here is that separate contributions are intended to have different addresses, which in a simple file system equates to different directories. If you want multiple composites in the same directory, then you should make them part of one contribution, which is allowed. Yours, Mike. Patrick Vanhuyse wrote: Hi Simon, I removed sca-contibutions.xml from provider. I copied Provider.composite to consumer/src/main/resource. I add ProviderComposite to the consumer sca-contribution.xml. And it works. I have had a look at the code in SCADomain.newInstance(). It loads only one sca-contribution.xml, the first found by the class loader, I think. To solve this, it should look at all the sca-contribution.xml (conflict : they are all in the same folder) from the various jars on the classpath in place of using only one (depends on the ClassLoader). I don't know if it's possible (the class loading mechanism is a mystery to me !). Furthermore, there is the SCA loading mechanism used which is yet a greater mystery. I will go on with my other tests. Afterwards, if I dare, I will throw myself into all this loading stuff. Thanks for your help. Patrick -Message d'origine- De : Simon Laws [mailto:[EMAIL PROTECTED] Envoyé : mercredi 30 mai 2007 18:11 À : tuscany-user@ws.apache.org Objet : Re: Simple use case problem Hi Patrick What is going on here is that the consumer module is not loading the provider composite. I can make this work by doing the following... 1 - Make the provider composite available to the consumer runtime copy the Provider.composite to consumer/src/main/resource 2 - Make the ProviderComposite deployable add the ProviderComposite to the consumer sca-contributions.xmlfile Now I kind of expected to have to do 2 so that the runtime knows that the composite exists and should be deployed. However I don't know how to get round 1. I would like to be able to specify a jar to load alongside the consumer composite that is loaded. However I took a look at the code and there seems to be more work to do in making the runtime and contribution service flexible in this way. All help is gratefully received if you feel like getting your hands dirty ;-) Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the SDO SCA schemas available via internet
Dan, I'm working on this for the SCA materials. We have just had an upgrade of the www.osoa.org server that will allow us to serve files outside of the Confluence Wiki. This should allow us to place files at the correct URLs implied by the specifications. Previously, the server configuration did not allow this at all. With luck, this will be available by next week. Yours, Mike. Dan Murphy wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Closer Involvement with the OSOA Specifications for Tuscany Developers - Update
Folks, I need to make an update to my original email about the OSOA Supporters group to clarify things. Anyone who is an employee of any of the member companies of the OSOA collaboration does not need to go through the process to sign up as an OSOA Supporter. This is simply because employees are already covered by legal agreements signed by your company - so that you can give any feedback you like without signing any more forms! To see which companies are members of the OSOA Collaboration look here: http://www.osoa.org/display/Main/Service+Component+Architecture+Partners and here: http://www.osoa.org/display/Main/Service+Data+Objects+Partners If you are an employee and you would like a userid to access the osoa.org Wiki site, please send an email with your request to: [EMAIL PROTECTED] Yours, Mike. haleh mahbod wrote: Thank you Mike. This is very good information. Forwarding your email to tuscany-user mailing list as well. -- Forwarded message -- From: *Mike Edwards* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Oct 24, 2006 5:52 AM Subject: Closer Involvement with the OSOA Specifications for Tuscany Developers To: tuscany-dev@ws.apache.org mailto:tuscany-dev@ws.apache.org Folks, The Open SOA collaboration, which is working on the SCA specifications and the SDO specifications, welcomes feedback on the evolving specifications, particularly from the Tuscany developers who are actively involved in implementing the specifications. If you would like to get closer involvement with the evolution of the specifications, you can now apply to join the OSOA Supporters group. The OSOA Supporters have a special controlled-access area on the www.osoa.org http://www.osoa.org Wiki site, which gives access to the minutes of the regular specification conference calls and which provides a discussion Forum which allows for discussion of any topics relating to the specifications and to the issues that are currently under discussion within the collaboration. To become at OSOA Supporter, please go to the following page on the OSOA site: http://www.osoa.org/display/Main/OSOA+Supporters+Home You will be asked to sign a simple Feedback license - this is similar in nature to the ICLA agreement that you must sign in order to contribute code to Apache. The OSOA collaboration specifications are published under generous Royalty-Free terms and the collaboration needs to ensure that any detailed feedback that you give on the specifications is donated in a way that meets those terms. Individuals may join the OSOA Supporters group as well as companies. Yours, Mike Edwards Chair of SCA Assembly Specification Working Group - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
