James Robertson pointed out Cote's quote about SOA: "What makes 'SOA' different than 'programming'?" It's worth asking. What makes SOA so desirable that people flock to it? Is it really an improvement? The full quote is a little more involved:

Long ago, when I was working at The Cobalt Group as a young J2EE developer, my pal JP schooled me on the idea of building your code as a series of services. It made complete sense, at a code-monkey level, and was great for both the technology and (more importantly) the way you could run the organization. Somewhere along the lines, the architectural simplicity that JP outlined for me, an early understanding of "SOA," was widened to mean "whatever (enterprise) software we're currently selling." And that, is the "vendor [crap]" that Bray mentions above. Increasingly, I find that large vendors use SOA to describe whatever it is they have and are selling. Under the covers, sure, it may be that services-based, distributed, HTTP/XML (or events/ESB) system, but at the marketing level, it's a bit more, as I said, "hijacked." The question I've started asking when I hear a story about how much better a customer's IT-scape is doing because it's now got "SOA Inside!" is "compared to what?" That is, what were the alternatives? The snarky, between the lines question being, "what makes 'SOA' different than 'programming'"?

So what about it? What defines SOA, and what really makes it better?

So what about it? What defines SOA, and what really makes it better?

I think at least the second question is meaningless. What makes C++/Java/COBOL different from programming. Well nothing. Generally I have now seen the good, the bad and the extremely ugly of SOAs (and have written a book about it). There are many problems with SOAs that, as so very often in our business, come from various sources, like wrong expectations, focus on vendor/technology, lack of technology and so on. The main definition, for me, is that in a SOA the "business service" rather than the "application" or the "library" is the main artifact of the architecture. This is not easy to convey, because most projects are essentially about "applications" and a SOA puts an overhead on these projects in its initial phases. Of course a SOA must meet certain constraints beyond that. Some that come to mind in no particular order: The architecture must be version stable from the point of view of the client. So, either, multiple "versions" of a service must be runnable in parallel, or clients of a service must be able to transparently access new versions. Management must understand that a SOA implementation is an ongoing process and that there will be transition period. The transition cost is quite often underestimated, since a service fully meets its purpose only, if at a certain point in time, all access to the underlying business functionality is through the service. This in turn means rewriting or changing of applications. A SOA must have all the typical "technical services" that we commonly use. This includes things like logging, authentication, transaction management and so on. This includes that a SOA should have a well defined technical runtime. This may well includes various systems of various venders, but a zoo of different message busses, corba and ejb servers within a company may all define service, but they usually won't define a SOA. From an organizational point of view, providing the SOA should be a set aside task. If a SOA is ran and maintained by a project or a programme team, it will be the first piece of the infrastructure that is crippled because of budget/time constraints. This makes it attractive to attempt and buy the "SOA" from a vendor. The problem here is that various SOA products fail in terms of basic infrastructure and runtime constraints.

It used to be that you put XML on your resume in order to get a job. Now you put SOA on your resume in order to get a job. That's it. Really.

It used to be that you put XML on your resume in order to get a job. Now you put SOA on your resume in order to get a job. That's it. Really.

And if you are going to do that, only apply to clueless companies where HR is making the hiring decisions. With me you wouldn't get past the initial screening. Pretending to know something is worse than admiting what you don't know. At least would then think I could trust you and we could move on to discuss your analytical and problem solving skills. SOA is significant. Look past the hype.

It used to be that you put XML on your resume in order to get a job. Now you put SOA on your resume in order to get a job. That's it. Really.

And if you are going to do that, only apply to clueless companies where HR is making the hiring decisions. With me you wouldn't get past the initial screening. Pretending to know something is worse than admiting what you don't know. At least would then think I could trust you and we could move on to discuss your analytical and problem solving skills.

SOA is significant. Look past the hype.

Nice try. But, splasing sentance filled with "common places" revealed that you are just pretending. The only worse thing HR making hiring is when HR hire tech-blafer to do hiring.

It used to be that you put XML on your resume in order to get a job. Now you put SOA on your resume in order to get a job. That's it. Really.

 

Or, it used to be that you put XML on your resume, now you put "programming in XML" on your resume. 

And yes, I hate programming in XML.

So what about it? What defines SOA, and what really makes it better?

Just looking down the list of responses to Cote's posting and the marketing coming out of various vendors makes one thing pretty clear: SOA has many different meanings to many different people. There may have been a single, tightly defined meaning for this term way back when but there certainly isn't now. And the result is endless argument about what is the best way to do or implement SOA with no chance of resolution because there's no common understanding to allow reasonable comparitive analysis of suggestions, recommendations, solutions etc. There is the OASIS reference model: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm But I don't see everyone buying into that for various (political) reasons. SOA has become the donkey that everyone pins their hopes, dreams, jobs and products on. Yet, without a clear agreement on what SOA is, there's no way we can ever be sure that we pinned all of these things on the correct animal. Any day now, I expect SOA to be the solution to world famine!

SOA has become the donkey that everyone pins their hopes, dreams, jobs and products on. Yet, without a clear agreement on what SOA is, there's no way we can ever be sure that we pinned all of these things on the correct animal. Any day now, I expect SOA to be the solution to world famine!

SOA is simply the (old) (good) set of rebranded tools/applications/containers, used to sell the same old (sometime stupid) solutions to the same old problems. Guido

SOA has become the donkey that everyone pins their hopes, dreams, jobs and products on. Yet, without a clear agreement on what SOA is, there's no way we can ever be sure that we pinned all of these things on the correct animal. Any day now, I expect SOA to be the solution to world famine!

SOA is simply the (old) (good) set of rebranded tools/applications/containers, used to sell the same
old (sometime stupid) solutions to the same old problems.

Guido

SOA is not a product or tool (in the concrete sense) just like OO is not a product or a tool. It's a design approach. You need to separate the concept of SOA from the marketing hype around it. SOA in a nutshell is approaching your high-level design as a group of abstractions that allows components to work together in a de-coupled way. I see SOA as being similar to OOD in a lot of ways. Now you can say, "that's just good design" and I'll agree with you. The difference is that 'good design' doesn't convey much in a discussion and SOA is actually pretty specific despite what people are saying here. So yes, it's not a new idea, it's a new term for describing a pretty complex topic. This offers the same advantage as design patterns: the specific design patterns were not new, but having a single term to describe something complex is useful. The real value of SOA to me is that third-party products are being forced to open up non-GUI services in order to keep up with the SOA 'revolution'. This is no small thing. It's a huge kludge remover. For example, I was going to have to use screen scraping to enter data into a tird-party product but the vendor has decided to add a service for that task. I think the hype around SOA had a lot to do with it. These services are being seen as necessities whereas before they avoided adding integration points because they were seen as reducing barriers to entry for competitors. Companies want to sell you the whole suite of products, not let you pick and choose from theirs and their competitors. The hype around SOA makes that kind of strategy difficult to pull off.

SOA has become the donkey that everyone pins their hopes, dreams, jobs and products on. Yet, without a clear agreement on what SOA is, there's no way we can ever be sure that we pinned all of these things on the correct animal. Any day now, I expect SOA to be the solution to world famine!

SOA is simply the (old) (good) set of rebranded tools/applications/containers, used to sell the same
old (sometime stupid) solutions to the same old problems.

Guido

SOA is not a product or tool (in the concrete sense) just like OO is not a product or a tool.

Yes, in fact. Now I realize that I omitted an important part of my post, because I thought it was implicit. It would have been: SOA is quite often for the hugely paid vendor's consultant, the umbrella under which the..... Guido

Yes, in fact.
Now I realize that I omitted an important part of my post, because I thought it was implicit.
It would have been:
SOA is quite often for the hugely paid vendor's consultant, the umbrella under which the.....

Guido

A prefect example of the sad state of debate in the world. The funny thing is that I agree with your basic premise that most SOA marketing hype is just garbage. It seems to me that if you are going to reject a technology or concept purely because some ******* in marketing misappropriates it, you will end up rejecting pretty much everything in computer technology at some point.

I also would like to see an article *trying* to dismitify what are the problems adressed by which solution. For instance, how ESB and OSGi compare to each other. To me, the SOA newbie, they seem to have a lot of overlapp so it's kind of hard to know where to start.

I totally agree with Alexandre Poitras that wants to "dismitify what are the problems adressed by which solution ". there are way too much miscommuncation in the soa debate. In so many discussions that I have had about SOA in end of the disussion I have found out that I was talking about BPM and the other guy was talking about simple web services. We need a classification that clarifies the different kinds of problems SOA as a general term tries to bring a solution to. I found a presentation from the Norwegian conference, Javazone, that presents four kinds of service categories: - Human Interaction Workflow services - Application to application orchestration services - Aggregated/Composite services - Core services These service categories attack different problems and requires differnt solutions. For Workflow and BPM you might want to use Biztalk or some other BPM product. For application-to-application integration some kind of ESB or BPEL engine might be an good idea or maybe a message system. Composite applications might be implemented using some kind of lightweight framework as Mule or ServiceMix and core heterogenous services might be exposed by using some kind of web service framework. so, I might be a good idea to stop talking about SOA and start talking about the more specific problems and application domains that the SOA term addresses! http://www.chwlund.com

I've been doing computing day in day out for 25 years now. SOA is just the next evolutionary step in the way information is shared and the way we have computing interoperability. It's taken the computing industry about 30 - 40 years to evolve to the point where computers can start interoperating like businesses interoperate. I can develop computing systems to interoperate in ways that I could not do with the tiered enterprise architectures of the 90s. Danny Thornton http://www.soamodeling.org

I've been doing computing day in day out for 25 years now. SOA is just the next evolutionary step in the way information is shared and the way we have computing interoperability.

I've been going for quite some time myself. I don't see SOA as the next evolutionary step at all. There's maybe a business imperative for sharing information but that's been around longer than SOA as demonstrated by the creation of such things as EDI. SOA might be another way to share information but I think the jury is out on whether it's a step forward.

It's taken the computing industry about 30 - 40 years to evolve to the point where computers can start interoperating like businesses interoperate.

I don't think so - TCP/IP has allowed computers to interoperate for a long period of time. All you then had to do was create a standard protocol to use on top of that which is where things like XDR came in some time ago.

I can develop computing systems to interoperate in ways that I could not do with the tiered enterprise architectures of the 90s.

You didn't have to use tiers and you don't have to now and even if you did there was nothing to stop you making them interoperable unless of course you chose to build your systems on top of some framework that didn't provide the hooks for interoperation.

I've been doing computing day in day out for 25 years now. SOA is just the next evolutionary step in the way information is shared and the way we have computing interoperability.

I've been going for quite some time myself. I don't see SOA as the next evolutionary step at all. There's maybe a business imperative for sharing information but that's been around longer than SOA as demonstrated by the creation of such things as EDI.

SOA might be another way to share information but I think the jury is out on whether it's a step forward.

It's taken the computing industry about 30 - 40 years to evolve to the point where computers can start interoperating like businesses interoperate.

I don't think so - TCP/IP has allowed computers to interoperate for a long period of time. All you then had to do was create a standard protocol to use on top of that which is where things like XDR came in some time ago.

I can develop computing systems to interoperate in ways that I could not do with the tiered enterprise architectures of the 90s.

You didn't have to use tiers and you don't have to now and even if you did there was nothing to stop you making them interoperable unless of course you chose to build your systems on top of some framework that didn't provide the hooks for interoperation.

I am with you, I do not seen what is evolutionary step either. If you have chance to look at BEA and IBM's SOA reference implementation model and SOA governance model, SOA is just another buzz word for them to suck client's money. It is really a joke instead of technology. "interoperating", plain web service can server that well. any opinion from any one of SOA vendor is worth less than 2 cents.

I am with you, I do not seen what is evolutionary step either. If you have chance to look at BEA and IBM's SOA reference implementation model and SOA governance model, SOA is just another buzz word for them to suck client's money. It is really a joke instead of technology. "interoperating", plain web service can server that well. any opinion from any one of SOA vendor is worth less than 2 cents.

I used to work for a very large oil company. Organisations like this have literally thousands of systems that are used to manage the business. (Ours had >8000 in just 1 segment). In the last 10 years, business has tended to globalise, which means that it is no longer sufficient to allow business systems to be siloed by country/region. This means that large oraganisations MUST integrate their (thousands of) systems to function properly (and legally) in a globalised world. Business has been sold integration MANY times, yes even via TCP, and each time it has turned out to be expensive and relying on proprietary systems. With SOA there is a set of technology standards, and a set of accompanying patterns, that could actually "do the integration thing" properly, in some kind of organised fashion. And whatever consultants will charge for it, for large organisations, it will pay for itself VERY quickly. There is alot of marketing hype, and underneath the technology isn't particularly advanced. But it does seem to me that SOA is the best way of doing integration properly, for once, which is why big business is getting on board and willing to spend money. Kit

SOA is just the next evolutionary step in the way information is shared and the way we have computing interoperability. It's taken the computing industry about 30 - 40 years to evolve to the point where computers can start interoperating like businesses interoperate. I can develop computing systems to interoperate in ways that I could not do with the tiered enterprise architectures of the 90s.

+1 Well said. SOA is all about integration and sharing. I highly recommend Banke’s book, “Enterprise SOA Service-Oriented Architecture Best Practices�. It provides background on the problems SOA addresses, and implementation strategies. It’s practical yet high-level, and provides unvarnished real-world experience, without the fluff and hype.

SOA is just the next evolutionary step in the way information is shared and the way we have computing interoperability. It's taken the computing industry about 30 - 40 years to evolve to the point where computers can start interoperating like businesses interoperate. I can develop computing systems to interoperate in ways that I could not do with the tiered enterprise architectures of the 90s.

+1

Well said. SOA is all about integration and sharing.

I highly recommend Banke’s book, “Enterprise SOA Service-Oriented Architecture Best Practices�. It provides background on the problems SOA addresses, and implementation strategies. It’s practical yet high-level, and provides unvarnished real-world experience, without the fluff and hype.

Well, well... So many "best practices" in books, but not a single confirmation in the real world. People, get over it. SOA is nothing but a cloud fest. The only positive thing about SOA emerging is that I discovered that I was doing SOA 10 years ago, too. Now I am enlightened!

I very much agree with your view, and I also see SOA as a todays OO, and continuing the process, where OO left. OO did a great job improving application development. But at two points OO did not succeed: One is reuse/standardization of business objects, the other is distributed objects, which doesn't compensate for the real world problems in distribution as network delay, servers being down etc. SOA based on ESBs is focused on these two issues. And as with OO 20 years ago, there is hype, vendors are overselling, and many developers will not accept it. Hardy Henneberg

I very much agree with your view, and I also see SOA as a todays OO, and continuing the process, where OO left.
OO did a great job improving application development. But at two points OO did not succeed: One is reuse/standardization of business objects, the other is distributed objects, which doesn't compensate for the real world problems in distribution as network delay, servers being down etc. SOA based on ESBs is focused on these two issues.

And as with OO 20 years ago, there is hype, vendors are overselling, and many developers will not accept it.

Hardy Henneberg

Comparing SOA and OO is like comparing Banana Pancake with Airbus A380. Banana Pancake can potentially be better than A380, but it depends more on the one making pancake than the pancake itself. SOA is cloudfest. Main problem of Service Oriented Architecture is that there is no architecture. People trying to compare SOA and OO usually don't understand neither SOA not OO. So, how would you implement SOA without OO? Using dBASE? Or, how would you develop distributed OO application without using concepts that SOA hijacked?

Comparing SOA and OO is like comparing Banana Pancake with Airbus A380. Banana Pancake can potentially be better than A380, but it depends more on the one making pancake than the pancake itself.

Right, my chicken also shits in a purple bucket.

SOA is cloudfest. Main problem of Service Oriented Architecture is that there is no architecture.

How is that different from OO?

People trying to compare SOA and OO usually don't understand neither SOA not OO.

You are beginning to seem like one such a person.

So, how would you implement SOA without OO?

What does comparing OO to SOA mean SOA have to do with implementing SOA with OO? This appears to demonstrate extreme confusion in your understanding of logical reasoning.

Using dBASE?

No, bannana pancakes and an Airbus 380.

Or, how would you develop distributed OO application without using concepts that SOA hijacked?

Now you seem to be agreeing that SOA is similar OO. You really aren't making any sense at all.

Good response James. I'd also add a few other points: 1) SOA is not an architecture - it is an architectural style. 2) OO is not an architecture or an architectural style. It is a paradigm that encompasses analysis, modeling and programming. You can implement an OO model without an OO language. 3) There are 2 major SOA styles. The one I see as being true SOA extends from component-based architecture and is OO-based. The SOAP document/literal style aligns well with OO-based SOA. So does REST. (The original concept of objects is that they send each other messages, not function calls.) The other SOA style is based on functional decompostion (structured) and tends to lead to RPC-based service definitions. SOAP RPC/encoded and XML-RPC align well it. Either SOA style can be programmed in OO or structured procedural languages. Finally using an OO language does not necessarily result in an OO implementation and in CBA, many OO designs were implemented in non-OO languages such as C. C++ was invented as a C generating precompiler to help makke that easier. If the dBase language had the necessary infrastructure support and extensions, you very well could use it to implement SOA. It would be a dumb idea, but you could do it.

If the dBase language had the necessary infrastructure support and extensions, you very well could use it to implement SOA. It would be a dumb idea, but you could do it.

Precisely. The example I typically use is FORTRAN, and in that case it's not necessarily a dumb idea -- there are huge numbers of highly-complex scientific/engineering assets implemented in that language that can be exposed as SOA services.

If all the analysts are to be believed (though am yet to see correlating biz data from the license revenues from some of the players in the SOA/ESb infrastructure space), then there is a lot of money being (and more "to be") spent on SOA. SOA is one of the key concerns of CIOs and enterprise IT managers. While there may be a lot of dollars spent, I believe these will be more in infrastructure/licenses than in actual enterprise applications/solutions development! Anyone that has dabbled in simple integration/web-services or the more "evolved" SOA infrastructure (spanning multiple service containers, orchestration of these multitude of geographically distributed services after browsing thru the UDDI based enterprise services registry and ensuring that the services all comply with the fanciest of WS-* specs), will know that SOA is more a "wrapper" layer on core IT solutions. And not IT solutions by themselves. Meaning, al other IT Systems and new requirements will continue as ever. Just that there is a growing need to look outward and allow/enable access to the solution from other apps/systems in the enetrprise. Now, enterprise integration is not exactly new. EDI technology has been around and widely used for a long time. But noone ever said we are "EDI programmers". And EDI was as central to enterprise IT infartsructure then as SOA/enterprise-intergation is today. But today there is so much noise about SOA. Like mentioned at the start of the thread, "Service orientation" as a design concept is a very good thing. And probably has been around in th eminds of good software architects all along. Especially, after component based multi-tier systems became widespread. So, hype aside, this goodness must surely be consdiered in all systems' design. Ensuring that the functionality is well described in clear biz interfaces is never a bad thing. With this is in place, getting these servcies into ANY Service bus/infra will be a no-brainer! - Ramesh @ Pramati http://jroller.com/page/rameshl

Now, enterprise integration is not exactly new. EDI technology has been around and widely used for a long time. But noone ever said we are "EDI programmers". And EDI was as central to enterprise IT infartsructure then as SOA/enterprise-intergation is today. But today there is so much noise about SOA.

I'm not sure if you are suggesting that people are saying that they are 'SOA programmers' or what. If someone did say that it would be a clear sign that person didn't know his ass from a hole in the ground.

I'm not sure if you are suggesting that people are saying that they are 'SOA programmers' or what. If someone did say that it would be a clear sign that person didn't know his ass from a hole in the ground.

Most of the discussion on this thread is around programming models and comparisons to OO et al. My reference was to such expectations on what it takes to build SOA solutions.

I agree. I was not talking about SOA replacing OO, but about CBA entending OO and SOA extending CBA - I admit that is not clear from my post. But I'm more interested in what will be the results of the SOA movement, than I am in the definition of SOA. I remember exactly the same discussions in the OO days. You can always split up such definitions, and claim this and that is nothing new, because it is already used in other areas. So what ? Although the techniques in OO was not quite new, and you could make OO applications in Cobol, the results of the OO movement is unquestionable. If the SOA movement will succeed in the same way, only time will tell. William, I think it was you talking about the next step - a more event driven SOA. I find this very interesting and mostly agree. At least we agree on synchronous communication from user interface to database is a bad thing- not scaleable and not reliable. I think SOA already has started a movement from synchronous to asynchronous communication. First: My experience is, that SOA has made you think, if a service should be asynchronous, and generally it is, if the service is asynchronous 'by nature' (whatever that means, but often something, which cannot be finished within a couple of seconds). Second: SOA architectures should be based on an ESB, which offers some decoupling, so a synchronous request need not to be synchronous all the way down to the database. I hear some whining 'you can do that using JMS too'. Yes you can, but one thing is what you can, another thing is what you do. What you talk about is event-driven (asynchronous) all the way and for all services, I think. A common argument against it is, that you mostly need a reply in a few seconds, for instance to show data to the user. I don't think it is a valid argument. If you can't get a reply within a few seconds using asynchronous communication, you can't get it using synchronous communication either. No, the problem is: asynchronous programming is harder. But ESBs on the midtier and BPM tools and Ajax toolkits at the frontend makes it easier. The hurdle may be to get all developers use to think message-oriented. I think, event-driven is thought into SOA. There is still a lot of polling out there, but gradually that will disappear, and so no business in selling this as new thing. regards Hardy

I have always found the discussion around synchronous/asynchronous/event driven issues rather misleading. Being synch or async depends on the point of view. Again here I recall ICE model for AMI/AMD that let you decide the interaction style in the client (requestor) independently from the processing style in the server (provider). Anyway, (client-side) asynchronous interaction style is not hard, it is ***very*** hard (in 90's I worked with an operating system where memory allocation - read malloc() - was asynchronous !!!!). Event driven style should not be mixed with the previous. It simply (!) refers to a way of triggering computations and making their results evidence available. Guido

Hardy, We seem to be agreeing in general, but I'd quibble on two things: 1) JMS is not an alternative to ESB, JMS can be used to communicate with the ESB. Many ESB's are based built on MOMs. I prefer using JMS because it is more powerful, robust and flexible than HTTP. I also prefer asynchronous communications with services. 2) OO is a paradigm while SOA is an architectural style so they are not alternatives. I practice OOA/OOP when implementing components in SOA. I started using asynch communications with services using Tuxedo in the 1990's. I found that it actually was faster than synchronous in part because of the style if forces you to adopt and because your communications are not blocking other activities on the client - including other service calls. An individual call might be slightly slower, but the net effect was more speed and greater throughput. The client's perception was that it seemed faster. Bill

Comparing SOA and OO is like comparing Banana Pancake with Airbus A380. Banana Pancake can potentially be better than A380, but it depends more on the one making pancake than the pancake itself.

Right, my chicken also shits in a purple bucket.

SOA is cloudfest. Main problem of Service Oriented Architecture is that there is no architecture.

How is that different from OO?

People trying to compare SOA and OO usually don't understand neither SOA not OO.

You are beginning to seem like one such a person.

So, how would you implement SOA without OO?

What does comparing OO to SOA mean SOA have to do with implementing SOA with OO? This appears to demonstrate extreme confusion in your understanding of logical reasoning.

Using dBASE?

No, bannana pancakes and an Airbus 380.

Or, how would you develop distributed OO application without using concepts that SOA hijacked?

Now you seem to be agreeing that SOA is similar OO. You really aren't making any sense at all.

Ever heard about analogical thinking, sarcasm, irony...? Never mind...

Ever heard about analogical thinking, sarcasm, irony...? Never mind...

Of course poseur.

Ever heard about analogical thinking, sarcasm, irony...? Never mind...

Of course poseur.

Then, if my analogy was too complex for you to process (your comments point to that direction), you could simply ask for explanation. And, to be sure that you will get it correct this time, Unprovoked insults always inspire me to accept someone's' point of view.

Ever heard about analogical thinking, sarcasm, irony...? Never mind...

Of course poseur.

Then, if my analogy was too complex for you to process (your comments point to that direction),

You assertion that I do not understand is a simple-minded and fallacious defense for a weak argument and I have little patience for such childish nonsense. You offered no valid argument for your viewpoint, just pretend cliche and chest-thumping. you could simply ask for explanation. Your facile comments needed no explanation.

And, to be sure that you will get it correct this time, Unprovoked insults always inspire me to accept someone's' point of view.

It seems quite stupid that you to use this strategy on others considering that you realize that it isn't effective.

