Software Engineering - SOA and real world systems

Author

SOA and real world systems

sdg

2006-01-10, 4:09 am

Hello;

I have just plowed through "Service-Oriented Architecture: A Field Guide to
Integrating XML and Web Services", and have read some other texts on the
subject.

In the past I have developed in CORBA, and books such as "Advanced CORBA
Programming with C++" were very helpful.

Because of the multiplicity of languages/toolkits/etc., is it a vain hope that I
would find a book as comprehensive as the CORBA one for a SOAP/WS-*/XML world?
I am looking for something to help bridge my understanding of programming a SOA
based world.

Given the multiplicy of toolkits, once I pick a language and toolkit, am I stuck
with that particular vendor's binding, just as we were in a CORBA 1.x world? So
that if, for example, I am exposing C++, I have to pick Microsoft/gSOAP/Iona's
kit and am stuck with them 'forever'?

Also, some SOA advocates seem to be making some of the same mistakes as CORBA
people of old, when EVERYTHING can be remote, with no impact to the local
application, and no extra overhead or error checking. Would it be fair to say
that anything that in the old-fashioned distributed world that I wanted local
and therefore comparatively robust I would keep that way? Why would I want to
service-ize my XML->PDF generation, when there are so many good libraries to do
that locally (for example)? When by doing so, I not only have the normal
XML->PDF failures to deal with, but networking and others as well?

What have people done in the real-world with SOA arhitectures? What level of
granularity have they been? What did the SOA-buzzword-compliance give you that
would not have been as possible in another distributed system?

Thanks
sdg

Merlin

2006-01-10, 4:09 am

Hi

We have been developing a Service Oriented application for the past two
years. I can tell you using .NET technology has made it exceedingly
easy to create web services and and use them in your application. It is
really seamless. There are however things that you should do
differently when developing distributed applications. The calls to the
web services for instance must not be chatty and u should try to do
reasonable work in a single call. Further more the way web services
work is by using a proxy object. So when a client wants to use a web
service it will do so via this proxy object on the client side. Within
the client you want to create this proxy once and use it each time you
need to call your web service. The singleton design pattern can be used
to ensure you just create this object once.

Your client can be configured through an XML configuration file to
access various webservices. These are often specified as URLs values
for keys. This way if a specific web service goes down you could switch
and use another. A good example is say a credit rating web service.
Your client could have the details of a few and in case one is down it
could use another. SOA of course follows a standard that has been
adopted widely and it will continue to do so. I anticipate that more
and more companies will start using SOA and you will see organisations
provide service interfaces. In not too distant future B2B integration
will become much easier and companies will be able to exchange
information using web services instead of using emails or paper.

In regards to error checking this is often done in two places. Once in
the client application and the other place is on the server. This is
because you may use the webservice not via the client, eg server to
server say. Often you create an error checking project assembly (dll)
that get loaded dynamically when its needed on the server and on the
client.

Merlin

JXStern

2006-01-10, 4:09 am

SOA is a great idea for selling services, it's not clear how great an
idea it is for buying services! Maybe enough people like you and me
and Merlin have already been through the architectural mistakes one
can make with n-tier systems, that we can avoid them with SOA, since
as you note the same old mistakes are still there to make!

J.

On 6 Jan 2006 08:00:10 -0800, sdg <sdg_member@newsguy.com> wrote:

>Hello;
>
>I have just plowed through "Service-Oriented Architecture: A Field Guide to
>Integrating XML and Web Services", and have read some other texts on the
>subject.
>
>In the past I have developed in CORBA, and books such as "Advanced CORBA
>Programming with C++" were very helpful.
>
>Because of the multiplicity of languages/toolkits/etc., is it a vain hope that I
>would find a book as comprehensive as the CORBA one for a SOAP/WS-*/XML world?
>I am looking for something to help bridge my understanding of programming a SOA
>based world.
>
>Given the multiplicy of toolkits, once I pick a language and toolkit, am I stuck
>with that particular vendor's binding, just as we were in a CORBA 1.x world? So
>that if, for example, I am exposing C++, I have to pick Microsoft/gSOAP/Iona's
>kit and am stuck with them 'forever'?
>
>Also, some SOA advocates seem to be making some of the same mistakes as CORBA
>people of old, when EVERYTHING can be remote, with no impact to the local
>application, and no extra overhead or error checking. Would it be fair to say
>that anything that in the old-fashioned distributed world that I wanted local
>and therefore comparatively robust I would keep that way? Why would I want to
>service-ize my XML->PDF generation, when there are so many good libraries to do
>that locally (for example)? When by doing so, I not only have the normal
>XML->PDF failures to deal with, but networking and others as well?
>
>What have people done in the real-world with SOA arhitectures? What level of
>granularity have they been? What did the SOA-buzzword-compliance give you that
>would not have been as possible in another distributed system?
>
>Thanks
>sdg

