OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Re: Major Historical SOA Milestone Today

[ Lists Home | Date Index | Thread Index ]

SOA certainly has a lot in common with things that came before it. Is it a natural progression of OOP? Absolutely.

That doesn't mean we should simply dismiss the entire discussion and the technology / standards that have come along with it. The fact that we are all on this list means we have a certain amount of interest in XML, Web Services, and so-called "2nd Generation" web service technologies like WS-Policy, WS-Security, etc. Still, using these technologies doesn't implicitly make an architecture service oriented.

Rather than looking at how a system is built to determine its orientation, I think it is more helpful to look at its behaviour. A service oriented system has the following benefits, to name a few:

1) Increased Code Mobility - I can move an individual component from one machine to another, or even outside of the organization.

2) Higher Availability - I can have multiple redundant servers and focus QoS on specific functions or users.

3) Scalability - I can increase the capacity of my most heavily loaded services instead of having to deploy multiple copies of the entire application

4) Easier Deployment and Maintenance - I can develop, install, upgrade, and maintain each component of the system independently from the others. If there are protocol changes, I can use message brokering to bridge the gap. With a silo-type application, I have to upgrade the whole thing at once.

5) Open Messaging Formats - Today I can find several third-party products that can allow me to monitor the business-level behaviour of my system, introduce new QoS, security, fault-handling, or auditing behaviour, convert synchronous behaviour to asynchronous, etc...

Yes, people have found ways to achieve these benefits to varying degrees in the past - none of this is completely new. It takes a certain critical mass before new ideas become a trend, and before that trend gets its own name, like SOA. But trends are retroactive - the people who were doing message brokering and location-transparency 10 years ago can be smug and say "I was SOA before SOA." That's fine.

Now that the trend has been identified, however, we get to benefit from adoption and support by standards groups, industry, and the open source community. Thanks to widespread adoption of OOP, OO programmers "never having to implement a stack again". As "refactoring" caught on as a buzzword Java developers gained the use of excellent toolkits for implementing the most common patterns. Thus, as SOA becomes more widely used and understood, versioning, redundancy, location transparency, auditing, scalability, etc. will become easier and easier.

Well defined or not, dismissing SOA as a passing trend would be like throwing the baby out with the bathwater.

Cheers,

Erik

> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com] 
> Sent: May 12, 2006 7:42 AM
> To: 'Richard Salz'
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Re: Major Historical SOA Milestone Today
> 
> >  But more importantly, type hierarchy doesn't seem to scale.  
> > Your payroll example seems to make every service an object.  
> > Can you take that example further and describe some other kinds of 
> > objects that might exist?  And show the hierarchy?
> 
> If you're a bank then you deal with trading partners. That's 
> a type with many instances, who all, at some level of 
> abstraction, exhibit the same interface to the bank. The type 
> "trading partner" also has subtypes, for example foreign 
> exchange dealers, stockbrokers, other banks.
> 
> Identifying this type hierarchy in my view can be of real 
> practical use when it comes to message design. Some of the 
> types might even map reasonably directly into type 
> definitions in an XML Schema - though that's perhaps 
> optimistic. But it can certainly help the analysis.
> 
> Of course one could argue that we're not using OO concepts 
> here, but rather the basic ontological methodology on which 
> OO concepts were based. But that's hair-splitting.
> 
> Michael Kay
> http://www.saxonica.com/
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 
> 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS