Java developers who responded to a recent survey put out by CodeFutures, a Java persistence software vendor, showed both strong interest in SOA development and frustration with application production.

Over 75% of those surveyed responded positively to the idea of SOA development, revealing at least widespread acceptance of Web services as mainstream. In addition, those groups maintaining C++ applications acknowledged interest in using C++ Web services.

Developers also admitted to scalability problems, and the majority of participants responded positively when asked whether their applications had high performance requirements or unmet high throughput requirements. This sentiment may be reflected in the POJO movement gaining traction.

Of course, this being a vendor-sponsored survey, these results come from a skewed audience -- which CodeFutures readily admits in the survey text. However, it does leave the reasons for production problems up for debate, and also begs the question: Are SOA and Web services technology being viewed as mainstream in the Java community?

I doubt that usage of the talkative Web-Service-Protocols will solve any bottlenecks. And for me SOA is just another buzz word flying around. Mix SOA, Offshore-Development and MDA and your manager goes crazy about the resulting buzz-cocktail.

Mike

Erl has a nice but big book on Service-Oriented Architecture (Prentice Hall) where he discusses the "contemporary" definition of SOA. He says the current definition is web service-centric. It's not required but assumed.

I have to think that people are waiting for WS-Security and WS-ReliableMessaging to be more transparent and fulfill nonfunctional requirements you can meet with current J2EE app servers. The great thing about Stateless Session EJB remoting is the ability to pass a security and transaction context, or even XA. Once you get the messaging A HA moment and then start modeling and expose services via MOM and SOAP you run into the problem of managing all this orchestrated crap. Yeah, there are tools but at a price. Hermes is a start.

I am following ServiceMix and Mule. The difference seems to be that ServiceMix starts with WSDL while Mule starts with object interfaces. Until then non-schema constrained XML messaging via XStream seems to cut it.

...Once you get the messaging A HA moment and then start modeling and expose services via MOM and SOAP you run into the problem of managing all this orchestrated crap...

Note: I work for Xcalia.
This is exactly the value proposition of Xcalia Intermediation Core. By using service metadata to intermediate and dynamically compose services at runtime, you are free from this burden. Before you bash me for recommending it, at least try to understand it:

Design-time:
1. Describe your databases (any kind, relational or otherwise) & services (any kind, web services, EJB session bean, or anything else callable from Java) using metadata.
2. Build a POJO model that captures the business adequately.
3. Build a composite application against the domain model and a persistence API (JDO & SDO now, EJB in the future).
Runtime:
4. Your composite application manipulates the POJO model.
5. XIC dynamically invokes whatever services and databases necessary in response to the work done on the POJO model.

These are the broad strokes. If you don't understand it right away, that's ok; I guess I suck at explaining it. It does take a while to wrap your brain around it, though. An easy way to understand it is to realize that dynamic composition does for orchestration in an SOA what ORM does for writing SQL code -- frees you from the burden of writing it.

--matthew

Mule is looking like the new Spring, I'm also following with great interest.

Leaving aside the hype and greediness boiling around SOA, my opinion is that SOA based in WS-* (i.e. not abstract SOA) is the platform of the future, which will allow to run, interoperate with, integrate and reuse most software developed by anyone. It will deliver the long soughted goal of reuse of code, in practice.

It is not that WS-* it is the best technology or that it is superior to other ones doing the same (CORBA, Jini, RMI, DCOM, whatever). It is that everybody supports it. This delivers interoperability in practice, not in theory.

More about this at http://javicamara.blogspot.com/2006/01/soa-platform-to-rule-them-all-and-in.html .

I do not care whether it is WS-*, REST or whatever, but we need such a universal interoperability framework in practice. WS-* is the best positioned to be so, because the key is not technology, but endorsement.

SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.)

BTW - SOA is the mainstream of for Federal government work these days.

Did someone use the word "mainstream" and "Federal government" in the same sentence? I have spent 12 years working in Federal Gov't IT, from civilian agancies to NASA, DOD and Postal. I have never seen anything consistent across gov't architectures.

The guys down the hall from me are using Delphi version 5 for a government job.

Mike

Please do not bind or equate SOA with XML.

Web Services certainly can be implemented so that they provide the behavior one would expect from a Service-Oriented-Architecture, but they are not a necessity.

As far as Java goes there are many SOA-ready technologies not the least of which is Jini.