Ever heard about analogical thinking, sarcasm, irony...? Never mind...

Of course poseur.

Then, if my analogy was too complex for you to process (your comments point to that direction),

You assertion that I do not understand is a simple-minded and fallacious defense for a weak argument and I have little patience for such childish nonsense. You offered no valid argument for your viewpoint, just pretend cliche and chest-thumping.


you could simply ask for explanation.


Your facile comments needed no explanation.

And, to be sure that you will get it correct this time, Unprovoked insults always inspire me to accept someone's' point of view.

It seems quite stupid that you to use this strategy on others considering that you realize that it isn't effective.

There you go again... Insults that you throw so easy speak much more about you than about me. Calm down. Don't you think that it is a bit infantile to start insulting someone who you don't know at all - completely unprovoked? Aside that your complaint is more about HOW I said something than WHAT I said...

The problem, Vladica, is that you don't make any sense most of the time and when you do manage to string together a sentence, it's usually factually incorrect. For example you wrote:

Nice try. But, splasing sentance filled with "common places" revealed that you are just pretending. The only worse thing HR making hiring is when HR hire tech-blafer to do hiring.

What is that supposed to mean? The post you replied to did not mention "common places". What is a "tech-blafer"? Is that an insult? If so, then why are you telling others not to be insulting? If you don’t want to be insulted you should eliminate the sarcasm and insults yourself. (Sarcastic responses are generally perceived as insults in the English language.) Another quote:

Main problem of Service Oriented Architecture is that there is no architecture.

SOA is a style of architecture, not an architecture itself. Do you know what an architecture is? Another one:

So, how would you implement SOA without OO? Using dBASE?

What does this mean? If you are saying that SOA is best implemented using OO, I would agree. If you are saying you must use OOP (OO programming) in order to implement SOA then I would disagree and I’d point out that SOA was being done long before OO languages performed well enough for high-performance systems. Your command of English and logic are both very poor. Instead of trying to be clever, why don't you just make your points in simple direct statements? Then we might understand what you said and we could argue about that. “Can’t we all just get along?� – Rodney King

The problem, Vladica, is that you don't make any sense most of the time and when you do manage to string together a sentence, it's usually factually incorrect. For example you wrote:

Nice try. But, splasing sentance filled with "common places" revealed that you are just pretending. The only worse thing HR making hiring is when HR hire tech-blafer to do hiring.

What is that supposed to mean? The post you replied to did not mention "common places". What is a "tech-blafer"? Is that an insult? If so, then why are you telling others not to be insulting? If you don’t want to be insulted you should eliminate the sarcasm and insults yourself. (Sarcastic responses are generally perceived as insults in the English language.)

Another quote:

Main problem of Service Oriented Architecture is that there is no architecture.

SOA is a style of architecture, not an architecture itself. Do you know what an architecture is?

Another one:

So, how would you implement SOA without OO? Using dBASE?

What does this mean? If you are saying that SOA is best implemented using OO, I would agree. If you are saying you must use OOP (OO programming) in order to implement SOA then I would disagree and I’d point out that SOA was being done long before OO languages performed well enough for high-performance systems.

Your command of English and logic are both very poor. Instead of trying to be clever, why don't you just make your points in simple direct statements? Then we might understand what you said and we could argue about that.

“Can’t we all just get along?� – Rodney King

Yes William, I do occasionally get annoyed by marketing-minded comments and carried away little bit. Please forgive me if I insulted you (or anyone else) personally in any way, as that was never my intention. The thing that I am trying to point is discrepancy between theoretical/academic (market?) and practical/real-life view on some topics discussed here, which are significantly mirrored in real project success rate. I am in IT for many years, so I can't help but seeing patterns in emerging stuff based on what I experienced before. I admit, sometimes I don't express it in very "readable" way, as I am not native english-speaker. Expressing doubt about something in sarcastic/ironic way is regarded humorous, not offensive, in my culture. So I am apologizing on that, too. Now, about SOA. Let's say that SOA is architectural style. Can you exactly point out what architectural benefits this style brings, compared to well-designed distributed systems from 1995? Can you give an example of productive real-life SOA implementation, so we can compare it with some productive real-life old-fashion EAI implementation? Even better, what would be architectural difference between ESB and EAI? We would come to conclusion that they don't differ that much architecturally. Technologically - yes. But not architecturally.

Vladica, Fair enough.

Now, about SOA. Let's say that SOA is architectural style. Can you exactly point out what architectural benefits this style brings, compared to well-designed distributed systems from 1995? Can you give an example of productive real-life SOA implementation, so we can compare it with some productive real-life old-fashion EAI implementation? Even better, what would be architectural difference between ESB and EAI? We would come to conclusion that they don't differ that much architecturally. Technologically - yes. But not architecturally.

Well posed questions. Well I began practicing SOA in about 1991. By 1995 I was using Tuxedo to do SOA. Using Tuxedo did not make it SOA, it was how I used it. In the 1980’s I began using component-based architecture. OO languages did not perform that well and were not very modular. We did OO analysis and modeling and often implemented prototypes in an OO language (e.g. Smalltalk), but we went to something like ‘C’ for implementation. Anyway when we started distributing the components we needed a means to communicate – RPC for example. What we found was that the components (objects) were designed to be reused which made them finer grained and they tended to maintain state. Conversations between components over the network were very expensive. We (myself and others in the community solving the same problems) discovered that we needed to construct what I called façade components that took in the data and invoked a sequence of component operations to complete a single unit of work. The component maintained no state. There was a lot of discussion and debate about what the proper granularity of these services should be since individual components were too fine grained. We also found that passing data as arguments was a pain to maintain. We adopted or invented different ways of making our messages more dynamic and self-describing. By 1995 I began using Tuxedo. Tuxedo supported the self-describing messages I needed (FML) along with synchronous and asynchronous communications. Most people I met at the time who were using Tuxedo weren’t doing services in the SOA sense. For example, many tended to design Tuxedo services to match a client design. They didn’t think about packaging the servers. (A Tuxedo service is maps to a SOA service operation. A Tuxedo server – an executable – a set of services – maps to a SOA service.) Most were not thinking in terms of components or even objects, but some of us were. Later I did some CORBA before moving on to J2EE. I applied the same patterns there. Vendors were encouraging everyone to design EJBs and CORBA objects as objects or components. Those of us who already learned the lessons designed them as services. The advent of web service standard has just made SOA that much more independent of the underlying implementation technologies and products. A good thing. So if you are developing large scale distributed systems, if you are minimizing calls by doing more work in each call and you use flexible message structures, you may be doing SOA whether you know it or not. Its not the technology you use – J2EE, Tuxedo, .NET, DCOM, CORBA – it’s the style you apply to it. So back to your questions EAI – is between 2 points from what I’ve seen. It’s a designed 2 way exchange. It may keep state. It may be conversational. In SOA, services, like components, don’t know about their clients and they don’t keep state. The first job of ESB’s is transport bridging so each service only has to support one transport protocol. ESB’s off load infrastructure concerns from the services. They can be used to handle security, monitoring, logging, auditing, format transformations, routing, and discovery. They can do this intrinsically or by routing traffic through nodes the have been added to the ESB that perform these services. ESB’s also often host BPM and BPEL engines as well as registries. The greatest thing in my mind about ESBs is that they keep the services simple (business logic only) and make integration easier and more consistent. You don’t have to support separate implementations of infrastructure services or cross-cutting concerns for .NET, J2EE, CORBA, Tuxedo, CGI, etc. The traffic is sent through the ESB which manages it and routes it to insure these requirements are met by one common implementation of each infrastructure service type. You’ll probably point out the EAI middleware has many of the capabilities of an ESB which is true. Many EAI vendors are now marketing enhanced versions of their products as ESBs just as many MOM vendors are doing. So, you could say that an ESB is more an architectural concept and construct than a product. To your original point: I think most of us who practice and advocate SOA would agree with you that it is being hyped and oversold by vendors and consultants trying to make a quick buck. We wouldn’t agree that its nonsense or phony or of little value. Bill

There you go again... Insults that you throw so easy speak much more about you than about me.

I think you were looking for "I'm rubber, you're glue..."

Calm down. Don't you think that it is a bit infantile to start insulting someone who you don't know at all - completely unprovoked?

I guess that depends on what one defines as provacative. You really don't think you were provoking anyone? I find that strange. Maybe you should reread what you have written in this thread. If I misread your intention then we can leave it at that. I don't care to continue.

Aside that your complaint is more about HOW I said something than WHAT I said...

What I read in your posts amounted to 'anyone who disagrees with me lacks skill, understanding or intellegence'. I didn't see any points, logical propositions or counter-arguments. I did see a lot of rhetoric and comments about a cloudfest. But again, maybe I misinterpreted.

OK. You won.

I very much agree with your view, and I also see SOA as a todays OO, and continuing the process, where OO left.
OO did a great job improving application development. But at two points OO did not succeed: One is reuse/standardization of business objects, the other is distributed objects, which doesn't compensate for the real world problems in distribution as network delay, servers being down etc. SOA based on ESBs is focused on these two issues.

And as with OO 20 years ago, there is hype, vendors are overselling, and many developers will not accept it.

Hardy Henneberg

Comparing SOA and OO is like comparing Banana Pancake with Airbus A380. Banana Pancake can potentially be better than A380, but it depends more on the one making pancake than the pancake itself.
SOA is cloudfest. Main problem of Service Oriented Architecture is that there is no architecture. People trying to compare SOA and OO usually don't understand neither SOA not OO.
So, how would you implement SOA without OO? Using dBASE?
Or, how would you develop distributed OO application without using concepts that SOA hijacked?

So, I responded to Hardys post (most of them are excellent), reacting to his statement that SOA is todays OO. I pointed (in ironic way) that this comparison is inappropriate. I then pointed out that SOA makes no difference compared to SOA before SOA buzzword. Distributed_application_/_integration project success rate was purely implementation specific before, as it is today. I hope that this time I won't be misquoted. Thanks in advance.

SOA began as an extension of component-based architecture (CBA). CBA began (in the 1980’s for me) when we used OO analysis and modeling to define and design systems that were implemented in procedural languages for performance reasons. Even when implemented using OO languages CBA has advantages over plain OO in terms of reuse, flexibility and maintainability because the discipline of components – strictly defined and enforced (via testing) contracts , strong encapsulation, independent deployment and versioning, etc. Whereas objects can be tightly coupled to each other, components, by definition, cannot. Where components are coarse-grained objects designed for reuse and usually incorporate some notions of a framework, SOA services realize use cases. That is, SOA services are (or should be) orchestrations of one or more components. That means services tend to be coarser-grained than components and therefore, more efficient for distributed systems. J2EE components (EJBs) are not particularly efficient when highly distributed – unless they are implemented as services instead of just components. Distributed objects and components don’t scale, but services do! Services are a style not a technology. In time SOA has added the concepts of messages (versus procedure calls) and greater encapsulation and independence from the implementation technology and not just the implementation code. Components tend to be tightly coupled to the technology used to implement them. The web services technologies and proprietary middleware (e.g. MOM and ESB) are useful for achieving that independence. Note that pattern – components (the building blocks) are orchestrated into services (use case realizations) which in turn can be orchestrated into larger processes. If you did your OO analysis modeling well and defined and built your components correctly, you’ll find that you can do some amazing things very quickly without much effort. You are now composing instead of programming. Adding an ESB with BPEL and BPM makes it that much more powerful. Vendors and a lot of programmers have confused SOA with messages, web services (whatever that means), etc. They often don’t understand that components are the building blocks and are the source of many of SOA’s advantages. SOA is not just a bunch of services. SOA is not web services. SOA is an architectural style independent of any technology. I believe that the next evolutionary step will be to make SOA more event-driven. Today we tend to call services (poll) instead of having the computer anticipate our requirements and notify us of what we need to know (push). Then people will talk about event-driven architectures (EDA) as if it replaces SOA instead of having evolved from it.

Distributed objects and components don’t scale, but services do!

LOL Tell me the difference between an object and a service on this particular point. No marketing pr pseudo-philosophical words, please.

In time SOA has added the concepts of messages (versus procedure calls) and greater encapsulation and independence from the implementation technology and not just the implementation code.

Nice to learn that CORBA is a SOA.

Components tend to be tightly coupled to the technology used to implement them.

