WS- I Basic Profile - Clarification

[Rasheed]

Please forgive my ignorance as I’m new to SOA related interoperability
issues. The requirement is to build interoperable web services which should
conform to WS-I Basic Profile 1.1 (This requirement came little late in the
development life cycle)

The current web service implementation heavily uses Data Transfer Objects
(DTO) as parameters to web service (The DTO itself contains primitive data
types) . In few places .NET generics are used as well.
Having said,

Do we conform to WS-I BP? Or To what degree we conform to WS-I BP?
If not, what would it take to make is WS-I conformance?

Kindly advice.

 

[John Saunders]

Please forgive my ignorance as I'm new to SOA related interoperability
issues. The requirement is to build interoperable web services which
should
conform to WS-I Basic Profile 1.1 (This requirement came little late in
the
development life cycle)

The current web service implementation heavily uses Data Transfer Objects
(DTO) as parameters to web service (The DTO itself contains primitive data
types) . In few places .NET generics are used as well.
Having said,

Do we conform to WS-I BP? Or To what degree we conform to WS-I BP?
If not, what would it take to make is WS-I conformance?

I don't know the full answer, but you can start right now changing your DTOs
not to expose .NET-isms. Generics aren't universal, so should not be exposed
to clients of your service. Keep in mind that a web service may be accessed
from any kind of client, including those which aren't even modern
programming languages with a knowledge of generics or templates.

Also, as a matter of personal taste, I don't think it's a good idea to
expose a DTO at all in a web service. Even though a DTO masks the details of
your data layer, using one is forcing the concept of "data transfer" into
the awareness of the client. It's an implementation-level concept which, I
don't think, belongs in your web service contract.

Besides, what if your data layer changes - adds new columns, for instance.
Your clients should not see the difference. You had a contract with them,
and it didn't include those extra columns.


John

 

[Rasheed]

John,

Thanks for your valuable inputs. We heavily depend on DTO to import data
from various legacy systems. The webservice will get the data as DTO structre
and import in to our database using Data Access Layer. This is similiar to
"Direct Integration of Legacy Data"

In previous version of the application, the legacy data integration happens
as a "batch" process. In this scenario, we are trying to eliminate the need
for batch processing of data. i.e. the legacy system will simply use the web
service to export the data to our database.

Are we doing anything wrong? Thanks for helping.

 

[John Saunders]

John,

Thanks for your valuable inputs. We heavily depend on DTO to import data
from various legacy systems. The webservice will get the data as DTO
structre
and import in to our database using Data Access Layer. This is similiar to
"Direct Integration of Legacy Data"

In previous version of the application, the legacy data integration
happens
as a "batch" process. In this scenario, we are trying to eliminate the
need
for batch processing of data. i.e. the legacy system will simply use the
web
service to export the data to our database.

Are we doing anything wrong? Thanks for helping.

Define "wrong". It's "right" until it's not.

If this is a special-purpose web service, then it doesn't matter what you
send back and forth, as long as the two ends, which you control, understand.
This will work until someone in Management decides that if you're using a
Web Service, that the same code should also be able to communicate with some
random system which does _not_ understand parts of your DTO. Then you'll
have to explain how it is that you used a platform-independant technology
like Web Services to produce a platform-dependant service!


John