http://java.sun.com/developer/technicalArticles/jini/protocols.html

If only someone would wrap bluetooth in a jini proxy -just think of the fun Java could have! (Shameless query to learn if this has been done or is in the works. . .)

Any takers?

Owen

You are correct when saying that loose coupling and reusability are the true hallmarks of an SOA system. It would be better if you said "SOA != Web Services" since that is the more common mistake. While SOA != XML as well, XML is much more "SOA ready" than something like Jini. Jini requires Java awareness, usually through a proxy. That is hardly loose coupling. The adoption of web services and SOAP is largely because of the interop problems caused by things like Jini proxies.

Well, reading suggestion might sound offensive but it is not my aim.
There are some interesting articles in ICE Connections (www.zeroc.com) about web services and decoupling that might be useful.

Guido

While SOA != XML as well, XML is much more "SOA ready" than something like Jini. Jini requires Java awareness, usually through a proxy. That is hardly loose coupling. The adoption of web services and SOAP is largely because of the interop problems caused by things like Jini proxies.

Excuse me whilst I cough, but I believe that XML is no more SOA ready than any other _data_ format. Even though you are correct that Jini requires java - it only requires java somewhere on your network. The decision to not look at cross-language problem was key in Jini, which essentially the SOAP concept renders inert, because every language has XML right!?

http://blogs.sun.com/roller/page/jag?entry=only_solve_the_problems_you

SOAP is a protocol, XML is a data format, just like JRMP is a protocol and serialized java objects are a data format.

Protocols and Data formats do not a SOA make.

SOA is about the contracts between service and client, and how you can meaningfully use these contracts and services together, dynamically, to provide your architecture.

IMO, SOA is far too focused on the business process arena; Services should be exposed much further into your infrastructure to provide re-use further inside your applications, so that services themselves depend upon other services. Because of this current focus, Web Services gain adoption, exposing business processes to third-parties via services and using XML as a transmission format - great, but this is not what Services Oriented Architecture is all about, it's really only a tiny fraction of SOA. There are things about SOA that many people ignore; partial failure, clustering, failover, etc.

My main gripes about Web Services et al, are about how long it takes to actually standardise and mobilise these standards-infatuated companies to actually push proper specs and implementations out the door.

Did someone use the word "mainstream" and "Federal government" in the same sentence? I have spent 12 years working in Federal Gov't IT, from civilian agancies to NASA, DOD and Postal. I have never seen anything consistent across gov't architectures.The guys down the hall from me are using Delphi version 5 for a government job.Mike

Yeah, I've contacts in DOD contracting and I've heard the same sort of thing.

SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. [rest deleted]

I agree that SOA does not necessarily need to be implemented using Web Services, but I do think that one of the primary shifts from traditional n-tiered architectures is the idea that SOA should support "easy" interoperability. So, if you're using Tuxedo and C to deploy things that ostensibly look like services, but require clients to be written with a specific language or toolset, I don't think that it would meet the definition that most architects use for SOA. However, if you were to provide access to those same services via XML messages (for easy interoperabilty) over an easily accessible transport mechanism, then it would certainly meet my definition of SOA, even if Web Services standards weren't followed.

I also see SOA as a computing architecture that goes well beyond the implementation specifics of web services and XML. I see developers specializing in one or more of the building blocks that go into an SOA - Identity Management, Service Policy, Security, Workflow, Service Management, Quality of Service, to name a few. I am currently in the process of putting together a web site to demonstrate SOA from concepts through architecture to implementations.

http://www.soamodeling.org

It is based on work by the OASIS SOA Reference Model Technical Committee. The SOA RM TC currently has a SOA Reference Model document open for public review. Public review comments are encouraged.

http://www.oasis-open.org/committees/download.php/16628/wd-soa-rm-pr1.pdf

Danny

I agree that web services technologies makes services more interoperable. Tuxedo/C and CORBA, etc. were less capable from that stand point. I'm just saying that deploying services - web or not - does not make an SOA. Its the underlying architecture - effectively an n-tiered component based architecture that makes it SOA. Components are service ready though many are too fine grained to be used as remote services. What components have are contracts, encapsulation, independent deployment and versioning. You can easily compose services from one or more components by adding a service facade in front of them. That is where the reuse and other benefits touted for SOA really come from.

