[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.aspnet.webservices

Re: Service Oriented Architecture?

(Generic Usenet Account)

7/22/2004 12:11:00 AM

[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=u3jQIlvQEHA.3660%40TK2MSFTNGP...
]



> 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
>
>