No, only stupid designers do that. Never heard about the bridge pattern ? Even if, at a certain level you must provide an implementation that is bound to an implementation technology.

The web services technologies and proprietary middleware (e.g. MOM and ESB) are useful for achieving that independence.

I guess you mean unuseful. Guido

Nice to learn that CORBA is a SOA.

I wouldn't say CORBA == SOA, but applications exposing services (defined by IDL) using CORBA can be used as part of a SOA. -John-

Distributed objects and components don’t scale, but services do!

LOL
Tell me the difference between an object and a service on this particular point.
No marketing pr pseudo-philosophical words, please.

If you read my entire post you'd have read that a service realizes a use case - its an orchestration of components. Components and objects are usually (not always) too fine-grained to make good services. You want to minimize the number of calls you have to make in order to do something. If you know what you want done, have it done in one call! Also,components and other objects are not always message driven, stateless or atomic. Services should be. Statelessness (of the instance)is important for scalability and managability. You can find some components that can be made directly into services, but its not the rule. Components, being objects, are designed to be re-used which works against the notion of realizing a complete use case in one call. Reusability correlates to finer granularity.

In time SOA has added the concepts of messages (versus procedure calls) and greater encapsulation and independence from the implementation technology and not just the implementation code.

Nice to learn that CORBA is a SOA.

SOA is a style, not a technology. You can use CORBA to do SOA very nicely.

Components tend to be tightly coupled to the technology used to implement them.

No, only stupid designers do that.
Never heard about the bridge pattern ?
Even if, at a certain level you must provide an implementation that is bound to an implementation technology.

When you write your components in Java (EJB or POJO), you are tightly coupled to Java. Other components have to use Java to interact with you unless build something (a bridge?)in between. That's pretty inefficient and a lot more work. Who in their right mind would do that if they were not forced to? Components that are implemented in the same technology can easily flow transactions and data/objects. They use their shared technology to discover each other as well. With services in SOA you try to use neutral means to communicate and discover. You also try to keep your services atomic and avoid orchestrating multiple services into a single system (not business) transaction. When you can't you end up using some awful means to get around it.

The web services technologies and proprietary middleware (e.g. MOM and ESB) are useful for achieving that independence.

I guess you mean unuseful.

Guido

No, I mean useful Guido. If I communicate with services via HTTP or message-oriented middleware via an ESB or directly or if I used CORBA, I have decoupled the client's implementation technology from the service's. If I communicate via RMI/IIOP, I have to consider the fact that my service or component was written in Java and work with that. BTW, ESB's greatly SOA implementations, more so than any other middleware, but that is another topic.

Distributed objects and components don’t scale, but services do!

LOL
Tell me the difference between an object and a service on this particular point.
No marketing pr pseudo-philosophical words, please.

If you read my entire post you'd have read that a service realizes a use case - its an orchestration of components. Components and objects are usually (not always) too fine-grained to make good services. You want to minimize the number of calls you have to make in order to do something. If you know what you want done, have it done in one call! Also,components and other objects are not always message driven, stateless or atomic. Services should be. Statelessness (of the instance)is important for scalability and managability.

Realizing one use-case per service call tells nothing about scalability, it depends on what happens "behind" the service, i.e. is the implementation of a service that scale. Components and objects used on the boundary as distributed entities that are (too) fine grained are simply badly designed. I am not sure to understand well what you mean for being message driven. If you think at some sort of asynchronous behaviour between the requestor and the service I would say that no, requestor/service sync/async behaviour should be independent. See ICE (www.zeroc.com) async invocation/async dispatch for a really impressive approach. If you are talking about a whole architecture that is message driven it is another matter and I would say that it depends, case by case. About statelessness. I am not so sure that stateful services prevents somehow scalability. It depends on the capabilities of the implementation platform. The judicious use POA/Servant and load-balancing feature of CORBA and ICE can scale unlimited.

When you write your components in Java (EJB or POJO), you are tightly coupled to Java. Other components have to use Java to interact with you unless build something (a bridge?)in between.

No at all. Again, CORBA and ICE are a bright example. If you are talking of EJB I can agree but, IMHO, it is a stupid technology that solves no problems and brings a lot of troubles.

That's pretty inefficient and a lot more work. Who in their right mind would do that if they were not forced to?

Components that are implemented in the same technology can easily flow transactions and data/objects. They use their shared technology to discover each other as well. With services in SOA you try to use neutral means to communicate and discover. You also try to keep your services atomic and avoid orchestrating multiple services into a single system (not business) transaction. When you can't you end up using some awful means to get around it.

The web services technologies and proprietary middleware (e.g. MOM and ESB) are useful for achieving that independence.

I guess you mean unuseful.

Guido

No, I mean useful Guido. If I communicate with services via HTTP or message-oriented middleware via an ESB or directly or if I used CORBA, I have decoupled the client's implementation technology from the service's. If I communicate via RMI/IIOP, I have to consider the fact that my service or component was written in Java and work with that.

BTW, ESB's greatly SOA implementations, more so than any other middleware, but that is another topic.

As you might realize EJB are not the belly of the world to me :) Guido

Again, CORBA and ICE are a bright example.
If you are talking of EJB I can agree but, IMHO, it is
a stupid technology that solves no problems and brings a lot of troubles.
As you might realize EJB are not the belly of the world to me :)
<Guido</blockquote> Session EJBs invoked over IIOP are just a very nice way to implement CORBA objects in Java. I have a very large US telecom firm as a client; those firms are required by gov't regulation to publish their external service interfaces using CORBA. They've implemented these services as stateless session EJBs invoked over IIOP. To external callers they appear as standard CORBA objects. Essentially, this client is successfully implementing a type of SOA using stateless session EJBs as the service integration layer.

Again, CORBA and ICE are a bright example.
If you are talking of EJB I can agree but, IMHO, it is
a stupid technology that solves no problems and brings a lot of troubles.
As you might realize EJB are not the belly of the world to me :)

Session EJBs invoked over IIOP are just a very nice way to implement CORBA objects in Java.

I don't know if it is nice (when I did I found it rather uncomfortable) but it is surely limited wrt CORBA capabilities.

I have a very large US telecom firm as a client; those firms are required by gov't regulation to publish their external service interfaces using CORBA. They've implemented these services as stateless session EJBs invoked over IIOP. To external callers they appear as standard CORBA objects. Essentially, this client is successfully implementing a type of SOA using stateless session EJBs as the service integration layer.

I am curious to see the corresponding IDL, it should not be very readable. Anyway, there should be very good reasons to setup a container, EJB etc. to run simple stateless services. However, nothing that CORBA can't do. To me EJBs bring great limitations not exposing the underlying technology, with little or no benefit. Don't forget that all the other useful specs belonging to the J2EE family (JTA, JMS) are not EJB/Container bound. Guido.

Session EJBs invoked over IIOP are just a very nice way to implement CORBA objects in Java.

I don't know if it is nice (when I did I found it rather uncomfortable) but it is surely limited wrt CORBA capabilities.

How? Session EJBs can consume any CORBA type and they can be invoked with IIOP. Could you elaborate on the limitations?

I have a very large US telecom firm as a client; those firms are required by gov't regulation to publish their external service interfaces using CORBA. They've implemented these services as stateless session EJBs invoked over IIOP. To external callers they appear as standard CORBA objects.

I am curious to see the corresponding IDL, it should not be very readable.

On the contrary, it's very readable; it's the standard IDL that all telecom providers need to support. The customer starts with the IDL, runs it through the IDL-Java compiler, and uses the resulting Java interfaces as their EJB business interfaces.

Anyway, there should be very good reasons to setup a container, EJB etc. to run simple stateless services.
However, nothing that CORBA can't do.

In practice, "CORBA" doesn't provide a ready-made server environment complete with a server runtime, an ORB, transaction and security services, instance management and pooling, thread management, systems management, clustering, and so on. The "very good reason" is that by running CORBA objects in a J2EE app server, you get all those things in a ready-made package.

To me EJBs bring great limitations not exposing the underlying technology, with little or no benefit.
Don't forget that all the other useful specs belonging to the J2EE family (JTA, JMS) are not EJB/Container bound.

Guido.

To use JTA you need an appserver. To use JMS you need an appserver (or you need to write your own server process, which is a lot more work to get right than just using an appserver in the first place). If you're using an appserver, there's an EJB container there for you to use. Being EJB/Container bound is really a non-issue, since that container is already present in any J2EE appserver. Finally, if you use the EJB3 model to write the session beans, they're not even container-bound anymore.

Session EJBs invoked over IIOP are just a very nice way to implement CORBA objects in Java.

I don't know if it is nice (when I did I found it rather uncomfortable) but it is surely limited wrt CORBA capabilities.

How? Session EJBs can consume any CORBA type and they can be invoked with IIOP. Could you elaborate on the limitations?

With POA you can do whatever you want with your implementation. But, if you like, and/or are satisfied with, the way EJB are managed (i.e. their model and lifecycle) it's OK. Just an example of limitations: with CORBA you can use a single (one, uno, un, ein) java object instance to implements zillion of distinct CORBA objects, running in the same server. I don't think you can do the same with EJB model.

I have a very large US telecom firm as a client; those firms are required by gov't regulation to publish their external service interfaces using CORBA. They've implemented these services as stateless session EJBs invoked over IIOP. To external callers they appear as standard CORBA objects.

I am curious to see the corresponding IDL, it should not be very readable.

On the contrary, it's very readable; it's the standard IDL that all telecom providers need to support. The customer starts with the IDL, runs it through the IDL-Java compiler, and uses the resulting Java interfaces as their EJB business interfaces.

Not quite J2EE-ish but not bad at all :)

Anyway, there should be very good reasons to setup a container, EJB etc. to run simple stateless services.
However, nothing that CORBA can't do.

In practice, "CORBA" doesn't provide a ready-made server environment complete with a server runtime, an ORB, transaction and security services, instance management and pooling, thread management, systems management, clustering, and so on. The "very good reason" is that by running CORBA objects in a J2EE app server, you get all those things in a ready-made package.

To me EJBs bring great limitations not exposing the underlying technology, with little or no benefit.
Don't forget that all the other useful specs belonging to the J2EE family (JTA, JMS) are not EJB/Container bound.

Guido.

To use JTA you need an appserver. To use JMS you need an appserver (or you need to write your own server process, which is a lot more work to get right than just using an appserver in the first place). If you're using an appserver, there's an EJB container there for you to use. Being EJB/Container bound is really a non-issue, since that container is already present in any J2EE appserver. Finally, if you use the EJB3 model to write the session beans, they're not even container-bound anymore.

Well, J2EE doesn't provide it either. You always need a product. A CORBA implementation provides a well-defined runtime environment and, IMO, a better instance management not limited to Session and Entity categories. And no, you don't need an appserver to run JTA or JMS, but, yes, there is a certain amount of work to setup. Guido

If I communicate with services via HTTP or message-oriented middleware via an ESB or directly or if I used CORBA, I have decoupled the client's implementation technology from the service's. If I communicate via RMI/IIOP, I have to consider the fact that my service or component was written in Java and work with that.

There's a subtlety here that is being overlooked. You don't "communicate" with RMI/IIOP. You communicate with IIOP and, if you choose to, use an RMI-style programming and usage model to make the calls or receive the calls. What's on the wire is plain-old, standard IIOP and can talk with any other language for which you have an IIOP ORB implementation. This even includes transaction and security interoperability context. That's why it's called "RMI over IIOP" and is typically written RMI-IIOP not RMI/IIOP. It is true that if you want to pass complex Java objects as arguments, you'll need some deserialization technology on the other end if the other end's not written in Java. There is a simple solution to this though: don't pass complex Java objects as arguments -- use simple Java types instead, since those automatically map into standard IDL types and can be converted into any language. Or define those complex structures as IDL structure types instead of complex Java objects.

SOA is an architectural style independent of any technology.