BTW, are you the Dru I used to know in Chicago?

I agree that web services technologies makes services more interoperable. Tuxedo/C and CORBA, etc. were less capable from that stand point.

Oh no, this is too much!!
Do you really think that CORBA is less interoperable than web services ?
When you say this, do you refer to the specs or to particular implementations ?

Guido

BTW, are you the Dru I used to know in Chicago?

Hi Bill,

Yep, that's me. :)

Dru

SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.) BTW - SOA is the mainstream of for Federal government work these days.

IMO SOA is nothing more that a new word to spread to try to
sell something (old products - beware, I don't mean bad here - in the case of ESB).
There is really nothing that you can't do with plain-old-DOC-framework (namely CORBA and ICE from ZeroC).
Yes, SOA is not WebService, sure!
Please, can you tell me a SOA not based on web services ?
It is funny to read in the survey the suggestion about vendors lock-in avoidance.
Want to talk about server-side JAXRPC specs ?
CORBA is lightyears far away for what concerns portability on both client and server side.
But now we have SOA that automagically gives perfect architectures !!
No, stop! Noone said that SOA is a one-size-fits-all !!
Strange, the percentages in the survery seem to show something different.
Anyway, it's a deja vu. It was the same with J2EE.
And now to leit motiv is: don't use J2EE if you don't have a good reason to, use SOA!
Until the next silver bullet with someone saying (maybe the same SOA-based products vendors): YOU were wrong using SOA for everything !

Guido

Hearing Alanis Morissette (Crazy) in the distance....

Please, can you tell me a SOA not based on web services ?

Guido,

I've been implementing SOA since the early 1990's. In the 1990's Tuxedo was the best middleware for implementing SOA. Java EE application servers are pretty much modeled after Tuxedo which is why it was so easy for me to transtition to them around 1999. CORBA could also be used for SOA and I know some folks who claim to have done so. Of course using either technology, or web services for that matter doesn't make it SOA. There is more to it than the technologies you use.

Bill

Guido,I've been implementing SOA since the early 1990's. In the 1990's Tuxedo was the best middleware for implementing SOA.

Yes, I remeber. Maybe the name of the architectures was different at that time :)

Java EE application servers are pretty much modeled after Tuxedo which is why it was so easy for me to transtition to them around 1999.

I have a clear memory of an IBM framework to invoke CORBA object via HTTP URLS where XXX object were created using XXXHome....
At that time Java was at version 1.1 (maybe 1.2).

CORBA could also be used for SOA and I know some folks who claim to have done so. Of course using either technology, or web services for that matter doesn't make it SOA. There is more to it than the technologies you use. Bill

I feel like vendors saying something different.....
I am really tired..

Guido

SOA seems to be this year's buzzword. It is hard to get excited about it. It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same. Call it what you want.

Even if the term SOA had a meaning by the time vendors get done with it.... it will not have a meaning any longer.

It is a floor wax and tooth paste. It whitens your teeth and cleans your grout.

SOA. SOA. SOA. SOA. Samiliaaan. (music)

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

SOA seems to be this year's buzzword. It is hard to get excited about it. It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same. Call it what you want.Even if the term SOA had a meaning by the time vendors get done with it.... it will not have a meaning any longer. It is a floor wax and tooth paste. It whitens your teeth and cleans your grout.SOA. SOA. SOA. SOA. Samiliaaan. (music)Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting

Whether ideas and technologies succeed or fail is largely down to timing. Is the business and technological environment right for them? The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation. Yes, we have heard it all before with things like CORBA, but I think the difference with SOA is that the timing is better. There are more technologies available to support the model that have been tried and tested. Things like Java, XML, JMS, WSDL, WS-Security.

I work for a very large global organisation. Most integration up to now has been point-to-point. No one has, or even no small group of people have, a complete picture of what systems we have out there doing what. It's difficult to quantify, but I reckon the costs resulting from such complexity runs into $millions. In these sort of environments, something SOA-like is desperately needed.

If you are concerned with individual projects, SOA may be less obvious. But put your project within the long term landscape of systems and assets a company owns and SOA should be a bit more meaningful.

Regards
Kit

The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation.

How will that work when more often than not one programmer can't explain the interface to his class to the programmer sitting next to him?

