Service Oriented Architecture?

[Shaun C McDonnell]

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

 

[Dino Chiesa [Microsoft]]

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.

 

[Generic Usenet Account]

[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&[email protected]
]

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.

 

[Umut K. Tezduyar]

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]

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. (e-mail address removed)>
ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:[email protected]...

 

[Jeffrey Hasan]

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.

 

[Gopi Bulusu]

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