Repository Structure

[jervisliu]

Does the repository structure proposed below look alright?


Services:
- serviceA
- serviceB
...
Question:
under the Services node, are we going to have another layer of structures? like JBOSSESB, Web Services or any kind of services that can be managed by SOA Repository?

Message Schemas and Samples
- A.xsd
- B.xsd
...
-sampleA.xml
-sampleB.xml

Policies
-policyA.xml
-policyB.xml

Configurations
We do need a configuration section, dont we?. Such as jboss-esb.xml or a spring configuration file. The idea is to encourage the reuse of configurations among different services.

Documentations

WSDL?
not sure about this. Having a WSDL section makes the SOA Repository very "Web Services centric". Maybe we can call this section "service contract"? so that ppl can use this section to store any kind of service contract that describes their services.

Any thing else we need?

[jeffdelong]

Sorry I took so long to reply:

I think there should be another layer under the service. Think of the top layer as the business description of the service, and the underlying layer as the technical implementation of the service.

I don't see why we would need a configuration section? I would think configuration information would be associated with the technical details of the service. I don't see how configuration is re-usable across different services. Perhaps you have an example?

WSDL. Well a contract can be more than a WSDL. Indeed much of the contract information can be in the XSD. We should be able to upload WSDLs and associate them with services. For the rest of the world SOA is very Web service centric. If you look at other repository products, Web services are handled as first class citizens.

We also need to handle BPEL files. We should be able to upload a BPEL file and associate it with a service.