I know, I'm mixing metaphors (or something like that). The said programmer probably can (with a little training or reference material) write a magical SOA descriptor for his class (or service, or whatever you want to call it). But that doesn't change the fact that no one but him understands what it does.

The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation.

How will that work when more often than not one programmer can't explain the interface to his class to the programmer sitting next to him?I know, I'm mixing metaphors (or something like that). The said programmer probably can (with a little training or reference material) write a magical SOA descriptor for his class (or service, or whatever you want to call it). But that doesn't change the fact that no one but him understands what it does.

This is a good point.

One of the things that companies creating service registry products have realised is that creating a service doesn't mean that everyone will magically use it, even in closed internal environments. Newer registry products have alot of space where the service designer/developer can document their service, including constraints, contracts, QoS, etc.

Quite apart from detailing the service technically, it can also act as a marketplace for services.

Regards
Kit

It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same.

Precisely - which is exactly why
  - SOA has been called Same Old Architecture by some insightful cynic
  - i argue that if we also remove webservices from the definition of SOA (as some have argued here) then we are left with...nothing at all. If SOA, however, means "the Same Old Architecture implemented on top of the webservices stack", as it does in my perception of reality in 2006 anyway, then we are at least left with a term that carries some meaning.

  cheers,
  gerald

http://www.gerald-loeffler.net

SOA definitely doesn't mean Web Services. The site I work on is very service oriented, we dispatch to the services using all kinds of various methods:

 - Straight HTTP (REST-ish)
 - MQ
 - EJB
 - JINI
 - and some Web Services

The product vendors may be rallying around Web Services but you can certainly do SOA without them.

SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.) BTW - SOA is the mainstream of for Federal government work these days.

I'm repeatedly shocked at how few people actually understand this concept. William is 100% correct. The WS-* stack is simply one of many wire protocols for services. IMO, nothing about SOA requires you to use web services.

The survey is been conducted by a vendor whose products are into persistence tier. I am kind of surprised about CodeFutures conducting this survey where SOA is not their primary business.

My personal experience with many of SOA product implementation in a supply chain management domain with large Rosattanet XML documents was quite bad. Especially the Java XML parsers are too slow to provide a good infrastructure for this development. The performance was horrible!!!

Does anybody know what exactly SOA is? Can we have a list of differences between a SOA and non-SOA system?

As far as I know it's all about decoupling and there is nothing specific about a technology like web services! So to me it's more a concept and practice than a standard or specification.

You are doing SOA, as long as you are delivering decoupled components.

Hi,

the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design.

As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.

Chris

Hi,the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design. As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.Chris

Based on your description, it sounds like something we should all consultants should learn as their is money to be had. Darn truth serum! :o)

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

Hi,the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design. As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.Chris

Based on your description, it sounds like something we should all consultants should learn as their is money to be had. Darn truth serum! :o)Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting

Let me try that again.

Based on your description, it sounds like something all consultants should learn as their is a lot of money to be had. Darn truth serum! :o) (Too much serum!)

I am saddened by seeing developers humming along to marketing tunes.

SOA is an architecture that includes the following repeatitive phases :
1. Modeling
2. Assembling (Development)
3. Deploying
4. Monitoring
and go again in that cycle from start. Development is just the second phase.

WebServices don't provide transactions at the moment, so the only thing you can integrate with them is something as mission-critical as a weather service and a socks selling website. Corba or MoM does better with it.
Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten.

Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten.

Ditto! I'm seeing exactly the same thing on a large scale SOA project I'm working on at the moment.

The Service contracts are being drawn up by business analysts in practical isolation. They view the contracts purely on a document basis with little/no regard for how those contract definitions will get consumed by the end user i.e. when Java stubs are generated from them, the resulting model is a mess and the stubs would be a pain to use.

I think there needs to be more balance in situations like this. Sure these contracts can be viewed as business entities blah blah blah but at the end of the day some poor developer is going to have to use them. If they're a steaming pile of unuserfriendly poo????

Of course, I do believe it is possible to draw up solid contracts that translate into usable interfaces at a code level. I just don't think it's likely to happen when these contracts get thrown over the wall by analysts.

The Service contracts are being drawn up by business analysts in practical isolation.

Are you using any formal development process (eg. Rational Unified Process)?

According to RUP interfaces (especialy the high level ones) should be specified by the architect (architecture team). Architect is the person who understand both business and technology aspects of the system. And interfaces are extremely "architecture-significant" elements of the system.