I agree with half the statement. The emergence of certain technologies and defacto standards has added old wine to some new bottles. Building a skyscraper or suspension bridge is an architectural style but it is the emergence of strong steel that makes the architecture possible. The need or desire for big bridges and buildings has functional and nonfunctional drivers that can be satisfied with new technologies. OO, XML and HTTP are recent technologies. Take for example mergers and acquisition (M&A) valuations. A company is valued as a whole or in part. Usually the parts add up to more than the whole. A bank looking to buy a bank, etc, etc will look at the parts in its valuation. There is overlap so the more decoupled the target bank systems the better. Architects aren't thinking of this when they design usaully but as the doamin morphs patterns emerge and cohesive services emerge too. SOA provides guidelines to package and expose those services. SOA, to me, provides some best practices and patterns as to how to do this. Tool vendors need to sell liceneses and keep innovating. Sometimes they move too fast. My concern for this thread is that nobody seems to decompose SOA into its business, process, and technical features. We have to eat it all or none of it. Its like agile - take what works for you or your organization and scrap the rest. If you think agile sucks you aren't looking at the value of its parts. I am lucky enough to work in a company that started using XML-RPC over HTTP services back in the '90s. I can see how cohesive services have allowed the business to enter new markets, add new functionality to across existing applications, and scrap dead features, markets, and applications. SOA is old wine in new bottles but this time there are a lot more patterns, best practices, and even lessons learned from failed SOA experiences.

J2EE components (EJBs) are not particularly efficient when highly distributed – unless they are implemented as services instead of just components. Distributed objects and components don’t scale, but services do! Services are a style not a technology.

Stateless Session EJBs and Message Driven EJBs scale just fine in a distributed environment. As soon as you introduce state into a server component you encounter scalability issues. Service oriented architecture is nothing new. The TP monitors of the early 80s and 90s (Tuxedo, TopEnd, Cics, etc) provided the infrastructure to implement service oriented architecture. Then came the hype of distributed objects implemented on frameworks such as Corba and EJBS (stateful session and entity ejbs). This was the new best thing since sliced bread in IT. The only problem was, it couldn't scale and the introduction of state meant it couldn't be losely coupled either. It's only now that the industry has realized the issues with distributed objects (ie. don't scale and can't be loosely coupled) that we've gone back to the service oriented approach that has proven scalability and performance. The difference today is the SOA has taken services to a new level by formalizing the interfaces to services (ie. WSDL ) and making the transport protocol truely open instead of proprietry (ie. http instead of tuxedo atmi or rmi). This means .NET web services can be seemlessly interact with J2EE webservices. This is the only real improvement of todays SOA over what we've already had for decades.

Stateless Session EJBs and Message Driven EJBs scale just fine in a distributed environment. As soon as you introduce state into a server component you encounter scalability issues.

Service oriented architecture is nothing new. The TP monitors of the early 80s and 90s (Tuxedo, TopEnd, Cics, etc) provided the infrastructure to implement service oriented architecture.

Then came the hype of distributed objects implemented on frameworks such as Corba and EJBS (stateful session and entity ejbs). This was the new best thing since sliced bread in IT. The only problem was, it couldn't scale and the introduction of state meant it couldn't be losely coupled either.

It's only now that the industry has realized the issues with distributed objects (ie. don't scale and can't be loosely coupled) that we've gone back to the service oriented approach that has proven scalability and performance.

The difference today is the SOA has taken services to a new level by formalizing the interfaces to services (ie. WSDL ) and making the transport protocol truely open instead of proprietry (ie. http instead of tuxedo atmi or rmi). This means .NET web services can be seemlessly interact with J2EE webservices. This is the only real improvement of todays SOA over what we've already had for decades.

