WS- I Basic Profile - Clarification

Discussion in 'ASP .Net Web Services' started by Rasheed, Jul 26, 2006.

  1. Rasheed

    Rasheed Guest

    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.
     
    Rasheed, Jul 26, 2006
    #1
    1. Advertising

  2. "Rasheed" <> wrote in message
    news:...
    > 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
     
    John Saunders, Jul 27, 2006
    #2
    1. Advertising

  3. Rasheed

    Rasheed Guest

    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" wrote:

    > "Rasheed" <> wrote in message
    > news:...
    > > 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, Jul 27, 2006
    #3
  4. "Rasheed" <> wrote in message
    news:...
    > 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

    >
    > "John Saunders" wrote:
    >
    >> "Rasheed" <> wrote in message
    >> news:...
    >> > 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
    >>
    >>
    >>
     
    John Saunders, Jul 29, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brad
    Replies:
    1
    Views:
    1,160
    Roedy Green
    Jul 19, 2005
  2. Andy B
    Replies:
    0
    Views:
    546
    Andy B
    May 3, 2008
  3. Steven
    Replies:
    5
    Views:
    504
    Steven
    Oct 24, 2008
  4. Nick Locke

    Basic Profile 1.1

    Nick Locke, Oct 28, 2006, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    206
    Nick Locke
    Oct 29, 2006
  5. mehdi

    WSI Basic Profile 1.1 Compliant Web Service!

    mehdi, Dec 11, 2006, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    148
    mehdi
    Dec 11, 2006
Loading...

Share This Page