And in my opinion low level interfaces shouldn't implemented as WebServices.

Marquis de Flore
IBM RUP Certified
www.enterpriseware.pl

Are you using any formal development process (eg. Rational Unified Process)?

The requirements gathering and analysis process is RUP based. The whole process is a mishmash of RUP and SCRUM and prob others. I'm not sure where it came from!

According to RUP interfaces (especialy the high level ones) should be specified by the architect (architecture team).

I guess I meant that somewhat tongue in cheek, but in my situation it is the case that the analysts "own the public interface". If they don't like something that goes in there it comes back out, but not necessarily the other way around. I'm sure the architects have (on paper at least) a degree influence, but I'm not convinced how effective it is. Of course a lot of this could be the individuals involved - we're talking about a large org here so I'm not totally familiar with all the personalities.

I personally think the interfaces needs to be modeled in an iterative way with feedback coming from all levels - analysts, architects, dev, qa. These business interfaces are used by different people in different ways and, as much as possible, should be user friendly to all. I think this requires an iterative process and no one group should "own" anything.

I think this requires an iterative process and no one group should "own" anything.

I totaly agree about the iterative aproach and feedback from different users but it is a good practice that every artifact has a person responsible for. (and the basic management rule says that if someone is responsible for something he also has to have decision making permisions for it - no one wants to be responsible for someone else decisions).

If many people are responsible for something it means no one realy cares. It is especialy true in large organisations :-)

Marquis
www.enterpriseware.pl

...it is a good practice that every artifact has a person responsible for....

I totally agree with you, someone/somegroup always needs to have ownership and responsibility. I guess what I'm really saying is that no one discipline should own something as important as this. Perhaps that means some sort of "overview" type group which has representation from all disciplines. If it fails after that, these people get their asses kicked.

Another point on the responsibility and ownership topic. I often see that because organisations reorg at sometimes ridiculous rates, it ends up that nobody is effectively responsible anyway because by the time that crap decision starts a fire somewhere, the person that made it is off working on something else and whoever "owns it" now simply blames the reorg and the fact that they didn't make the decision.

Another point on the responsibility and ownership topic. I often see that because organisations reorg at sometimes ridiculous rates, it ends up that nobody is effectively responsible anyway because by the time that crap decision starts a fire somewhere, the person that made it is off working on something else and whoever "owns it" now simply blames the reorg and the fact that they didn't make the decision.

From the Tao of Programming:

A novice asked the master: ``In the east there is a great tree-structure that men call `Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying `Go, Hence!' or `Go, Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity be?"

The master replied: ``You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?''

Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten.

Ditto! I'm seeing exactly the same thing on a large scale SOA project I'm working on at the moment.The Service contracts are being drawn up by business analysts in practical isolation. They view the contracts purely on a document basis with little/no regard for how those contract definitions will get consumed by the end user i.e. when Java stubs are generated from them, the resulting model is a mess and the stubs would be a pain to use.I think there needs to be more balance in situations like this. Sure these contracts can be viewed as business entities blah blah blah but at the end of the day some poor developer is going to have to use them. If they're a steaming pile of unuserfriendly poo????Of course, I do believe it is possible to draw up solid contracts that translate into usable interfaces at a code level. I just don't think it's likely to happen when these contracts get thrown over the wall by analysts.

Hmmmm.... I am not sure this is a problem with SOA or just stupid developers. Some folks tend to take an idea and pound it to death.

Example: I've seen this "if design patterns are good, then I should try to use every design pattern in the book". I've seen it done, and it ain't pretty.

Another Example: I've seen people do some strange things with AOP and DI. This does not mean AOP and DI are bad.

Unlike AOP and DI, SOA will become a very large marketing mumbo jumbo mess and will loose all meaning.

Our XYZ product is fully SOA compliant.

SOA already seems to have so many definitions that the term is near useless.

Of course it goes without saying that Design Patterns (DP) are good. But, like anything (SOA), they can be misapplied.

I was refering to using DP just for the sake of it (and as many as they could. You could tell where they stopped reading in the book b/c those DPs were not there.)

Of course it goes without saying that Design Patterns (DP) are good. But, like anything (SOA), they can be misapplied.I was refering to using DP just for the sake of it (and as many as they could. You could tell where they stopped reading in the book b/c those DPs were not there.)