You misunderstood what I said. Neither stateless session beans nor MDBs nor Tuxedo nor CORBA (I've done all os them- and have been practicing SOA for 15 years.) scale well when distributed if you implement them as components instead of services. If you design an EJB as a service it realizes a use case. You do not have a conversation with it. You do not call it multiple times to accomplish a piece of work when you have all the information needed to do the work. If you design it so you can call any of its operations one time and give it all the data it needs to complete a unit of work, it will scale better. It will also be a service, not a component. Components - in CBA - are a type of object designed for reuse which tends to (not always) make them too fine grained to be good services. You compose services (use cases) by orchestrating components.

J2EE components (EJBs) are not particularly efficient when highly distributed – unless they are implemented as services instead of just components. Distributed objects and components don’t scale, but services do! Services are a style not a technology.

It depends on what and how is distributed. It's a matter of grain, technology may enable scalability, unconstrained or under well defined conditions, or not allowing at all.

Stateless Session EJBs and Message Driven EJBs scale just fine in a distributed environment. As soon as you introduce state into a server component you encounter scalability issues.

Service oriented architecture is nothing new. The TP monitors of the early 80s and 90s (Tuxedo, TopEnd, Cics, etc) provided the infrastructure to implement service oriented architecture.

Then came the hype of distributed objects implemented on frameworks such as Corba and EJBS (stateful session and entity ejbs). This was the new best thing since sliced bread in IT. The only problem was, it couldn't scale and the introduction of state meant it couldn't be losely coupled either.

It's only now that the industry has realized the issues with distributed objects (ie. don't scale and can't be loosely coupled) that we've gone back to the service oriented approach that has proven scalability and performance.

The difference today is the SOA has taken services to a new level by formalizing the interfaces to services (ie. WSDL ) and making the transport protocol truely open instead of proprietry (ie. http instead of tuxedo atmi or rmi). This means .NET web services can be seemlessly interact with J2EE webservices. This is the only real improvement of todays SOA over what we've already had for decades.

Please don't mix CORBA and EJB. They are really different. And please don't say CORBA objects cannot scale or cannot be loosly coupled, it is simply false. You are making the equation SOA==WebService that, theory false (ask vendor consultant for a counter proof). More, interface formalization with a neutral language popped up with RPC I think. More more, WSDL is stupid by design. Never seen an interface definition including the endpoint declaration. You say that, thanks to don't know who or what, .NET web services can seemlessly interact with J2EE webservices. Well, nothing really new. CORBA goes beyond seemless client-server interaction. Its portable client and layers have no equal in other distributed frameworks. Guido

Guido, You can't read very well can you? You say scalability is "a matter of grain" meaning granularity. That is what I just said, what are you arguing about? Services are coarser grained than objects. Duh! I didn't "mix CORBA and EJB", but they can both be used to implement distributed components or services. They scale better when they are coarser grained - services not objects. You are mixing the implementation technology with the architecture and design styles. (BTW, EJB with RMI/IIOP is CORBA in Java.) I didn't say SOA=Web Services. I said the opposite. It is you who are confused. SOA benefits from web services because web services standardize ways of defining interfaces and message structures. They are far more widely supported then CORBA IDL. Your other statements are nonsensical. Which RPC do you refer to? What are you saying about webservices written in .NET and EJB interacting? I said that when using web services you no longer care which is which. They do interact if you first define the WSDL and schema and then do the code. Early tools to generate services from existing code had inter-operability issues, but doing things that way is just plain wrong in any case. Bad tools and the people using created the problem, not the standards. WSDL is "stupid by design"? Your statement is stupid by its meaning. WSDL is a more complete definition of the interface. It contains everthing I need to know to interact with a service and invoke its operations. It works pretty damn well. If you had any significant experience in this area you would know that. Cling to CORBA if you like. Hopefully enough of it will be around long enough to last you until retirement. Get a translator will you?

Guido,

You can't read very well can you? You say scalability is "a matter of grain" meaning granularity. That is what I just said, what are you arguing about? Services are coarser grained than objects. Duh!

From where I stand you are making an artificial separation between services and objects. Some objects are coarse grained too. I'd be interested to hear how you view a Session bean - do you view that as an object or a service?

I didn't "mix CORBA and EJB", but they can both be used to implement distributed components or services. They scale better when they are coarser grained - services not

Actually there are a number of ways to achieve scaling not all of which are about coarser grained methods. Batching etc for example.

objects. You are mixing the implementation technology with the architecture and design styles.

(BTW, EJB with RMI/IIOP is CORBA in Java.)

I didn't say SOA=Web Services. I said the opposite. It is you who are confused.

I believe you are also making the same mistake re mixing implementation and architecture hence all my questioning of you as I try and work out what it is you're trying to say.

SOA benefits from web services because web services standardize ways of defining interfaces and message structures. They are far more widely supported then CORBA IDL.

Your other statements are nonsensical. Which RPC do you refer to? What are you saying about webservices written in .NET and EJB interacting? I said that when using web services you no longer care which is which. They do interact if you first define the WSDL and schema and then do the code. Early tools to generate services from existing code had inter-operability issues, but doing things that way is just plain wrong in any case. Bad tools and the people using created the problem, not the standards.

WSDL is "stupid by design"?

So we must not generate WSDL from existing interfaces - so what is the prescribed method for integrating an existing service that isn't yet expressed in WSDL?

Your statement is stupid by its meaning. WSDL is a more complete definition of the interface. It contains everthing I need to know to interact

Please explain how it is a more complete definition?

with a service and invoke its operations. It works pretty damn well. If you had any significant experience in this area you would know that.

Cling to CORBA if you like. Hopefully enough of it will be around long enough to last you until retirement.

Get a translator will you?

Venomous to say the least - if you want to get a point across, this is not the way to do it.

Dan,

From where I stand you are making an artificial separation between services and objects. Some objects are coarse grained too. I'd be interested to hear how you view a Session bean - do you view that as an object or a service?

A service is not a technology. You can use a session bean to implement an object or a service. A service corresponds to a use case, not an object.. Use cases and objects are defined during requirements analysis and modeling. When you broke down your use case activities and looked at your data flows you discovered objects and relationships and added them to your model. The actors (clients) still want their cases realized. They don’t want to talk to objects. Objects are for developers. If you are service oriented you will define your services based on your use cases and create them by doing some object choreography using the objects derived from them.

Actually there are a number of ways to achieve scaling not all of which are about coarser grained methods. Batching etc for example.

Like CORBA copy helpers and command beans? In either case you are being coarser grained. Whether you define the sequencing at the client and send it or send the data to the end point where the sequencing is defined, you are still being coarse grained. It’s not a single object from your object model that manages the execution sequence on the server side. It’s either a specific service or a service engine.

I believe you are also making the same mistake re mixing implementation and architecture hence all my questioning of you as I try and work out what it is you're trying to say.

Excuse me? How clear can I make it? SOA is not web services. Web services is a label invented to describe the use of some combination of technologies (always involving XML) that are used to implement services. You can use web services technologies in SOA or not. You can use CORBA, EJB, Tuxedo, or other middleware, or not. SOA is not technology.

So we must not generate WSDL from existing interfaces - so what is the prescribed method for integrating an existing service that isn't yet expressed in WSDL?

It is unlikely that any existing code was designed to be a SOA service. Slapping a service façade on what you have will not get you to SOA. Assuming that your code is a well-defined service in the SOA style, then you already have a defined interface, it is just not in WSDL form. The problem with generating the WSDL from your code is that the tools available tend to generated programming language-centric names from reading the code. The naming conventions can create conflicts with other technologies that attempt to use your WSDL to generate their client code. The conflicts created between Apache and .NET services by WSDL from code generation are well-documented. Microsoft learned from this and changed the advice they give developers. Check out their posts on services interoperability. Look for stuff written by some guy named Simon something or other (I think). He’s pretty good.

Please explain how it is a more complete definition?

My response to Guido before this adds to the explanation. Basically a WSDL can give you multiple ways to reach services and XSD is more robust in describing message structures than the simple typing systems in IDL and field table files (Tuxedo FML). The venomous stuff is deserved. Guido has a history of labeling everything that is not CORBA and anyone who doesn’t use it as “stupid�. He also has a history of arguing with people he actually agrees with because he doesn’t take the time to try and understand their post. Bill

The venomous stuff is deserved. Guido has a history of labeling everything that is not CORBA and anyone who doesn’t use it as “stupid�. He also has a history of arguing with people he actually agrees with because he doesn’t take the time to try and understand their post.

Bill

Sorry, I would stop but... Never said that someone is stupid, never. I have only tried to say that too many times what is stated on old technologies (CORBA) it is simply FUD. And the new one aren't really new. Guido.

Guido,

You can't read very well can you? You say scalability is "a matter of grain" meaning granularity. That is what I just said, what are you arguing about? Services are coarser grained than objects. Duh!

No, it depends on what the service does.

I didn't "mix CORBA and EJB", but they can both be used to implement distributed components or services. They scale better when they are coarser grained - services not objects. You are mixing the implementation technology with the architecture and design styles.

(BTW, EJB with RMI/IIOP is CORBA in Java.)

You say

Then came the hype of distributed objects implemented on frameworks such as Corba and EJBS (stateful session and entity ejbs).

To me it seems you are mixing the two. More, saying that EJB with RMI over IIOP is CORBA in Java you are superficially confusing a communication protocol with a full DOC framework. Maybe you have never written a CORBA server (I would say I hope).

I didn't say SOA=Web Services. I said the opposite.

Yes, but you said this too

The difference today is the SOA has taken services to a new level by formalizing the interfaces to services (ie. WSDL )

Maybe you wrote i.e. instead of e.g. In any case the remaining part is false. Formalizing interfaces has nothing to do with SOA.

It is you who are confused. SOA benefits from web services because web services standardize ways of defining interfaces and message structures. They are far more widely supported then CORBA IDL.

Two persons saying a wrong thing does not make the thing right. And neither three.

Your other statements are nonsensical. Which RPC do you refer to?

SUNRPC

What are you saying about webservices written in .NET and EJB interacting? I said that when using web services you no longer care which is which.

What do you mean with "which is which" ? I don't care which is which even in a normal java app when object invokes a method.

They do interact if you first define the WSDL and schema and then do the code. Early tools to generate services from existing code had inter-operability issues, but doing things that way is just plain wrong in any case. Bad tools and the people using created the problem, not the standards.

We had not to wait WSDL guru to know that.

WSDL is "stupid by design"? Your statement is stupid by its meaning. WSDL is a more complete definition of the interface.

More complete than what ?

It contains everthing I need to know to interact with a service and invoke its operations.

Yes apple and orange.

It works pretty damn well. If you had any significant experience in this area you would know that.

Cling to CORBA if you like. Hopefully enough of it will be around long enough to last you until retirement.

It works pretty damn well ? It's a matter of taste. For the remaining part I would say mind your business. We were talking of something different, but I think you missed the point.

Get a translator will you?

I am not sure I understand well what you mean with that. It does not seem to be a nice thing, if so it qualifies more you than me. Guido

Guido, Let’s try again.

No, it depends on what the service does.

Do you understand the difference between a remote service and a remote object? We are not talking technologies and they are not just arbitrary labels. They describe different sets of characteristics. Assume both are written using CORBA. Using a distributed object approach you would tend to maintain state – use getter and setter calls – and your calls would invoke the methods of as single object. If you wrote it as a service you would not maintain state in the runtime, you would not use getters and setters and you would be invoking a sequence of methods of multiple objects. The service was defined base on a use case. It will never be less fine grained than an object and almost always would be coarser grained.

To me it seems you are mixing the two. More, saying that EJB with RMI over IIOP is CORBA in Java you are superficially confusing a communication protocol with a full DOC framework. Maybe you have never written a CORBA server (I would say I hope).

Actually, I have written CORBA applications. The CORBA 3.0 spec specifically incorporated features so that EJBs could functions as CORBA objects and interoperate with them. I was working with some of IBM’s Component Broker architects at the time (they were a major force behind both EJBs and CORBA) and they saw EJBs as being part of the next generation of CORBA. Down playing the association between EJBs and CORBA was probably marketing driven. It made EJBs seem more “shiny and new�. As you know and have said in other words, there is a lot of fad chasing done in IT. Re: SOA == Web Services I’ve numerous posts on this thread and others where I’ve said that services do not make SOA and web services are not required for SOA. My personal preference is to use web services only for outward facing services. Internally I keep my messages mapped to the structures I’ve defined in XML schemas, but I don’t bother serializing them as XML or using SOAP if I don’t have to. The advent of web services and its effect on SOA is an economic one. It makes SOA more attractive from an economic perspective. Its not a moral or even much of a technical issue.

More complete than what ?

More complete than IDL or a field table file (Tuxedo). A WSDL tells me all the transports I can use to reach a service. It tells me where the service endpoints are so I can reach them. It tells me what services are available and what operations they have. It tells me what the message structures are needed to invoke a given operation and what the message structure will be in the response. It is so complete that I can generate all the code I need to invoke any service operation defined in the WSDL. That is a step beyond telling me the message structures.

I am not sure I understand well what you mean with that. It does not seem to be a nice thing, if so it qualifies more you than me.

I mean that in this thread and in others you frequently misunderstand the posts of others and your own posts are hard to understand because they are poorly written. My suspicion is that it’s more about your personality than your command of English. When reading a post, don’t jump to conclusions. Read the post a few times and try to understand what is really being said. Go back up the thread a bit to get its context. It isn’t about your technical qualifications, but your communication style gets in the way. In fact, we probably agree on more than you think because a number of times you have argued my position thinking we disagreed because you didn’t read my posts carefully and think before responding. As far as my comment about your “clinging to CORBA� is concerned. You come across as a CORBA fan-boy. You tend to use the word “stupid� a lot when describing other technologies, techniques and styles. That is pretty close minded and does you no favors. It is also insulting everyone who disagrees with you. Once you get labeled as a fan-boy, people quit listening to you. Bill

More complete than IDL or a field table file (Tuxedo). A WSDL tells me all the transports I can use to reach a service. It tells me where the service endpoints are so I can reach them. It tells me what services are available and what operations they have. It tells me what the message structures are needed to invoke a given operation and what the message structure will be in the response. It is so complete that I can generate all the code I need to invoke any service operation defined in the WSDL. That is a step beyond telling me the message structures.

Transports and endpoints are surely service implementation details rather than service interface details. Why would I wish to mix these two things in one chunk of stuff? In fact, why would I wish to expose these implementation details to a consumer of the service at all?

I'll just throw a little tidbit. The WSDL standard that we all know and love (or not) does have problems. The issue is that the spec requires redundant sections that not only have the same info but in a very different format. I don't think I need to explain DRY here but this is not a good idea. What I have seen is that different vendors tend to focus on different parts. All the info is there but they have not filled in the redundant sections properly. This (for obvious reasons) casues interoperability problems. I've even worked with two products from a single vendor (Tibco) that could not understand the WSDL produced by the other. One can argue that the vendors aren't implementing the spec properly but I think it's obvious that eliminating the possibility of this issue would be better. The good news is that WSDL 2.0 appears to do so. It's much better in terms of human readability too.

+1 There is too much wiggle room in most if not all of the WS-* standards. Despite the best efforts of WS-I.org, there is still wiggle room even in their profiles.

More complete than IDL or a field table file (Tuxedo). A WSDL tells me all the transports I can use to reach a service. It tells me where the service endpoints are so I can reach them. It tells me what services are available and what operations they have. It tells me what the message structures are needed to invoke a given operation and what the message structure will be in the response. It is so complete that I can generate all the code I need to invoke any service operation defined in the WSDL. That is a step beyond telling me the message structures.

Transports and endpoints are surely service implementation details rather than service interface details. Why would I wish to mix these two things in one chunk of stuff?

In fact, why would I wish to expose these implementation details to a consumer of the service at all?

Not really. You are not using an IP address as the end point. Its not even a physical machine. A URL does not necessarily map to any one server. A port is an abstraction. Clients have always need to know what tranport to use. Without WSDL you hard-code it either in your own code or by using a middleware-specific client component. If you are a client and you are not on an ESB or similar middleware that does transport bridging for you, then you need to know what transports are available for reaching a service. With Tuxedo or CORBA or EJBs in J2EE you don't have a choice of protocols. This is a disadvantage if you don't have the client software for the middleware you are using. In any case, the transport you need to contact the service says nothing about the implementation of the service. The transport protocol is not part of the service. The service may not even communicate using the same protocol specified in your WSDL. Your client may be directed to a proxy where intermediaries eventually route your message to the service. Think of a service running in CICS that you access via HTTP. The service knows nothing about HTTP. You could later add JMS access (MOM) or native CICS access. It has nothing to do with the service. Remember WSDL's are used both to generate code for the developer and can be used dynamically at runtime with an invocation framework. The availability of multiple transports gives clients the ability to choose the one they prefer.

More complete than IDL or a field table file (Tuxedo). A WSDL tells me all the transports I can use to reach a service. It tells me where the service endpoints are so I can reach them. It tells me what services are available and what operations they have. It tells me what the message structures are needed to invoke a given operation and what the message structure will be in the response. It is so complete that I can generate all the code I need to invoke any service operation defined in the WSDL. That is a step beyond telling me the message structures.

Transports and endpoints are surely service implementation details rather than service interface details. Why would I wish to mix these two things in one chunk of stuff?

In fact, why would I wish to expose these implementation details to a consumer of the service at all?

Not really. You are not using an IP address as the end point. Its not even a physical machine. A URL does not necessarily map to any one server. A port is an abstraction.

Clients have always need to know what tranport to use. Without WSDL you hard-code it either in your own code or by using a middleware-specific client component.

If you are a client and you are not on an ESB or similar middleware that does transport bridging for you, then you need to know what transports are available for reaching a service. With Tuxedo or CORBA or EJBs in J2EE you don't have a choice of protocols. This is a disadvantage if you don't have the client software for the middleware you are using.

In any case, the transport you need to contact the service says nothing about the implementation of the service. The transport protocol is not part of the service. The service may not even communicate using the same protocol specified in your WSDL. Your client may be directed to a proxy where intermediaries eventually route your message to the service. Think of a service running in CICS that you access via HTTP. The service knows nothing about HTTP. You could later add JMS access (MOM) or native CICS access. It has nothing to do with the service.

Remember WSDL's are used both to generate code for the developer and can be used dynamically at runtime with an invocation framework. The availability of multiple transports gives clients the ability to choose the one they prefer.

If the service knows nothing of the protocol, presumably I have some adapter in the middle doing translation from say http to method invocation? How is that adapter generated? What resemblance does this underlying service I'm invoking upon bear (if any) to the WSDL I originally wrote? How do I ensure that I've chosen a protocol that best fits with the service? And how do I ensure that I have all the pieces in place to ensure that the URL I've posted (which chances are uses DNS and therefore does resolve to an IP address???) as the access point gets directed to the appropriate place ultimately?

If the service knows nothing of the protocol, presumably I have some adapter in the middle doing translation from say http to method invocation? How is that adapter generated? What resemblance does this underlying service I'm invoking upon bear (if any) to the WSDL I originally wrote? How do I ensure that I've chosen a protocol that best fits with the service? And how do I ensure that I have all the pieces in place to ensure that the URL I've posted (which chances are uses DNS and therefore does resolve to an IP address???) as the access point gets directed to the appropriate place ultimately?

Let's say you wrote your service as a POJO. You could write a servlet that received the requests and transmitted the responses. You might also want to create an application protocol proxy for SOAP. (You could also add one for REST or other protocols.) The SOAP proxy would accept the input stream from the servlet, process the header (via handlers) and then hand the body to the data binding component. Out comes objects. The proxy might also determine which service operation was being invoked base on the message structure received. It would instantiate the service object and invoke the correct method, passing the objects marshalled from the message body. The service itself instantiates other objects and does the choreography while they do the work. The service knows nothing of SOAP or HTTP. You could replace the servlet with an MDB and use JMS. You could support both JMS and HTTP and JCA at the same time. You could use any protocol supported by your ESB and then the clients could use any ESB supported protocol to reach you. So nothing in the definition or construction of the service itself depends on either the transport or application protocols used. The clients of the services will find nothing in the WSDL that tell them where the service is actually executed, what platform it runs on or the technology used to implement it. If the transport matters to you as the implementer, you can confine access to the protocols that you want to support. You can implement the MDB or servlet parts of the facade to behave as you think they should. Synch, asynch or fire and forget, acknowledgements, dead letters, etc. It won't matter to the service code. The endpoint is not the service anymore than your mailbox or telephone is you. About that statement I just made about confining access to the transports you want to support. If you use an ESB, you probably will not be controlling the protocols used by the clients on an individual service basis. So if for some reason (I can't think of one) you think the service works best using JMS instead of HTTP, you'll have to hope your HTTP clients are using the correct WS-* stacks so they can mimic JMS.

Assume both are written using CORBA. Using a distributed object approach you would tend to maintain state – use getter and setter calls – and your calls would invoke the methods of as single object. If you wrote it as a service you would not maintain state in the runtime, you would not use getters and setters and you would be invoking a sequence of methods of multiple objects. The service was defined base on a use case. It will never be less fine grained than an object and almost always would be coarser grained.

You appear to be saying that an object is an object because it's got getters and setters and a service is not an object because it doesn't have getters and setters? I've built lots of objects (that is instantiations of classes) which don't contain getters and setters - call them services if you like but they're still objects by the classic definition. And if my objects can have things other than getters and setters and be remote they are "remote objects" but, under your definition they would also be "services". Seems to me you're labelling a particular style of object as a service - doesn't change the fact that it's still an object though. Which leads me to the conclusion that I'm still doing objects and OO design albeit with some objects having different design constraints from others. To go further, is this a service? public interface Rhubarb { public Iterator getStuff() throws RemoteException; public void addStuff(Serializable keys[], Serializable values[]) throws RemoteException; } That's going to ultimately be implemented in a class which I will instantiate into an object which may or may not have state and may or may not be delegating to other objects underneath.

Guido,

Let’s try again.

No, it depends on what the service does.

Do you understand the difference between a remote service and a remote object? We are not talking technologies and they are not just arbitrary labels. They describe different sets of characteristics.

No, I don't understand what you are thinking about when you use the word "service" and "object". As someone else already said, it seems you are artificially making a distinction.

More complete than what ?

More complete than IDL or a field table file (Tuxedo). A WSDL tells me all the transports I can use to reach a service. It tells me where the service endpoints are so I can reach them. It tells me what services are available and what operations they have. It tells me what the message structures are needed to invoke a given operation and what the message structure will be in the response. It is so complete that I can generate all the code I need to invoke any service operation defined in the WSDL. That is a step beyond telling me the message structures.

I think that is stupid to put together the definition of the interface of a service with the definition of where it resides because does not allow to have 2 different instances running in different places. Yes, I know, there some workaround. But are workaround. And I don't think that people who like that are stupid and I never said that.

I am not sure I understand well what you mean with that.
It does not seem to be a nice thing, if so it qualifies more
you than me.

I mean that in this thread and in others you frequently misunderstand the posts of others and your own posts are hard to understand because they are poorly written. My suspicion is that it’s more about your personality than your command of English.

Without words, really.

When reading a post, don’t jump to conclusions. Read the post a few times and try to understand what is really being said. Go back up the thread a bit to get its context.

It isn’t about your technical qualifications, but your communication style gets in the way. In fact, we probably agree on more than you think because a number of times you have argued my position thinking we disagreed because you didn’t read my posts carefully and think before responding.

Is this a good way to not answer to my points ?

As far as my comment about your “clinging to CORBA� is concerned. You come across as a CORBA fan-boy. You tend to use the word “stupid� a lot when describing other technologies, techniques and styles. That is pretty close minded and does you no favors.

This is your feeling. I have tried to say that some issues related to CORBA were false or really misconceptions. I have not used stupid generically describing other stuff (I know to you I am a CORBA fan-boy). I have said that certain effects are stupid, because limit flexibility. But, again, if there are people who like that effects I don't think they are stupid. Maybe they made a judicious balance of pros and cons. Guido. P.S. I think we can stop here. Other people don't care

Reading twice (and thinking a little more) would help anyone. My post was not a reply to yours. Guido

Reading twice (and thinking a little more) would help anyone.
My post was not a reply to yours.

Guido

It was quotes from my post that you embedded in your responsse and were attempting to rebut, but whose post it was not the point.

Reading twice (and thinking a little more) would help anyone.
My post was not a reply to yours.

Guido

It was quotes from my post that you embedded in your responsse and were attempting to rebut, but whose post it was not the point.

Not really true. The original post was badly cut to interleave the comments that were targeted to what Anthony Fryer wrote. And it is obvious that you didn't say that, as you with a remarkable elegance pointed out, even if you could agree upon. Guido

Building your code as a series of services is a good start to and SOA but the vast majority of enterprises don't have the luxury of starting from scratch. In this case SOA means the service enabling of the legacy applications. Once service enabled they can become part of the Service Oriented Architecture. An application/product can not be "SOA" or have "SOA inside", it can expose its services in a "friendly" way which usually means Web Services. It doesn't have to be Web Services, services can be exposed as Java APIs but they are not "SOA" as such, they simple fit easier into an existing SOA. The only way a vendor can sell SOA is by selling the architecture, not a product. -John- CTO C24

Building your code as a series of services is a good start to and SOA but the vast majority of enterprises don't have the luxury of starting from scratch. In this case SOA means the service enabling of the legacy applications. Once service enabled they can become part of the Service Oriented Architecture.

An application/product can not be "SOA" or have "SOA inside", it can expose its services in a "friendly" way which usually means Web Services. It doesn't have to be Web Services, services can be exposed as Java APIs but they are not "SOA" as such, they simple fit easier into an existing SOA.

The only way a vendor can sell SOA is by selling the architecture, not a product.

-John-
CTO C24

All of which makes me wonder about this sort of thing:

I believe that the next evolutionary step will be to make SOA more event-driven. Today we tend to call services (poll) instead of having the computer anticipate our requirements and notify us of what we need to know (push). Then people will talk about event-driven architectures (EDA) as if it replaces SOA instead of having evolved from it.

Because there's nothing architectural to stop me designing my services to expose appropriate events/push interfaces already. So I fail to understand why I need to make SOA "more event driven".

I believe that the next evolutionary step will be to make SOA more event-driven. Today we tend to call services (poll) instead of having the computer anticipate our requirements and notify us of what we need to know (push). Then people will talk about event-driven architectures (EDA) as if it replaces SOA instead of having evolved from it.

Because there's nothing architectural to stop me designing my services to expose appropriate events/push interfaces already. So I fail to understand why I need to make SOA "more event driven".

My point was that SOA is a style applied to what what CBA. EDA is a style that can (and is) applied to SOA, but someone in "marketecture" will inevitably declare SOA obsolete replaced by the next "big thing", EDA. BTW, using events doesn't make you EDA anymore than services make you SOA. You have to start modeling things as events and responses (or transitions) instead of requests and responses.

I believe that the next evolutionary step will be to make SOA more event-driven. Today we tend to call services (poll) instead of having the computer anticipate our requirements and notify us of what we need to know (push). Then people will talk about event-driven architectures (EDA) as if it replaces SOA instead of having evolved from it.

Because there's nothing architectural to stop me designing my services to expose appropriate events/push interfaces already. So I fail to understand why I need to make SOA "more event driven".

My point was that SOA is a style applied to what what CBA. EDA is a style that can (and is) applied to SOA, but someone in "marketecture" will inevitably declare SOA obsolete replaced by the next "big thing", EDA.

BTW, using events doesn't make you EDA anymore than services make you SOA. You have to start modeling things as events and responses (or transitions) instead of requests and responses.

Can you explain how you apply the EDA style to SOA? What do you consider makes you SOA?

BTW, using events doesn't make you EDA anymore than services make you SOA. You have to start modeling things as events and responses (or transitions) instead of requests and responses.

Can you explain how you apply the EDA style to SOA?

What do you consider makes you SOA?

See the first sentence above? It begins with how you're modeling things. Like SOA uses CBA components as the building blocks to create services, EDA can use SOA components and services. In traditional SOA - we think of requesting services and getting responses from them. As you start thinking in terms of state change notifications and events - the system doing more for you and initiating more of its own behavior - you become more event-driven. There is no definable "tipping point". Anyway my point is that CBA, SOA and EDA are not radically different - they build one upon the other in an evolutionary way. As to what SOA is, see my earlier post. SOA evolved from and extends component-based architecture in ways that make it distribute better with greater technology independence. SOA isn't just making services. You can have services and not have SOA.

we think of requesting services and getting responses from them I think about triggering some action and getting some change from applying that action and effects of that action might be communicated. I'm simply modelling business processes/behaviours. Then I need to turn that into some reality using the infrastructure I have available to me which might be implemented by such things as scripting, messages, request/response to "services", components, events, people at desks etc.

Whoops, editing error, resend:

we think of requesting services and getting responses from them

I think about triggering some action and getting some change from applying that action and effects of that action might be communicated. I'm simply modelling business processes/behaviours. Then I need to turn that into some reality using the infrastructure I have available to me which might be implemented by such things as scripting, messages, request/response to "services", components, events, people at desks etc.

Just wanted to add some more... A good SOA is event driven, it's going to be far more scalable this way so events don't conflict with SOAs. JavaSpaces are probably the best framework for a SOA in Java. Services are distributed in the Space and state changes generate events. Services (including a transaction monitor and the location service itself) are dynamically located based on the services they expose (using an object template). Once located services are leased, when the lease expires an event is generated. If you were designing a service-based framework in Java it wouldn't be far from JavaSpaces. -John-

Just wanted to add some more...

A good SOA is event driven, it's going to be far more scalable this way so events don't conflict with SOAs.

JavaSpaces are probably the best framework for a SOA in Java. Services are distributed in the Space and state changes generate events. Services (including a transaction monitor and the location service itself) are dynamically located based on the services they expose (using an object template). Once located services are leased, when the lease expires an event is generated.

If you were designing a service-based framework in Java it wouldn't be far from JavaSpaces.

-John-

+1 Finally, some common sense!

It seems to me that you are talking about SOI when you refer to making legacy systems SOA-friendly. That's fine - and realistic for at least the near term. The problem is that you won't reap all the benefits from SOA because being "SOA inside" means its component based. Most of your reuse and flexibility, lower maintenance costs, etc. come from the use of components, not the services themselves. I advise my clients to also "componentize" their legacy system through refactoring if they intend to keep them a long time and if they find that they need to change them relatively frequently. Stable, static legacy systems can get by with just an SOI for as long as needed. The problem with many SOI approaches is that the services often get defined based on the existing code - just slap services facade on what is there. To be truely SOA friendly they should define their services in terms of use cases first and scaffold back to the legacy code. Doing this will tend to result in more composable (reusable) services over the long haul.

I can agree to this but many companies need to start with a bottom-up approach to get their feet wet. I think it needs to be advertised and accepted up front that mistakes will be made moving from more siloed n-tier applications to a SOA. Many early services will be thrown away as teams get better at the top down approach you mention. I see a lot of resistance to SOA on this thread but I think that folks need to understand that much of SOA is just a standardization on the language of the technology. A tech-savvy person, like those who post here, is more likely to roll their eyes and say "duh". Or you'll get the fogies who say "Technology x has been doing that for years..". I don't think that is the point. Where the major change occurs I think is at the client (management, BA) level. They need to think more about the enterprise as a single set of business processes first which isn't easy without a common understanding of terminology and methodology. Vendors of course are doing the industry a disservice by watering down the specifics of that language but that's what marketing does in all industries. Once you start drinking the SOA is a technology kool-aid all bets are off as far as usefulness. Get scared the first time the meeting is steered toward the ESB and how it will solve problems. ______________ George Coller DevilElephant

The problem with a purely bottom approach - even initially - is that it impacts the new code you are writing as well. You're entire perspective as to your processes and the services that compose them becomes warped. My practice to do both top down and bottom up and meet in the middle - SOI plus scaffolding as I described. Another problem I've experience with the bottom up approach is that management seems to jump to the conclusion that because you made something work like a service you now have SOA. "You're done. No need to go back and fix it later. Let's move on."

Did the pattern movement in the 90's introduce a lot of new ideas ? No - they collected and formalized existing ideas. Does that make patterns useless ? Not at all ! It is a help for software development. Does SOA consist mostly of new ideas and concepts ? No - it builds on top of decades of knowledge. And similar to the pattern movement it helps software development by being more structure in the way the problems is analyzed and the solutions designed. The increasing complexity in system, the huge mass of legacy systems around and the availability of standards like SOAP over HTTP has made SOAP popular. And as with so many other good things it has become overhyped by press, managers etc.. But being overhyped does not imply bad. Just to that we have to be a bit skeptical about

We have implemented service based architecture long back when SOA was not around and no surorise that service based architecture scaloes much better then compoenent based architecture.You can move in and out the services you want, make services available.Its just ease of use and maintanence that makes SOA popular. cheers, http://javaicillusion.blogspot.com/

I personally think, the right question is not: What's better with Service-oriented Architectures ( SOA ) ? A better question would be: What is the right strategy to solve the existing problems with the Business Processes in many Enterprises, which are caused by the implementation of monolithic IT-Structures in the last 20 years. Such problems are often the cause, that today has many IT-Departments problems to change existing or to implement new Business Processes, in corresponding periods. Many IT-Departments must spend great part of their time in the Maintenance of their existing IT-Processes, which needs primary the multiple adaption of simple standard-procedures, to implement the proper new Business-Logic or to adapt existings. Each adaption of Business Logic needs in this cases the change of Master Data Handling, which is in the most cases not organized in a centralized manner and standalone implemented in multiples distinct Applications. For this reason, needs simple changes in the Business Logic, the adjustment of X applications and the participation of X departments. The Management of Enterprises has in the last years experienced great changes - maybe causing by the global internationalization, ... and needs today Business Processes which are more flexible and adaptable to the distinct Business Requirements in very short cycles. ---- What makes Service-oriented Architectures ( SOA ) distinct ? That's simple: SOA will change the thinking: The Business Logic must be adapting to the realities of the existing Enterprise IT. To: The Enterprise IT must be adapting and be prepared to the Requirements of the Business Processes in an acceptable manner. --- SOA needs a way of thinking, which is focused in the Business Processes, providing a global Infrastructure of Services, which are re-usable and adaptable to the Requirements of the global Enterprise and permits the Interchange of Informations with the involved or associated Partners in secure and flexible manner. This global Infrastructure needs Granularity by their global Service-Structure and also by their internal Service-Structure, which contains a centralized Master-Data-Management (e.g. a la SAP NetWeaver and MDM ...). At last - the most important: SOA needs the right Teams of Managers, Architects, Programmers, Administrators, ... to design and realize such Infrastructure with a rich Technology and powerful Tools. --- Rome wasn't built in a day. Also Service-oriented Architectures can't be realized in one day and needs a way of thinking in large periods and a proceeding step-by-step. Maybe that's a fact, which is difficult to unterstand for someone, which thinking is focused primary in a quickly accessible ROI. Over the time is the result of a succesfull implemented Service-oriented Architecture ( SOA ) , the desired, flexible Business Processes which are adaptable in short cycles to the real Requirements of the Enterprise - Today and in the next Future. This makes all happier: The Enterprise: makes more and better Business ... The Manager: receives more money ... The Architect: receives a big praise and as a special renumeration - more work by the next waiting project ... The Programmer: has now more time for other nice things ... --- Sorry for my simple English ;-) Roland SOA Kompetenznetzwerk

At first glance it looks like SOA is just a procedure call pattern (or publish-subsribe) gone enterprise. However, the advent of XML, XML schema (data type and structure), WSDL, and SOAP has enabled us to describe interactions in a much richer way than with any notation before, and less dependent on underlying technology. This is the paradigm shift that started it all and that makes SOA deserving to be a new acronym, albeit an overused one.

I don't understand what's all the arguments about. We don't seem to even know exactly what is SOA. If SOA is just a style, best practice, pattern or whatever you call it, then we the IT professionals better let the business folks know. If it is a new technoloy, then it has to be SOAP over HTTP. But the software industry has to agree first.

One word: MARKETING. Sad but true... :-\

Service Orientation in itself does not bring any real new value than Object Orientation did not offered already. It can be even seen as a variant of it. What has made Service Orientation so popular is actually web services. Web services do provide a novelty that was not available before: real interoperability across any platform, tool and vendor (OK not perfect but the best one ever achieved). Web services is the only realistic technique to build software that can interoperate with any tool from any vendor in any platform. This was never achieved by CORBA, DCOM, RMI or whatever because they did not enjoyed universal vendor support. Web services, SOAP, XML and the like do. And interoperability is the sinequanon requisite for reuse, aka the holy grial of software. Try to reuse C++ in Java: a a joke. "Orientation" is not enough. This huge difference is what has made web services so popular, and then somebody sublimated the thing from the concrete web services into the abstract, generic Service Orientation. Its actual rationale is the interoperability of web services. But in the end this means that [Web] Service Orientation delivers a great deal of real value to IT, and this is why it will govern most of the IT landscape for the upcoming years.

Again, SOA is an architectural style while OO is a paradigm. They are not comparable. They do not compete. OOA guides you in modeling the problem and OOP translates your model into implemention. Neither address architecture. SOA works best when based on OOA, but it does not require OOP. OOA/OOP can be employed in many architectural styles, not just SOA. I do agree when you say that it is web services that made SOA take off. OO took off when fast hardware became cheap and labor become relatively much more expensive.

Again, SOA is an architectural style while OO is a paradigm. They are not comparable. They do not compete...

I agree with you but would you agree that 'service orientation' is a paradigm? The only reason I mention it is that I have seen a good number of failed attempts at services that I attribute to a misunderstanding of the concept of a service. For example I have seen 'services' that return mainframe error codes and require that callers poll while waiting for the mainframe to come online (through another 'service'). I guess my personal explanation for this is that modern SOA is a pradigm shift from the older style of mainframe service they were familiar with.

Again, SOA is an architectural style while OO is a paradigm. They are not comparable. They do not compete...

I agree with you but would you agree that 'service orientation' is a paradigm?

The only reason I mention it is that I have seen a good number of failed attempts at services that I attribute to a misunderstanding of the concept of a service. For example I have seen 'services' that return mainframe error codes and require that callers poll while waiting for the mainframe to come online (through another 'service'). I guess my personal explanation for this is that modern SOA is a pradigm shift from the older style of mainframe service they were familiar with.

Mmmmm, interesting point I guess that depends on your perspective. I see SOA (versus just services) services as being a part of the OO paradigm. That is, SOA extends component-based architecture which derived from OO analysis and modeling. A SOA style service is a use case realization that has an object like interface - a data model grouped with operations. I see RPC style services as coming from structured analysis so I don't see them as SOA in the current sense of the term, but others do. So maybe there is an OO SOA and a functional decomposition (structured) type of SOA. The mainframe error codes and polling you refer to seem to me to be more of a failure to hide implementation details in part due to the technology used. Does our harnessing the sum of changes made possible by improvements in technology constitute a paradigm shift? I guess it does at some level. So maybe OO SOA - as represented by component-based construction and document/literal styles combines 2 paradigms - service orientation and object orientation. As I write this I'm coming around to your point of view. Thanks for the insight.

I guess that depends on your perspective. I see SOA (versus just services) services as being a part of the OO paradigm. That is, SOA extends component-based architecture which derived from OO analysis and modeling. A SOA style service is a use case realization that has an object like interface - a data model grouped with operations.

I see OO and SOA sharing some commonalities such as encapsulation and abstraction but I'm not sure the Object concept fits in general. I tend to think of services as stateless, mainly because statless services are much easier to deal with. I guess I think of services more like a static interface (in the Java sense) than Objects.

The mainframe error codes and polling you refer to seem to me to be more of a failure to hide implementation details in part due to the technology used.

I didn't explain fully because I didn't want to get into the tedium of the solution but I guess I should explain more fully. The solution was a WebService that was taking the place of one or more existing Mainframe RPC type calls. I wasn't familiar with that side of things as I was the client in this situation. Essentially, they took the existing mainframe calls and created a thin webservice wrapper to them. When I called the webservice I got mainframe return codes for success and failure in addition to the SOAP exceptions. You can probably chalk some of this up to lack of familiarity with the technology but there was an issue conceptually, too. They didn't get the idea that the webservice should be an abstraction.

Does our harnessing the sum of changes made possible by improvements in technology constitute a paradigm shift? I guess it does at some level.

I'd say that proper use of technology requires a paradigm shift. As an general example: WWI troops ordered to attack protected machine gun positions with infantry charges. The machine gun (technology) necessitated the paradigm shift.

So maybe OO SOA - as represented by component-based construction and document/literal styles combines 2 paradigms - service orientation and object orientation. As I write this I'm coming around to your point of view. Thanks for the insight.

What's my point of view again? ;) Seriously, I'm not pushing any particular view other than that SOA is not just a buzzword regardless of it's orginality (or lack thereof) and the hype around it. The hype will die down, the question is whether SOA will die with it. I don't think so because (as most everyone here agrees) it's built on old ideas that work.

Personally I do not think of SOA as an extension of components. The big wins for reuse tend to be in the lower layers of the procesing stack and the closer you get to to the details of a particular business the more bespoke the requirements become. At this level it makes sense to be "agile" with respect to those requirements: not to try to preempt them with some notion of component reuse. I really dont believe, especially in a post-agile world, that there is any value in hanging on to notions like "reusable business components" which have surely been roundly discredited with the failure of componentisation efforts of EJB, CORBA, COM etc to deliver anything close to the promised level of reuse of business level functionality. Anyone looking to SOA to provide this is going to be dissapointed as well. Indeed I view talking about SOA and "components" in the same breath as a positively dangerous thing because it encourages people to over generisise thier designs and enshrine what should be fluid (and hence agile) APIs by bolting on web service access or whatever. We really dont want to get into the flow of "lets just expose this API as a web service because someone somewhere might need it" - there either is a requirement to do this or there isnt. SOA is "super architecture" - it is a concept that lives at a higher level of abstraction than we currently think of as "architecture". Its about how we glue together coarse grained functions within a business and not about how we connect components within a single system (and I'll loosly classify a "single system" as a set of software components which exists in the same change managment domain). Paul C.

SOA is not an extension of components; it's an extension of component-based architecture. SOA servcies are not components; they are choreographies of one or more components that realize use cases. Big difference. Components in the CBA are not EJB, COM, CORBA, etc. Those are component technologies in that sense but they not the application components. In other words, they facilitate the implementation of components, but they are not components of the application. You don't need any of them to do CBA. Components in CBA are the primary, coarser-grained objects from your model whose implementation may include some notion of a framework. Components are objects, but what sets them apart is that their encapsulation is stricter. They have formal contracts, not just interfaces. Their development tends to be test-driven, They are independently versioned and deployed. Their interactions have no side effects. We don't bother with all this for ordinary objects, but components are seen as particularly useful and reusable. Because services are coarse grained and efficiency (avoiding unnecessary calls) is important, they are not as reusable as components. We mitigate that because we can easily compose new services from our collection of components. That is what SOA is all about. You create components CBA style and then use them to compose the services you expose. You do not expose the components. So, I agree with much of what you have said, but not your confusion of component technologies with CBA and SOA. P.S. Please don't quote me Wikipedia's mistaken definition of components. Better definitions can be found by googling "Catalysis" and works by D'Souza, Wills Szyperski, Heinman and others.

One of the advantages of SOA and services that has been greatly emphasized is the (potential ?) scalability. It has been stated that services scale either in general, because should be stateless etc., and because they, tipically, realize an use case. I think that saying SOA, and the services realized accordingly, scales, somehow automagically, is not correct. First, I find rather hard to state that SOA/services (in this discussion the distinction has become harder and harder to catch), scale. What scales ? The architecture ? The implementation ? It is not very clear to me. I have always found hard to figure out an abstract scalability of abstract concepts. I know of specific services scalability, because the architecture of the service has such intrinsic capability. Examples could be the CORBA Name Service and UDDI. Other forms of scalability are strictly related to **implementation** of a SW element (either a service, object, component). Scalability could be achieved, for example, with load-balancing devices (either SW, HW, due to framework enabling features). Now back to SOA, if we analyze the assumption that services realize an use case, what could we deduce in terms of scalability ? I think little or nothing. Surely, requestor-service interaction is minimized, i.e., communication overhead is lowered wrt the number of request/reply handled by the communication middleware. Anyway, bandwidth saving might not be so important, it depends. How do services implementing use cases cope with increasing load ? I think the assumption by itself it is not sufficient to state that services scale. Now statelessness. I don't think that there is a common understanding of the meaning of stateful/stateless services. Some relate the state to a piece of information that is bound each specific requestor (some form of conversational state), other relate it to the internal state of the service. Whatever meaning you give to this property, neither of the two types have intrinsic scalability capabilities with the exception of one special case. If we consider a (stateless) service with no conversational state and no internal state, scalability issues are mainly related to the possibility to increase reachability of the service, i.e., network connectivity. In all the other cases, scalability can be achieved under specific circumstances. Considering a (stateless ?) service with no conversational state but with an internal state, we might say that it cannot be replicated because of state. Well, it depends. It depends on the frequency of updates of the state. The state can be persisted with a distributed cache infrastructure that maintains consistency. Now let’s go stateful. Conversational state is some contextual data that applies during a service request. Here we have to options: the context data is attached to each request, the context reference is attached to each request. In the first case conversational state does not affect scalability. In the second scalability issues do not apply to the service, but to the **context** service that provides access to the context data. The discussion of a service with both conversational and internal state is a mix of the previous two. So, in the end, SOA scales ? As any other stuff, it depends. Unless SOA is limited to services with no conversational and internal state. But, in this case, should we bother with ****these*** services scalability ? Maybe such a “simple� services have scalability needs far later than other elements of the system. Guido