Service Oriented Architecture?

Discussion in 'ASP .Net Web Services' started by Shaun C McDonnell, May 26, 2004.

  1. All,

    There is alot of talk and buzz around the idea of implementing a service
    oriented architecture. I am very much interested in this concept and how it
    could help benefit the corporation that I work for. However, I am failing
    to see the difference between component-based development and SOA. Is the
    difference only within the technology?

    It comes down to this question for me: Is there a benefit in developing
    only Web Services (SOA) rather than a .NET Assembly for reuse? The benefits
    that I see are mostly related to B2B transactions, easier enterprise
    integration, and possibly some faster deployment and a more controlled
    versioning environment. But, at the same time, alot seems to be lost when
    going to a pure stateless/non-persistent environment through Web Services in
    a programming environment.

    Being a component developer for a large corporation, I am always looking for
    reasons to be more agile and the deployment scenario alone seems to allow a
    more agile environment, but, is there any reason to go to a strict Web
    Service environment and stop deploying assemblies to our developers?

    Thanks for your time,

    Shaun
    Shaun C McDonnell, May 26, 2004
    #1
    1. Advertising


  2. > It comes down to this question for me: Is there a benefit in developing
    > only Web Services (SOA) rather than a .NET Assembly for reuse?


    yes.

    SOA is not the same as webservices, and all webservices systems are not SOA.

    There are 4 commonly cited tenets behind SOA; I use the word BASH to
    remember them
    B= Boundaries, which are explicit, and expensive to traverse
    A = Autonomous, which is to say, the communicating systems are independent
    and independently managed.
    S = Schema - the service interfaces are defined by schema. there is no
    assumption of type sharing.
    H = Negotiate (??). the services can negotiate the quality of service based
    on policy. Eg, the responder service may decline to honor a request if the
    requestor cannot accept encrypted responses.

    The benefit is that systems plugging into a SOA can be loosely coupled and
    need not all run on .NET, or on Windows. Interoperability.

    The drawback of course is that it is much more complicated than just
    dropping in a .NET Assembly.

    Rule of thumb: continue to use components and assemblies to segment code
    within a particular applications. However, where the app is exposed to "the
    outside world", that is to say, any system that is not being developed by
    the same team, or maintained by the same team, etc. , then, consider SOA and
    looser coupling.

    By the way, nothing you see in the "tenets of SOA" indicate "web services"
    or "SOAP" or "WSDL". you *could* implement a SOA with webservices
    technology, and that will probably be the most common approach, but a SOA
    need not be limited to web services technology, and it need not include any
    webservices technology.

    > that I see are mostly related to B2B transactions, easier enterprise
    > integration,


    Yes

    >and possibly some faster deployment and a more controlled
    > versioning environment.


    Depends.

    > But, at the same time, alot seems to be lost when
    > going to a pure stateless/non-persistent environment through Web Services

    in
    > a programming environment.


    Webservices are by nature stateless but it is possible to make them
    stateful. You don't have to lose state.

    > Being a component developer for a large corporation, I am always looking

    for
    > reasons to be more agile and the deployment scenario alone seems to allow

    a
    > more agile environment, but, is there any reason to go to a strict Web
    > Service environment and stop deploying assemblies to our developers?
    >


    No, in the general case you will use both. Different approaches for
    different purposes. The two are complementary, not mutually exclusive.

    > Thanks for your time,
    >
    > Shaun
    >
    >
    Dino Chiesa [Microsoft], May 26, 2004
    #2
    1. Advertising

  3. [The following posting by Dino Chiesa from Microsoft has an
    interesting take on Service-oriented Architectures. I am
    cross-posting it to more mainstream news groups, where this topic may
    be of interest

    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=
    ]



    > It comes down to this question for me: Is there a benefit in developing
    > only Web Services (SOA) rather than a .NET Assembly for reuse?


    yes.

    SOA is not the same as webservices, and all webservices systems are
    not SOA.

    There are 4 commonly cited tenets behind SOA; I use the word BASH to
    remember them
    B= Boundaries, which are explicit, and expensive to traverse
    A = Autonomous, which is to say, the communicating systems are
    independent
    and independently managed.
    S = Schema - the service interfaces are defined by schema. there is no
    assumption of type sharing.
    H = Negotiate (??). the services can negotiate the quality of service
    based
    on policy. Eg, the responder service may decline to honor a request
    if the
    requestor cannot accept encrypted responses.

    The benefit is that systems plugging into a SOA can be loosely coupled
    and
    need not all run on .NET, or on Windows. Interoperability.

    The drawback of course is that it is much more complicated than just
    dropping in a .NET Assembly.

    Rule of thumb: continue to use components and assemblies to segment
    code
    within a particular applications. However, where the app is exposed
    to "the
    outside world", that is to say, any system that is not being developed
    by
    the same team, or maintained by the same team, etc. , then, consider
    SOA and
    looser coupling.

    By the way, nothing you see in the "tenets of SOA" indicate "web
    services"
    or "SOAP" or "WSDL". you *could* implement a SOA with webservices
    technology, and that will probably be the most common approach, but a
    SOA
    need not be limited to web services technology, and it need not
    include any
    webservices technology.

    > that I see are mostly related to B2B transactions, easier enterprise
    > integration,


    Yes

    >and possibly some faster deployment and a more controlled
    > versioning environment.


    Depends.

    > But, at the same time, alot seems to be lost when
    > going to a pure stateless/non-persistent environment through Web Services in
    > a programming environment.


    Webservices are by nature stateless but it is possible to make them
    stateful. You don't have to lose state.

    > Being a component developer for a large corporation, I am always looking for
    > reasons to be more agile and the deployment scenario alone seems to allow a
    > more agile environment, but, is there any reason to go to a strict Web
    > Service environment and stop deploying assemblies to our developers?
    >


    No, in the general case you will use both. Different approaches for
    different purposes. The two are complementary, not mutually
    exclusive.

    > Thanks for your time,
    >
    > Shaun
    >
    >
    Generic Usenet Account, Jun 2, 2004
    #3
  4. I have read the text on msdn news groups about SOA, your reply to Shaun C
    McDonnell. That was really good information for me. I had the same questions
    as Shaun C McDonnell.
    I want to have deep knowlage about soa. I need examples, more
    documentation. Search through the web was insufficient for me. Could you
    advise me sources for them. Do you know a good book about this.
    I am especially interested in applying soa on small applications that
    are not a part of a connected system now, but may be in the future. In fact i
    want to be sure "what so is"?

    If you can help me, i would be very happy. Thanks !


    "Dino Chiesa [Microsoft]" wrote:

    >
    > > It comes down to this question for me: Is there a benefit in developing
    > > only Web Services (SOA) rather than a .NET Assembly for reuse?

    >
    > yes.
    >
    > SOA is not the same as webservices, and all webservices systems are not SOA.
    >
    > There are 4 commonly cited tenets behind SOA; I use the word BASH to
    > remember them
    > B= Boundaries, which are explicit, and expensive to traverse
    > A = Autonomous, which is to say, the communicating systems are independent
    > and independently managed.
    > S = Schema - the service interfaces are defined by schema. there is no
    > assumption of type sharing.
    > H = Negotiate (??). the services can negotiate the quality of service based
    > on policy. Eg, the responder service may decline to honor a request if the
    > requestor cannot accept encrypted responses.
    >
    > The benefit is that systems plugging into a SOA can be loosely coupled and
    > need not all run on .NET, or on Windows. Interoperability.
    >
    > The drawback of course is that it is much more complicated than just
    > dropping in a .NET Assembly.
    >
    > Rule of thumb: continue to use components and assemblies to segment code
    > within a particular applications. However, where the app is exposed to "the
    > outside world", that is to say, any system that is not being developed by
    > the same team, or maintained by the same team, etc. , then, consider SOA and
    > looser coupling.
    >
    > By the way, nothing you see in the "tenets of SOA" indicate "web services"
    > or "SOAP" or "WSDL". you *could* implement a SOA with webservices
    > technology, and that will probably be the most common approach, but a SOA
    > need not be limited to web services technology, and it need not include any
    > webservices technology.
    >
    > > that I see are mostly related to B2B transactions, easier enterprise
    > > integration,

    >
    > Yes
    >
    > >and possibly some faster deployment and a more controlled
    > > versioning environment.

    >
    > Depends.
    >
    > > But, at the same time, alot seems to be lost when
    > > going to a pure stateless/non-persistent environment through Web Services

    > in
    > > a programming environment.

    >
    > Webservices are by nature stateless but it is possible to make them
    > stateful. You don't have to lose state.
    >
    > > Being a component developer for a large corporation, I am always looking

    > for
    > > reasons to be more agile and the deployment scenario alone seems to allow

    > a
    > > more agile environment, but, is there any reason to go to a strict Web
    > > Service environment and stop deploying assemblies to our developers?
    > >

    >
    > No, in the general case you will use both. Different approaches for
    > different purposes. The two are complementary, not mutually exclusive.
    >
    > > Thanks for your time,
    > >
    > > Shaun
    > >
    > >

    >
    >
    >
    Umut K. Tezduyar, Aug 12, 2004
    #4
  5. U can find many info about SOA in http://msdn.microsoft.com/architecture/ ,
    http://www.zapthink.com/, www.cbdiforum.com, www.bea.com and www.ibm.com
    sites.

    "Umut K. Tezduyar" <Umut K. >
    ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
    news:...
    > I have read the text on msdn news groups about SOA, your reply to

    Shaun C
    > McDonnell. That was really good information for me. I had the same

    questions
    > as Shaun C McDonnell.
    > I want to have deep knowlage about soa. I need examples, more
    > documentation. Search through the web was insufficient for me. Could you
    > advise me sources for them. Do you know a good book about this.
    > I am especially interested in applying soa on small applications that
    > are not a part of a connected system now, but may be in the future. In

    fact i
    > want to be sure "what so is"?
    >
    > If you can help me, i would be very happy. Thanks !
    Denis Kondratyev, Aug 12, 2004
    #5
  6. Hi Umut,

    My new book on SOA and WSE 2.0 may be useful to you (link below). There are
    plenty of good references and articles online as well, especially on MSDN
    and in the blogs.

    Jeffrey Hasan, MCSD
    President, Bluestone Partners, Inc.
    -----------------------------------------------
    Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
    http://www.bluestonepartners.com/soa.aspx

    "Umut K. Tezduyar" <Umut K. > wrote in
    message news:...
    > I have read the text on msdn news groups about SOA, your reply to

    Shaun C
    > McDonnell. That was really good information for me. I had the same

    questions
    > as Shaun C McDonnell.
    > I want to have deep knowlage about soa. I need examples, more
    > documentation. Search through the web was insufficient for me. Could you
    > advise me sources for them. Do you know a good book about this.
    > I am especially interested in applying soa on small applications that
    > are not a part of a connected system now, but may be in the future. In

    fact i
    > want to be sure "what so is"?
    >
    > If you can help me, i would be very happy. Thanks !
    >
    >
    > "Dino Chiesa [Microsoft]" wrote:
    >
    > >
    > > > It comes down to this question for me: Is there a benefit in

    developing
    > > > only Web Services (SOA) rather than a .NET Assembly for reuse?

    > >
    > > yes.
    > >
    > > SOA is not the same as webservices, and all webservices systems are not

    SOA.
    > >
    > > There are 4 commonly cited tenets behind SOA; I use the word BASH to
    > > remember them
    > > B= Boundaries, which are explicit, and expensive to traverse
    > > A = Autonomous, which is to say, the communicating systems are

    independent
    > > and independently managed.
    > > S = Schema - the service interfaces are defined by schema. there is no
    > > assumption of type sharing.
    > > H = Negotiate (??). the services can negotiate the quality of service

    based
    > > on policy. Eg, the responder service may decline to honor a request if

    the
    > > requestor cannot accept encrypted responses.
    > >
    > > The benefit is that systems plugging into a SOA can be loosely coupled

    and
    > > need not all run on .NET, or on Windows. Interoperability.
    > >
    > > The drawback of course is that it is much more complicated than just
    > > dropping in a .NET Assembly.
    > >
    > > Rule of thumb: continue to use components and assemblies to segment

    code
    > > within a particular applications. However, where the app is exposed to

    "the
    > > outside world", that is to say, any system that is not being developed

    by
    > > the same team, or maintained by the same team, etc. , then, consider SOA

    and
    > > looser coupling.
    > >
    > > By the way, nothing you see in the "tenets of SOA" indicate "web

    services"
    > > or "SOAP" or "WSDL". you *could* implement a SOA with webservices
    > > technology, and that will probably be the most common approach, but a

    SOA
    > > need not be limited to web services technology, and it need not include

    any
    > > webservices technology.
    > >
    > > > that I see are mostly related to B2B transactions, easier enterprise
    > > > integration,

    > >
    > > Yes
    > >
    > > >and possibly some faster deployment and a more controlled
    > > > versioning environment.

    > >
    > > Depends.
    > >
    > > > But, at the same time, alot seems to be lost when
    > > > going to a pure stateless/non-persistent environment through Web

    Services
    > > in
    > > > a programming environment.

    > >
    > > Webservices are by nature stateless but it is possible to make them
    > > stateful. You don't have to lose state.
    > >
    > > > Being a component developer for a large corporation, I am always

    looking
    > > for
    > > > reasons to be more agile and the deployment scenario alone seems to

    allow
    > > a
    > > > more agile environment, but, is there any reason to go to a strict Web
    > > > Service environment and stop deploying assemblies to our developers?
    > > >

    > >
    > > No, in the general case you will use both. Different approaches for
    > > different purposes. The two are complementary, not mutually exclusive.
    > >
    > > > Thanks for your time,
    > > >
    > > > Shaun
    > > >
    > > >

    > >
    > >
    > >
    Jeffrey Hasan, Aug 13, 2004
    #6
  7. Shaun C McDonnell

    Gopi Bulusu Guest

    > >
    > > "Dino Chiesa [Microsoft]" wrote:
    > >


    > > > SOA is not the same as webservices, and all webservices systems are not

    > SOA.
    > > >
    > > > There are 4 commonly cited tenets behind SOA; I use the word BASH to
    > > > remember them
    > > > B= Boundaries, which are explicit, and expensive to traverse
    > > > A = Autonomous, which is to say, the communicating systems are

    > independent
    > > > and independently managed.
    > > > S = Schema - the service interfaces are defined by schema. there is no
    > > > assumption of type sharing.
    > > > H = Negotiate (??). the services can negotiate the quality of service

    > based


    This is very interesting and informative. However, I think the 'S'
    definitely needs to be relooked :)

    What is the difference between "Schema Sharing" and "Type Sharing"

    A schema generally refers to something that describes a domain of
    values
    that are permissible (for example in a database table). That's
    precisely
    what a 'type' does. No 2 services or objects or people can communicate
    unless they eventually agree on a common language (grammar) and
    vocabulary.

    I think early in the application server days, people tended to create
    monolithic applications (example - using J2EE) comprising of
    individual components. The Service Oriented Architecture is just a
    logical next step
    where several autonomous servers (as you rightly pointed out)
    collaborate
    to provide a particular solution to the end user. Weak coupling of
    such
    services is of course an easy way to make build initial systems, by
    transfering the burden of integration to the subscriber of a service
    rather than the provider of such a service. Of course standards,
    especially XML
    standards ensure that an organization can decide on an enterprise
    service
    bus effectively making it easy for integrating the various services.

    IMO, There is really not much difference between using a whole bunch
    of individual and autonomous CORBA services that collaborate to
    provide a
    solution (which was how distributed systems were mostly built before
    J2EE)
    and the idea of SOA, except in the technologies used and the mindset
    of
    the solution architects ! Most SOA solutions now will include a portal
    that
    provides a single-point of access to various services.

    Best Regards,
    gopi

    ---

    Gopi Kumar Bulusu
    Sankhya Technologies Private Limited
    http://www.sankhya.com
    Tel: +91 891 554 2666
    Fax: +91 891 554 2665
    Gopi Bulusu, Aug 13, 2004
    #7
    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. Lian Liming
    Replies:
    2
    Views:
    380
    Patrick May
    Oct 26, 2005
  2. crm-tutorial
    Replies:
    0
    Views:
    330
    crm-tutorial
    Oct 5, 2006
  3. crm-tutorial
    Replies:
    0
    Views:
    347
    crm-tutorial
    Oct 5, 2006
  4. bpm
    Replies:
    0
    Views:
    349
  5. Purushottam Khandebharad

    web service boundaries for service oriented architecture

    Purushottam Khandebharad, Dec 14, 2005, in forum: ASP .Net Web Services
    Replies:
    1
    Views:
    137
    Henrik Gøttig
    Dec 20, 2005
Loading...

Share This Page