Here. I'm in total agreement with you. It's called the Golden Hammer syndrome/anti-pattern... "if all you have is a hammer, everything looks like a nail!".

I'm also in agreement with you re AOP and DI. Are you working on the same project as me by any chance ;-)

On AOP, I've always sorta avoided using AOP because I always seemed to be able to find another way of doing whatever I was trying to do without AOP. I'm a conservative sort of guy - been burned too many times before. I've been waiting for a project where someone with AOP experience could show me how to use AOP sensibly. So, along came the project I'm currently working on and there's AOP.... loads of AOP... in fact, the way things are going we're soon going to just have empty main methods with Spring configs full of interceptors. It's a royal PITH in my opinion. An interceptor is the answer to every problem. So, I guess I've learned how not to use AOP at any rate!

This goes for anything - AOP, DI and whatever else you're having... There's usually a place for them all, but not on every project or every problem...

Example: I've seen this "if design patterns are good, then I should try to use every design pattern in the book". I've seen it done, and it ain't pretty. Another Example: I've seen people do some strange things with AOP and DI. This does not mean AOP and DI are bad.

Usually the victims of Pattern Compulsive Disorder also fall prey to the "let's find a convoluted way to use AOP because it's cool" mental disease. The consequences are disasterous.

Unlike AOP and DI, SOA will become a very large marketing mumbo jumbo mess and will loose all meaning.Our XYZ product is fully SOA compliant. SOA already seems to have so many definitions that the term is near useless.

I'd say it has already lost all meaning and become utterly useless. Just re-read this whole thread and count the number of meanings: to each his own. It's a new concept but everyone was doing it 20 years ago; it's entirely XML/WS*-based but has nothing to do with XML/WS*; it's a paradigm and a philosophy... Etc ad infinitum.

I'm sure sinners use SOA whitepapers to fuel the furnace in hell.

I'd say it has already lost all meaning and become utterly useless. Just re-read this whole thread and count the number of meanings: to each his own. It's a new concept but everyone was doing it 20 years ago; it's entirely XML/WS*-based but has nothing to do with XML/WS*; it's a paradigm and a philosophy... Etc ad infinitum.I'm sure sinners use SOA whitepapers to fuel the furnace in hell.

But that has as much to do with ignorance than ambiguity. Much of the definitions of SOA on this thread seem to be loaded with ignorance.

(The rest of the post is not aimed at the previous post).

We all know what object orientation means now because people had time to define it's meaning and come up with some clear definitions. It too had been around in practise for a long time before it became distilled into languages and hit mainstream appeal. It had mainstream appeal because the complexity companies and developers were dealing with was exploding, the complexity of systems in even small companies was requiring a paradigm which helped to manage the complexity.

SOA is no different really, it's a concept that's bean around for a while but has not been a priority for many companies since they have had a handful of services and systems. Now with the IT systems explosion even small companies can end up with dozens of little IT systems. So it's now a priority to reuse existing services rather than existing code and to manage the complexity again with a paradigm that encourages you to abstract a complex system into smaller subsystems. In time the definitions will become clearer also.

To me the parallel is very clear and SOA unlike AOP has immediate and large scale usages and appeal. The ignorance comes when developers see the usual nonsense trotted out by venders to sell their SOA systems.

So stay clear of the nonsense, look carefully at some of the developer friendly SOA products (like Mule) and see how it allow us to work at a higher level of abstraction at development time, not just at design time.

There is no reason SOA would necessarily break OO designs. SOA extends component based architecture, but services realize use cases. The components you compose services from are high level objects from your object model. Components are not pure problem domain objects themselves. They are controllers that wrap objects that implement certain functionality. CBA derives from OO but incorporates notions of frameworks and architecture. Though individual components may become services, they are often too fine grained to be good services. They may not be a complete unit of work either. CBA is the parent of SOA and its certainly consistent with good OO design.

Investigate component-based architectures to get a better understanding of components and how to define and implement them. Amazon has some good books on the subject.

Subterfuge Obfuscation Addle

Is SOA a buzzword - sure. The IT industry is always going through buzzwords. Remember Component based development and Client server? In all cases they are just a way of thinking and have nothing to do with specific technology per se.

