| Author |
Message
|
| HOMETOWN47 |
 Posted: Fri Apr 03, 2009 2:28 am Post subject: Message Sets from Importing WSDL |
 |
|
Apprentice
Joined: 25 Mar 2003
Posts: 34
|
Question on message sets and web services.
Working on a client site where they are creating Web Services and they have created several WSDL's that define the services, endpoints, messages etc.
Each of the WSDL's refer to a common schema that defines the req/resp messages. In common I mean there is one great big schema where all the req/resp messages are defined in a common schema which itself then imports two further schemas that define data elements and data types.
The WSDL's have been imported into the MB toolkit via the 'Start from WSDL' wizard. Within each message set project the message definitions (.mxsd) have been created for each of the message schema's (the main 'common' schema and the two schema's reference as imports within this schema).
The message defintions created within each of the projects are created using namespaces. For instance:-
the 'common' message schema is in schema
| Code: |
com.wibble.esb.common.esb
wibble_portal_services.mxsd
This has a target namespace of 'http://wibble.com/esb/common/esb'
And imports '..types/wibble_esb_common_types.mxsd' and '..icommon/wibble_esb_common_internal_elements.msxd'
|
These refer to the same mset project where we have schemas
| Code: |
com.wibble.esb.common.icommon
wibble_esb_common_internal_elements.mxsd
This has a target namespace of 'http://wibble.com/esb/common/icommon'
|
and
| Code: |
com.wibble.esb.common.types
wibble_esb_common_types.mxsd
Target namespace of 'http://wibble.com/esb/common/types'
|
The issue is that we now have multiple version of the same common message defintion files across mutlipe message set projects. I can see that people have made changes to one WSDL and it's associated message definitons which are then not reflected across the other WSDL.
Is there a best practice prevent this occurring ?
Can I import the 3 schemas into a seperate message set project and then reference them in the imported (via wizard) WSDL ? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Fri Apr 03, 2009 2:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| No, you cannot reference one message set from another message set. Each message set is a self-contained entity. |
|
| Back to top |
|
|
| HOMETOWN47 |
| Posted: Fri Apr 03, 2009 3:12 am Post subject: |
|
|
Apprentice
Joined: 25 Mar 2003
Posts: 34
|
I suspected that was how it might be but it does seem to be an issue when it comes to web services and maintainability. I assume that it is quite common that one or more web services share a common message schema but this then implies that they all must be defined in the same message set (and WSDL) if you want to avoid this duplication of message defintions across projects ?
As I see it, if we continue to have multiple versions on the message defs in multiple projects then there is a large overhead in keeping them all in step.
I'm not sure if having the common message definition is a good approach or not as we are starting to having issues about re-use of existing and creating new services as any change will affect all services that use that common message set project.
Would appreciate other peoples views on the approach that should be taken.... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 03, 2009 3:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
When it comes to web services, you maintain the WSDL, and the schema that build them.
You don't manually make changes to artifacts generated from WSDLs. This includes message sets. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Apr 03, 2009 4:19 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I do have some sympathy with you. Duplication of schemas is likely to cause maintainability problems. Can you add a trigger to your configuration management system so that when the common schema gets changed it sends an email to a responsible person, or triggers a rebuild of all affected BAR files?
I would be surprised if you are the first person to grapple with this problem, so I expect other suggestions will be put forward.
| Quote: |
| I'm not sure if having the common message definition is a good approach or not as we are starting to having issues about re-use of existing and creating new services as any change will affect all services that use that common message set project. |
If the common message definition is well-designed, then it should not need changing very often. If it does change often, then it probably is not really 'common'. |
|
| Back to top |
|
|
| HOMETOWN47 |
| Posted: Fri Apr 03, 2009 4:52 am Post subject: |
|
|
Apprentice
Joined: 25 Mar 2003
Posts: 34
|
In response to the previous two posts:-
| Quote: |
When it comes to web services, you maintain the WSDL, and the schema that build them.
You don't manually make changes to artifacts generated from WSDLs. This includes message sets. |
In a way this is what I have been doing to date as the source WSDL and XSD's have been imported into the message set project. When a change is required I've been editing the schemas (using an XML editor tool) then manually cutting and pasting the changes back into the message def files. Doing it this way allows me to keep all my changes in one section at the end of the file which hopefully will simplify merging the changes in any other projects.
Problem is that I've only joined the project in the last few months and there has not been a defined process in place up to now. Consequently, the different message defn files are all out of step across the projects....
| Quote: |
| If the common message definition is well-designed, then it should not need changing very often. If it does change often, then it probably is not really 'common'. |
The common message definition will change if for example a new service is created and therefore a new request and response message structure is defined. The new request and response may refer to new data elements that are defined as new complex data types or it may refer to existing data elements already defined.
The idea was that by having a common schema would make the re-use of common types easier but it sounds like that is not the case !
The client uses Rational Clear Case which I assume could be configured to intiate emails etc if someone changes a message set project that contains the 'common' definition files. |
|
| Back to top |
|
|
|
|