Merlin

2006-01-10, 4:09 am

What mistakes are those... Just curious to know!

Merlin

JXStern

2006-01-10, 4:09 am

On 8 Jan 2006 00:04:12 -0800, "Merlin" <merlin2769@hotmail.com> wrote:
>What mistakes are those... Just curious to know!

As you said, "don't be chatty", you have to respect the topology.

As you said, create your singleton/proxy objects efficiently.

As you say, error check in two places, both client and server, and
even more places if you have n-tiers, and not just error-check but
edit-checks as well, I might add.

Stuff like that!

The big mistake is to treat all of cyberspace as if it were a single,
local domain, just a big, unified space to write sloppy code in. All
the rest is commentary.

J.

>
>Merlin

Cristiano Sadun

2006-01-11, 7:00 pm

SOA -or at lest, the definition that I pick out of the dozen available
;) - isn't really anything new technically, at least at a conceptual
level. Using SOAP rather than IIOP adds a bit of readability while
decreasing a bit of performance but that's pretty much it. The "how"
(technical) part of the equation changes a little, but not much - and
neither do the pitfalls, as you all have already noticed.

The novelty is actually supposed to be at the (argh) "architectural"
level - that is, in "what" is exposed.... which are supposed to be
services related to the business you're dealing with. For example, if a
company deals with selling books, then there should be a set of
services that allow to perform the "buy a book" use case (or "value
chain") electronically, one for each of the business level steps which
are required ("say", "submit a pre-order", "check for availability",
"confirm order" and so on) (and incidentally, also to discover that the
company has a "buy a book" capability, which is what the directory
stuff is all about)

A company has a SOA when it can consistently perform business
interactions electronically, not just because some bit of functionality
is available as a webservice. Historically there has been a total mix
of which procedure calls in a software are "business" entry point and
which aren't - i.e. looking at the code, they all look the same, it's
just names and parameters that make a difference, and only to a human
reader at that.

So, SOA is supposed to concentrate business people on defining what are
the business processes that make up their organization - and then,
incidentally, have a set of technologies that allow their IT
departemnts to implement the results of such concentration efficiently.
But the first bit is the one that is potentially interesting... only
that most of the people that gets excited with SOA ain't business
people nor get the point that technology isn't the main issue, so I'm
not so sure on how it'll all go...

For example, exposing an "XML-PDF" translation makes sense in a SOA
only if, say, your company sells PDFlizations (which actually in dotcom
times could have been considered a bright business idea, but I
digress.. :-D).

If it doesn't - that is, if that translation doesn't have a meaning or
interest in business terms (say, the company's CEO doesnt know it
exists and couldnt care less) - then what you end up with is a rather
cumbersome way of doing a remote procedure call - nothing new, and
probably not that smart, as you've noticed.

Mike Bandor

2006-01-12, 9:57 pm

sdg wrote:
> Hello;
>
> I have just plowed through "Service-Oriented Architecture: A Field Guide to
> Integrating XML and Web Services", and have read some other texts on the
> subject.
>
> In the past I have developed in CORBA, and books such as "Advanced CORBA
> Programming with C++" were very helpful.
>
> Because of the multiplicity of languages/toolkits/etc., is it a vain hope that I
> would find a book as comprehensive as the CORBA one for a SOAP/WS-*/XML world?
> I am looking for something to help bridge my understanding of programming a SOA
> based world.
>
> Given the multiplicy of toolkits, once I pick a language and toolkit, am I stuck
> with that particular vendor's binding, just as we were in a CORBA 1.x world? So
> that if, for example, I am exposing C++, I have to pick Microsoft/gSOAP/Iona's
> kit and am stuck with them 'forever'?
>
> Also, some SOA advocates seem to be making some of the same mistakes as CORBA
> people of old, when EVERYTHING can be remote, with no impact to the local
> application, and no extra overhead or error checking. Would it be fair to say
> that anything that in the old-fashioned distributed world that I wanted local
> and therefore comparatively robust I would keep that way? Why would I want to
> service-ize my XML->PDF generation, when there are so many good libraries to do
> that locally (for example)? When by doing so, I not only have the normal
> XML->PDF failures to deal with, but networking and others as well?
>
> What have people done in the real-world with SOA arhitectures? What level of
> granularity have they been? What did the SOA-buzzword-compliance give you that
> would not have been as possible in another distributed system?
>
> Thanks
> sdg
>

The Global Combat Support System - Air Force (GCSS-AF) is a very large
implementation of a SOA. Here is a link to a presentation, albeit more
high-level than you would probably like, discussing it:
http://www.opengroup.org/conference..._4_-_Adams.pdf.
If you do a search in Google for GCSS-AF and SOA, you should find
additional information.

Mike

Sponsored Links