So you can build a SOA using pretty much anything at all from files, to MOM to CORBA to Tuxedo to HTTP. Pointy brackets are not manadatory :). The simplest way to start building a SOA is typically just to use a MOM; then all you need to worry about is getting messages on and off the bus - not grokking the whole WS-* and the issues of getting different vendors WS-* to work together.

FWIW I remember working on my first SOA back in '89 (yes I am that old :-) at JP Morgan where we had a distributed trading system with real time pricing, P&L, position keeping, order matching and settlement gateways live in multiple countries over WAN & LAN. Back in those days we wrote our own SOA technologies in C/C++. Thankfully these days you can just reuse a bunch of great open source code to make a SOA - most of what you need is all at Apache these days.

I tend to think of the talk of SOA as similar to that of Design Patterns; a discussion of best practices which you can implement using whatever technology you choose.

James
LogicBlaze
Fuse: the Open Source SOA runtime

After reading these posts I get the feeling SOA is too lofty and out-of-the-scope of mere developers. Maybe it has to be bought on the golf course by CIOs and crammed down the throats if IT as a top-down strategy. Sounds like this group is at the "expose an api as a web service on an ad-hoc basis or setup an internal queue" level of adoption.

On Maslow's Hierarchy of Needs, SOA must be on the high end for most developers or even companies. I don't hear developers being forced to use an existing package in these posts.

The trends that will drive SOA as I see it are mergers & acquisitions driving integration, Microsoft parity, and continuous flow batch processing across cheap boxes. Sort of [email protected]

Services are an abstraction and don't dictate web services. But! Web services are driving the latest CORBA-esque markitecture. Yes, old wine in new bottles but the wine has aged a bit and mellowed. Sommalier oriented architecture.

-andrew

Developers also admitted to scalability problems, and the majority of participants responded positively when asked whether their applications had high performance requirements or unmet high throughput requirements. This sentiment may be reflected in the POJO movement gaining traction.

I believe the POJO based approach for SOA is the right way to go. Projects like mule provides a very good reference on how this could be accomplished.

"Stateful SOA applications are distributed applications that require integration with each other on two dimensions: communication and state. Many workflow scenarios fall into this category, as well as distributed computing applications. Normally, state iz shared through a centralized resource - such as a file system or a database which often creates a scalability and performance bottleneck. Maintaining consistency in such environments also requires the use of a distributed transaction coordinator with an XA interface, which significantly impairs performance. Typical deployment environments require three separate sub-systems: messaging, database and transaction coordination, which significantly add to the complexity of such environments from a programming perspective (complexity of APIs and number of APIs). From a deployment perspective, maintaining high availability in such systems often involves integration of separate high availability solutions for each of the three sub-systems. From a cost and licensing perspective, this approach can be relatively costly as it introduces a need for multiple licenses, often from different vendors. This lack of efficiency also results in a requirement to use additional costly hardware resources to meet the application's scalability and performance requirements."

You can find more detailes on this approach in the following paper:

Stateful Service-Oriented Architectures Using Mule and GigaSpaces

You can try a free version using the following url:
http://mule.codehaus.org/JavaSpaces

Nati S
CTO GigaSpaces
"Write Once Scale Anywhere"

Excuse me, but I remember, I heard a lot of these arguments 20 years ago, when I argumented for using OO. 'Nothing new here', 'You can do this in Cobol or C too' etc.
Never mind if the arguments were right or wrong, it is unquestionable, the OO sat focus on modelling and encapsulation, and so did a lot to quality and reuseability.

Same thing with SOA, a lot of discussions on technical aspects (no offending, because we are technicians), but the important part of SOA is, that it sets focus on modelling with services, which are high-level, business things, and so will do lot to quality and reuse, I hope.

/Hardy Henneberg

What's SOA all about after all?

Is it SOA a component architecture with a OPEN, EASYLY IMPLEMENTABLE, WHICHEVER IT IS, communication stack?

What's SOA all about after all?Is it SOA a component architecture with a OPEN, EASYLY IMPLEMENTABLE, WHICHEVER IT IS, communication stack?

Simple! It stands for Service Oriented Architecture.

It is a term coined by service providers used to refer to an architecture that will lead to increased sales of services.

IBM Global Services estimates that for every customer that it convinces to switch to SOA there will be a 75% in revenue (meaning IBM will sell more services).

Other, smaller service providers are expecting even greater increases in revenue from customers transitioning to SOA.