Hi Ben,
it is true that you will want to adapt the service to the domain object
change. But you have to do it in a way that you can first create a new
service version that includes the change while in the same time still
offering the old version. So your clients can adapt one after the other.
Then when all clients use the new version you can retire the old
version. It is the same when you build an api of a library that many
people use.
If you simply change the service contract from one day to the other you
will force all your service users to roll out their new version at the
same time with your change. In a big company this is almost impossible.
At least you will have to delay your own rollout if only one of the
service users is delayed in their rollout. This can slow down innovation
in a company extremly. Handling changes in services is one of the
biggest challenges in SOA.
Best regards
Christian
Ben Berner schrieb:
Thanks Dan and Christian for the responses.
Christian: So from your email, I gather that use some sort of dto instead of
the actual domain object. However, let's say the the domain object changes
due to some user requirements, now won't my dto also change beacause I may
have to send extra data (again off the user requirement) requiring the
clients to change their code in this scenario? for example, say Employee
has name, id and so does EmployeeTransfer object. Now changing
EmployeeTransfer class to include age attribute will still require me to
change the wsdl, won't it? In this case, I would think I will have to
publish a new version of the earlier service....
Regards,
Ben
On Thu, Jun 12, 2008 at 2:50 PM, Christian Schneider <
[EMAIL PROTECTED]> wrote:
