(This is a follow-up to my previous article, "Early signs of the
death of SOA?")
A recent article by Darryl K. Taft in the online edition of eWeek,
dated 15 July 2007, and entitled, "The Merging of SOA and Web 2.0"
offers more evidence that the SOAP and WS-* standards are not
gaining wide adoption, but simpler standards such as REST and JSON
are.
Taft quotes Dan Hushon, CTO at EMC's Grid Business Unit in Hopkinton,
MA:
"Web 2.0 concepts and technologies may, over time, displace the WS-*
stack in many cases. For example, where we used to see SOAP [Simple
Object Access Protocol] and JSON [JavaScript Object Notation]/REST
APIs to services - e.g., Google - we are now seeing mainly JSON/REST.
And, in fact, REST, with its more data-centric approach, may very
well prove to be better aligned with the need for collaborating
around data. However, systemic security remains an Achilles' heel
for REST."
Note that Hushon says it's systemic security that's the challenge, not
that REST can't be made secure at all. So let's get to work on some
good security practices for REST-based services!
J.A.W.
Sunday, August 19, 2007
Saturday, June 09, 2007
Bad Data!
As our country's lawmakers and citizens debate the proposed Immigration Reform bill, I found an related article in the 28 May 2007 issue of eWeek entitled, "Privacy concerns stem from bill." The full title of the bill is "The Secure Borders, Economic Opportunity and Immigration Reform Act of 2007" and one of the provisions that ought to concern IT people is the proposed expansion of the Employment Eligibility Verification System (EEVS). Basically, it would require all American workers to be registered in a Department of Homeland Security database, be checked against it to get a job, and also fine businesses that don't comply. The problem is, the government doesn't have a good track record for operating and protecting large databases like this - just think about the problems with the "No Fly List" database and recent data breaches. Here's my favorite quote from the article:
"The government definitely seems to have two consistent problems — one is bad data getting into the database ... and the other is getting bad data out of the database," said John Pescatore, an analyst for Gartner.
I usually take anything a Gartner analyst says with a large grain of salt, but in this case, he's right on the money. As a government employee who's run large database programs for a living, I can tell you: It's going to be a disaster.
J.A.W.
"The government definitely seems to have two consistent problems — one is bad data getting into the database ... and the other is getting bad data out of the database," said John Pescatore, an analyst for Gartner.
I usually take anything a Gartner analyst says with a large grain of salt, but in this case, he's right on the money. As a government employee who's run large database programs for a living, I can tell you: It's going to be a disaster.
J.A.W.
Tuesday, May 22, 2007
Wimpy Theology
I just read an article entitled "The Military: Faith Under Fire" by Eve Conant in the 7 May 2007 print issue of Newsweek. It's a story about Army Chaplain Roger Benimoff and his experiences in Iraq. In a nutshell, he goes to Iraq, an evangelical Christian feeling full of faith and enthusiasm to help the soldiers there, and he ends up "losing" his faith, then slowly regaining it after returning to the U.S. The uniqueness of the article is the way in which the author tells Benimoff's story by interspersing personal interviews and diary entries.
It becomes clear that during his two tours in Iraq, Benimoff's faith in God is severely tested as he goes about his duties. Though at first his faith appeared to be strong, he became increasingly troubled by the senselessness and carnage of the war. It is related that he often quoted Bible verses to himself and others for comfort, "But it didn't explain why bad things happen to good people, a question Benimoff would face again and again from the soldiers he served with - and
from within himself." When counseling other soldiers, "They would ask me: if I'm a child of God, then why isn't God protecting me?"
The thing that made me want to write this post was a quote from Benimoff's wife, obviously very concerned about her husband's faith and general well-being: "Sometimes he would ask me: why does a loving God allow suicide bombers to attack civilians? We were both brought up with a picture of God that was different from the world he was seeing."
This highlights what I believe is a problem in many Christian churches today. What is this "picture of God" that they found so different from their experience in the real world? Theologians have wrestled with this problem for a long time (there's an understatement for you!), but many basic truths from the Bible can illuminate our understanding of the problem. For example, it is true that God allows "bad" things to happen to "good" people (see the book of Job, for instance). God is also sovereign and acts in ways that are sometimes difficult or impossible for us to understand. For a Bible-believing Christian, this is a given. I think it is due to a "wimpy gospel" that some Christians think we are immune to such troubles when we become believers. Being a Christian is not always "fun" - there are trials and troubles that God
uses to refine us and build our faith in Him. But we need to understand that is the norm, and being a Christian is not a guarantee of a trouble-free, happy-all-the-time existence.
I have great respect for Chaplain Benimoff and all our other servicemen who selflessly work to protect our citizens, our country and our freedoms. But I lay blame on denominations, seminaries, churches, and pastors who preach a warped gospel. We must present a full and well-balanced view of real Christianity, including all the fun and not-so-fun aspects.
After returning to the U.S. to take a tour at Walter Reed Army Medical Center, he wrote in his journal, "I was reading my Bible and I found myself getting violently mad at God." But by the time of his Newsweek interview, he appears to be regaining his faith, but still deals with the pain, saying, "But now I have a new relationship with God. I tend to be much more blunt with him." This sounds to me like a good thing; be honest with God and be realistic about what it's like to serve Him.
J.A.W.
P.S. - I just got the 21 May 2007 issue of Newsweek, and there were several letters to the editor on the Faith Under Fire article. Some of them basically agreed with me, but did not identify wimpy theology as the problem.
It becomes clear that during his two tours in Iraq, Benimoff's faith in God is severely tested as he goes about his duties. Though at first his faith appeared to be strong, he became increasingly troubled by the senselessness and carnage of the war. It is related that he often quoted Bible verses to himself and others for comfort, "But it didn't explain why bad things happen to good people, a question Benimoff would face again and again from the soldiers he served with - and
from within himself." When counseling other soldiers, "They would ask me: if I'm a child of God, then why isn't God protecting me?"
The thing that made me want to write this post was a quote from Benimoff's wife, obviously very concerned about her husband's faith and general well-being: "Sometimes he would ask me: why does a loving God allow suicide bombers to attack civilians? We were both brought up with a picture of God that was different from the world he was seeing."
This highlights what I believe is a problem in many Christian churches today. What is this "picture of God" that they found so different from their experience in the real world? Theologians have wrestled with this problem for a long time (there's an understatement for you!), but many basic truths from the Bible can illuminate our understanding of the problem. For example, it is true that God allows "bad" things to happen to "good" people (see the book of Job, for instance). God is also sovereign and acts in ways that are sometimes difficult or impossible for us to understand. For a Bible-believing Christian, this is a given. I think it is due to a "wimpy gospel" that some Christians think we are immune to such troubles when we become believers. Being a Christian is not always "fun" - there are trials and troubles that God
uses to refine us and build our faith in Him. But we need to understand that is the norm, and being a Christian is not a guarantee of a trouble-free, happy-all-the-time existence.
I have great respect for Chaplain Benimoff and all our other servicemen who selflessly work to protect our citizens, our country and our freedoms. But I lay blame on denominations, seminaries, churches, and pastors who preach a warped gospel. We must present a full and well-balanced view of real Christianity, including all the fun and not-so-fun aspects.
After returning to the U.S. to take a tour at Walter Reed Army Medical Center, he wrote in his journal, "I was reading my Bible and I found myself getting violently mad at God." But by the time of his Newsweek interview, he appears to be regaining his faith, but still deals with the pain, saying, "But now I have a new relationship with God. I tend to be much more blunt with him." This sounds to me like a good thing; be honest with God and be realistic about what it's like to serve Him.
J.A.W.
P.S. - I just got the 21 May 2007 issue of Newsweek, and there were several letters to the editor on the Faith Under Fire article. Some of them basically agreed with me, but did not identify wimpy theology as the problem.
Saturday, March 17, 2007
What do Software Architects Do?
In many software organizations, there are job titles like
"Software Architect". What do Software Architects do? That's a great
question, but there is no general agreement on the answer.
I have a friend who is a "real" architect (the kind that designs and
builds buildings) and he tells me that in his industry they are a bit
upset with our industry's use of the term. It's mostly because
Software Architects don't go through anything like the kind of
training, testing, and certification that building architects do. I
think they have a good point.
A recent article by Joe Winchester in the online edition of Java
Developers Journal entitled, "Those Who Can, Code; Those Who Can't,
Architect" really got my attention. The article begins with this:
"At the moment there seems to be an extremely unhealthy obsession in
software with the concept of architecture. A colleague of mine, a
recent graduate, told me he wished to become a software architect. He
was drawn to the glamour of being able to come up with grandiose ideas
- sweeping generalized designs, creating presentations to audiences of
acronym addicts, writing esoteric academic papers, speaking at
conferences attended by headless engineers on company expense accounts
hungrily seeking out this year's grail, and creating e-mails with huge
cc lists from people whose signature footer is more interesting than
the content. I tried to re-orient him into actually doing some coding,
to join a team that has a good product and keen users both of whom are
pushing requirements forward, to no avail. Somehow the lure of being
an architecture astronaut was too strong and I lost him to the dark
side."
Of course, there's a "Software Architect" article in Wikipedia, so I
checked it out. The job description seemed to have a lot to do with
working with stakeholders, getting user requirements, doing cost/benefit
analysis, generating acceptance test requirements, and "generating
products such as sketches, formal diagrams, executable models, an
early user's manual, and prototypes." Except for maybe prototypes,
that doesn't sound like much codin' to me! Where is the need to
actually understand programming?
Winchester continues: "Meanwhile, the architects seem invincible
to failure and rise within the ranks of their organizations, ordering
fresh business cards each year with the words 'architect,' 'senior'
or, for the power blowhards, 'distinguished' in the title. They are
drawn to the tar pit of attending and creating presentations, or
joining conference calls with fellow architects who showboat their
knowledge of obscure standards specifications or bleeding-edge
research projects."
I found that there's an organization called the "Worldwide Institute
of Software Architects (WWISA)". Ironically, the graphic on their web
site's home page illustrates that they do in fact consider themselves
architects in the same sense as the kind who build buildings.
Winchester concludes: "When confronted by such people, recant the
following mantra:
Code ships,
code runs,
code helps users,
get their job done.
Remind any architects in your path that presentation charts, e-mails,
project plans, line-items spreadsheets and so forth, are all there to
help the code ship on time and to spec. The goal of everyone on a
project should be to spend as little time as possible on tasks that
distract from the job of creating quality, tested, and shippable
code. Please architects, please understand this, respect this, and
quietly stay out of the way of those good folk who prefer to spend
their day working with an IDE writing code rather than composing
e-mails."
J.A.W.
"Software Architect". What do Software Architects do? That's a great
question, but there is no general agreement on the answer.
I have a friend who is a "real" architect (the kind that designs and
builds buildings) and he tells me that in his industry they are a bit
upset with our industry's use of the term. It's mostly because
Software Architects don't go through anything like the kind of
training, testing, and certification that building architects do. I
think they have a good point.
A recent article by Joe Winchester in the online edition of Java
Developers Journal entitled, "Those Who Can, Code; Those Who Can't,
Architect" really got my attention. The article begins with this:
"At the moment there seems to be an extremely unhealthy obsession in
software with the concept of architecture. A colleague of mine, a
recent graduate, told me he wished to become a software architect. He
was drawn to the glamour of being able to come up with grandiose ideas
- sweeping generalized designs, creating presentations to audiences of
acronym addicts, writing esoteric academic papers, speaking at
conferences attended by headless engineers on company expense accounts
hungrily seeking out this year's grail, and creating e-mails with huge
cc lists from people whose signature footer is more interesting than
the content. I tried to re-orient him into actually doing some coding,
to join a team that has a good product and keen users both of whom are
pushing requirements forward, to no avail. Somehow the lure of being
an architecture astronaut was too strong and I lost him to the dark
side."
Of course, there's a "Software Architect" article in Wikipedia, so I
checked it out. The job description seemed to have a lot to do with
working with stakeholders, getting user requirements, doing cost/benefit
analysis, generating acceptance test requirements, and "generating
products such as sketches, formal diagrams, executable models, an
early user's manual, and prototypes." Except for maybe prototypes,
that doesn't sound like much codin' to me! Where is the need to
actually understand programming?
Winchester continues: "Meanwhile, the architects seem invincible
to failure and rise within the ranks of their organizations, ordering
fresh business cards each year with the words 'architect,' 'senior'
or, for the power blowhards, 'distinguished' in the title. They are
drawn to the tar pit of attending and creating presentations, or
joining conference calls with fellow architects who showboat their
knowledge of obscure standards specifications or bleeding-edge
research projects."
I found that there's an organization called the "Worldwide Institute
of Software Architects (WWISA)". Ironically, the graphic on their web
site's home page illustrates that they do in fact consider themselves
architects in the same sense as the kind who build buildings.
Winchester concludes: "When confronted by such people, recant the
following mantra:
Code ships,
code runs,
code helps users,
get their job done.
Remind any architects in your path that presentation charts, e-mails,
project plans, line-items spreadsheets and so forth, are all there to
help the code ship on time and to spec. The goal of everyone on a
project should be to spend as little time as possible on tasks that
distract from the job of creating quality, tested, and shippable
code. Please architects, please understand this, respect this, and
quietly stay out of the way of those good folk who prefer to spend
their day working with an IDE writing code rather than composing
e-mails."
J.A.W.
Is Python Ready for Prime Time? Yes!
Is Python Ready for Prime Time?
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
Early signs of the death of SOA?
Trying to follow what's going on in the world of enterprise
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
Hilarious SOA Video
I found an absolutely hilarious video on YouTube (what a surprise!) called "Greg the Architect - SOA This. SOA That." Not only funny, it reflects a strangely ironic, true picture of the state of the current Service-Oriented Architecture
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
Subscribe to:
Posts (Atom)