RE: Application design & architecture

midrange-l-bounces@xxxxxxxxxxxx wrote on 05/09/2006 10:52:29 AM:

Chris,

> I like to think that I am a reasonably intelligent man, but I have to
> admit that I still have no idea what SOA is. I know that "SOA is
> Architecture. Not technology. Not hardware. Not software." And I have
> also learned that "your FTP solution could be SOA." And that it seems to
> make people think of web services and for whatever reason XML?

There has obviously been a lot of hype surrounding web services which can 
confuse things.  I would loosely define a web service as some kind of 
message, typically XML, being exchanged over a web protocol, usually 
http(s).  Most often this would be something like SOAP or XML-RPC but it 
could also be something that is lighter weight like a custom XML format in 
a REST or AJAX scenario.

I think what happened is that people started to realize that there were a 
lot of variations that this could take, and also that it was not very 
different from what people might have already been doing.  So the term SOA 
was coined as an umbrella to cover the general practice.  I would define 
SOA as what we might have called a message-based architecture.  For years, 
Joe Pluta has been describing an SOA to all of us when he has advocated a 
design that uses data queues to exchange messages between client and 
servers.  Lots of iSeries shops have probably done something like this on 
a small scale using data queues or maybe even MQSeries.

So when people are talking about moving towards an SOA it mostly involves 
a best practices idea of decoupling your business rules from your user 
interface and using some kind of message-based approach to expose those 
rules.  Once this is done, it becomes easier to reuse that business logic 
in new ways and also to integrate different applications.  Anything that 
can send and receive a message can use the application.

One approach to exposing your SOA is to use web services.  Web services, 
such as SOAP, can be fairly heavyweight so they are not always going to be 
the best solution.  But if taking advantage of http(s) for the protocol 
and/or being able to exchange information with partner applications via 
the Internet makes sense, then web services can be a good approach.  If 
your applications are purely internal, in many cases it would make more 
sense to build an SOA on top of data queues or MQSeries or something like 
that.

An advantage you can potentially get in the long term from taking a web 
services approach is that you can start to take advantage of things like 
BPEL which lets you model and choreograph business processes.  I do not 
have a good feel for how many businesses could actually benefit from stuff 
like this, but it looks like something that could be interesting for 
larger corporations that have lots of applications and processes that they 
want to integrate.

Another nice thing with web services is WSDL, which is an XML document 
that describes the service.  This can be consumed by tools, such as WDSC 
which can then do a good job of generating starter code for using the 
service.  This code generally hides the boiler-plate protocol level 
details from you and lets you treat the service as just another object, 
which simplifies application development.

Finally, it is worth pointing out that if you design your applications for 
an SOA and have decoupled your RPG-based business logic, putting a web 
services front end on it, when/if it is needed, is generally not that 
difficult to do.  The hardest part is decoupling the logic and moving to a 
stateless message-based system.  Once that is done, it is not that hard to 
put different front ends on the messages. 

Mark




_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email 
Security Management Services powered by MessageLabs. 
_____________________________________________________________________________