|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 54
Messages: 54
Messages: 54
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
SOA acceptance among developers?
Java developers who responded to a recent survey put out by CodeFutures, a Java persistence software vendor, showed both strong interest in SOA development and frustration with application production.
Over 75% of those surveyed responded positively to the idea of SOA development, revealing at least widespread acceptance of Web services as mainstream. In addition, those groups maintaining C++ applications acknowledged interest in using C++ Web services.
Developers also admitted to scalability problems, and the majority of participants responded positively when asked whether their applications had high performance requirements or unmet high throughput requirements. This sentiment may be reflected in the POJO movement gaining traction.
Of course, this being a vendor-sponsored survey, these results come from a skewed audience -- which CodeFutures readily admits in the survey text. However, it does leave the reasons for production problems up for debate, and also begs the question: Are SOA and Web services technology being viewed as mainstream in the Java community?
|
|
|
Message #204914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
I doubt that usage of the talkative Web-Service-Protocols will solve any bottlenecks. And for me SOA is just another buzz word flying around. Mix SOA, Offshore-Development and MDA and your manager goes crazy about the resulting buzz-cocktail.
Mike
|
|
|
Message #204919
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.)
BTW - SOA is the mainstream of for Federal government work these days.
|
|
|
Message #204934
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
Did someone use the word "mainstream" and "Federal government" in the same sentence? I have spent 12 years working in Federal Gov't IT, from civilian agancies to NASA, DOD and Postal. I have never seen anything consistent across gov't architectures.
The guys down the hall from me are using Delphi version 5 for a government job.
Mike
|
|
|
Message #204935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA means discreet, reusable, highly decoupled . . .not just XML
Please do not bind or equate SOA with XML.
Web Services certainly can be implemented so that they provide the behavior one would expect from a Service-Oriented-Architecture, but they are not a necessity.
As far as Java goes there are many SOA-ready technologies not the least of which is Jini.
http://java.sun.com/developer/technicalArticles/jini/protocols.html
If only someone would wrap bluetooth in a jini proxy -just think of the fun Java could have! (Shameless query to learn if this has been done or is in the works. . .)
Any takers?
Owen
|
|
|
Message #204936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. [rest deleted]
I agree that SOA does not necessarily need to be implemented using Web Services, but I do think that one of the primary shifts from traditional n-tiered architectures is the idea that SOA should support "easy" interoperability. So, if you're using Tuxedo and C to deploy things that ostensibly look like services, but require clients to be written with a specific language or toolset, I don't think that it would meet the definition that most architects use for SOA. However, if you were to provide access to those same services via XML messages (for easy interoperabilty) over an easily accessible transport mechanism, then it would certainly meet my definition of SOA, even if Web Services standards weren't followed.
|
|
|
Message #204940
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.) BTW - SOA is the mainstream of for Federal government work these days. IMO SOA is nothing more that a new word to spread to try to
sell something (old products - beware, I don't mean bad here - in the case of ESB).
There is really nothing that you can't do with plain-old-DOC-framework (namely CORBA and ICE from ZeroC).
Yes, SOA is not WebService, sure!
Please, can you tell me a SOA not based on web services ?
It is funny to read in the survey the suggestion about vendors lock-in avoidance.
Want to talk about server-side JAXRPC specs ?
CORBA is lightyears far away for what concerns portability on both client and server side.
But now we have SOA that automagically gives perfect architectures !!
No, stop! Noone said that SOA is a one-size-fits-all !!
Strange, the percentages in the survery seem to show something different.
Anyway, it's a deja vu. It was the same with J2EE.
And now to leit motiv is: don't use J2EE if you don't have a good reason to, use SOA!
Until the next silver bullet with someone saying (maybe the same SOA-based products vendors): YOU were wrong using SOA for everything !
Guido
Hearing Alanis Morissette (Crazy) in the distance....
|
|
|
Message #204941
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
I also see SOA as a computing architecture that goes well beyond the implementation specifics of web services and XML. I see developers specializing in one or more of the building blocks that go into an SOA - Identity Management, Service Policy, Security, Workflow, Service Management, Quality of Service, to name a few. I am currently in the process of putting together a web site to demonstrate SOA from concepts through architecture to implementations.
http://www.soamodeling.org
It is based on work by the OASIS SOA Reference Model Technical Committee. The SOA RM TC currently has a SOA Reference Model document open for public review. Public review comments are encouraged.
http://www.oasis-open.org/committees/download.php/16628/wd-soa-rm-pr1.pdf
Danny
|
|
|
Message #204943
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
The survey is been conducted by a vendor whose products are into persistence tier. I am kind of surprised about CodeFutures conducting this survey where SOA is not their primary business.
My personal experience with many of SOA product implementation in a supply chain management domain with large Rosattanet XML documents was quite bad. Especially the Java XML parsers are too slow to provide a good infrastructure for this development. The performance was horrible!!!
|
|
|
Message #204944
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
Please, can you tell me a SOA not based on web services ?
Guido,
I've been implementing SOA since the early 1990's. In the 1990's Tuxedo was the best middleware for implementing SOA. Java EE application servers are pretty much modeled after Tuxedo which is why it was so easy for me to transtition to them around 1999. CORBA could also be used for SOA and I know some folks who claim to have done so. Of course using either technology, or web services for that matter doesn't make it SOA. There is more to it than the technologies you use.
Bill
|
|
|
Message #204945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
I agree that web services technologies makes services more interoperable. Tuxedo/C and CORBA, etc. were less capable from that stand point. I'm just saying that deploying services - web or not - does not make an SOA. Its the underlying architecture - effectively an n-tiered component based architecture that makes it SOA. Components are service ready though many are too fine grained to be used as remote services. What components have are contracts, encapsulation, independent deployment and versioning. You can easily compose services from one or more components by adding a service facade in front of them. That is where the reuse and other benefits touted for SOA really come from.
BTW, are you the Dru I used to know in Chicago?
|
|
|
Message #204946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA means discreet, reusable, highly decoupled . . .not just XML
You are correct when saying that loose coupling and reusability are the true hallmarks of an SOA system. It would be better if you said "SOA != Web Services" since that is the more common mistake. While SOA != XML as well, XML is much more "SOA ready" than something like Jini. Jini requires Java awareness, usually through a proxy. That is hardly loose coupling. The adoption of web services and SOAP is largely because of the interop problems caused by things like Jini proxies.
|
|
|
Message #204947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
Guido,I've been implementing SOA since the early 1990's. In the 1990's Tuxedo was the best middleware for implementing SOA. Yes, I remeber. Maybe the name of the architectures was different at that time :)Java EE application servers are pretty much modeled after Tuxedo which is why it was so easy for me to transtition to them around 1999. I have a clear memory of an IBM framework to invoke CORBA object via HTTP URLS where XXX object were created using XXXHome....
At that time Java was at version 1.1 (maybe 1.2).CORBA could also be used for SOA and I know some folks who claim to have done so. Of course using either technology, or web services for that matter doesn't make it SOA. There is more to it than the technologies you use. Bill I feel like vendors saying something different.....
I am really tired..
Guido
|
|
|
Message #204948
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
I agree that web services technologies makes services more interoperable. Tuxedo/C and CORBA, etc. were less capable from that stand point. Oh no, this is too much!!
Do you really think that CORBA is less interoperable than web services ?
When you say this, do you refer to the specs or to particular implementations ?
Guido
|
|
|
Message #204949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA means discreet, reusable, highly decoupled . . .not just XML
Well, reading suggestion might sound offensive but it is not my aim.
There are some interesting articles in ICE Connections (www.zeroc.com) about web services and decoupling that might be useful.
Guido
|
|
|
Message #204952
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
Did someone use the word "mainstream" and "Federal government" in the same sentence? I have spent 12 years working in Federal Gov't IT, from civilian agancies to NASA, DOD and Postal. I have never seen anything consistent across gov't architectures.The guys down the hall from me are using Delphi version 5 for a government job.Mike Yeah, I've contacts in DOD contracting and I've heard the same sort of thing.
|
|
|
Message #204957
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA indifference among developers?
Erl has a nice but big book on Service-Oriented Architecture (Prentice Hall) where he discusses the "contemporary" definition of SOA. He says the current definition is web service-centric. It's not required but assumed.
I have to think that people are waiting for WS-Security and WS-ReliableMessaging to be more transparent and fulfill nonfunctional requirements you can meet with current J2EE app servers. The great thing about Stateless Session EJB remoting is the ability to pass a security and transaction context, or even XA. Once you get the messaging A HA moment and then start modeling and expose services via MOM and SOAP you run into the problem of managing all this orchestrated crap. Yeah, there are tools but at a price. Hermes is a start.
I am following ServiceMix and Mule. The difference seems to be that ServiceMix starts with WSDL while Mule starts with object interfaces. Until then non-schema constrained XML messaging via XStream seems to cut it.
|
|
|
Message #204962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Orchestrated crap, meet dynamic composition
...Once you get the messaging A HA moment and then start modeling and expose services via MOM and SOAP you run into the problem of managing all this orchestrated crap... Note: I work for Xcalia.
This is exactly the value proposition of Xcalia Intermediation Core. By using service metadata to intermediate and dynamically compose services at runtime, you are free from this burden. Before you bash me for recommending it, at least try to understand it:
Design-time:
1. Describe your databases (any kind, relational or otherwise) & services (any kind, web services, EJB session bean, or anything else callable from Java) using metadata.
2. Build a POJO model that captures the business adequately.
3. Build a composite application against the domain model and a persistence API (JDO & SDO now, EJB in the future).
Runtime:
4. Your composite application manipulates the POJO model.
5. XIC dynamically invokes whatever services and databases necessary in response to the work done on the POJO model.
These are the broad strokes. If you don't understand it right away, that's ok; I guess I suck at explaining it. It does take a while to wrap your brain around it, though. An easy way to understand it is to realize that dynamic composition does for orchestration in an SOA what ORM does for writing SQL code -- frees you from the burden of writing it.
--matthew
|
|
|
Message #204970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA is a concept and practice
Does anybody know what exactly SOA is? Can we have a list of differences between a SOA and non-SOA system?
As far as I know it's all about decoupling and there is nothing specific about a technology like web services! So to me it's more a concept and practice than a standard or specification.
You are doing SOA, as long as you are delivering decoupled components.
|
|
|
Message #204972
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Management and SOA
Hi,
the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design.
As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.
Chris
|
|
|
Message #204973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA seems to be this year's buzzword. It is hard to get excited about it. It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same. Call it what you want.
Even if the term SOA had a meaning by the time vendors get done with it.... it will not have a meaning any longer.
It is a floor wax and tooth paste. It whitens your teeth and cleans your grout.
SOA. SOA. SOA. SOA. Samiliaaan. (music)
Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting
|
|
|
Message #204974
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Management and SOA
Hi,the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design. As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.Chris
Based on your description, it sounds like something we should all consultants should learn as their is money to be had. Darn truth serum! :o)
Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting
|
|
|
Message #204975
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Management and SOA
Hi,the main problem with SOA is that it is a) nothing really new, just another name for "do it all with web services", and b) managers think it is something really new that will solve all problems with poor architecture and infrastructure design. As a result, our management starts salivating when they read white papers about SOA and BPEL, and command that every project uses these technologies, no matter if the software is suited in any way or something can be gained from the exercise.Chris Based on your description, it sounds like something we should all consultants should learn as their is money to be had. Darn truth serum! :o)Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting
Let me try that again.
Based on your description, it sounds like something all consultants should learn as their is a lot of money to be had. Darn truth serum! :o) (Too much serum!)
|
|
|
Message #204980
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA means discreet, reusable, highly decoupled . . .not just XML
While SOA != XML as well, XML is much more "SOA ready" than something like Jini. Jini requires Java awareness, usually through a proxy. That is hardly loose coupling. The adoption of web services and SOAP is largely because of the interop problems caused by things like Jini proxies.
Excuse me whilst I cough, but I believe that XML is no more SOA ready than any other _data_ format. Even though you are correct that Jini requires java - it only requires java somewhere on your network. The decision to not look at cross-language problem was key in Jini, which essentially the SOAP concept renders inert, because every language has XML right!?
http://blogs.sun.com/roller/page/jag?entry=only_solve_the_problems_you
SOAP is a protocol, XML is a data format, just like JRMP is a protocol and serialized java objects are a data format.
Protocols and Data formats do not a SOA make.
SOA is about the contracts between service and client, and how you can meaningfully use these contracts and services together, dynamically, to provide your architecture.
IMO, SOA is far too focused on the business process arena; Services should be exposed much further into your infrastructure to provide re-use further inside your applications, so that services themselves depend upon other services. Because of this current focus, Web Services gain adoption, exposing business processes to third-parties via services and using XML as a transmission format - great, but this is not what Services Oriented Architecture is all about, it's really only a tiny fraction of SOA. There are things about SOA that many people ignore; partial failure, clustering, failover, etc.
My main gripes about Web Services et al, are about how long it takes to actually standardise and mobilise these standards-infatuated companies to actually push proper specs and implementations out the door.
|
|
|
Message #204981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
I am saddened by seeing developers humming along to marketing tunes.
|
|
|
Message #204982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA seems to be this year's buzzword. It is hard to get excited about it. It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same. Call it what you want.Even if the term SOA had a meaning by the time vendors get done with it.... it will not have a meaning any longer. It is a floor wax and tooth paste. It whitens your teeth and cleans your grout.SOA. SOA. SOA. SOA. Samiliaaan. (music)Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting
Whether ideas and technologies succeed or fail is largely down to timing. Is the business and technological environment right for them? The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation. Yes, we have heard it all before with things like CORBA, but I think the difference with SOA is that the timing is better. There are more technologies available to support the model that have been tried and tested. Things like Java, XML, JMS, WSDL, WS-Security.
I work for a very large global organisation. Most integration up to now has been point-to-point. No one has, or even no small group of people have, a complete picture of what systems we have out there doing what. It's difficult to quantify, but I reckon the costs resulting from such complexity runs into $millions. In these sort of environments, something SOA-like is desperately needed.
If you are concerned with individual projects, SOA may be less obvious. But put your project within the long term landscape of systems and assets a company owns and SOA should be a bit more meaningful.
Regards
Kit
|
|
|
Message #204989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Same Old Architecture - now with webservices
It is the same stuff that we have been talking about for 13 years (longer really). The names change, but the concepts are the same.
Precisely - which is exactly why
- SOA has been called Same Old Architecture by some insightful cynic
- i argue that if we also remove webservices from the definition of SOA (as some have argued here) then we are left with...nothing at all. If SOA, however, means "the Same Old Architecture implemented on top of the webservices stack", as it does in my perception of reality in 2006 anyway, then we are at least left with a term that carries some meaning.
cheers,
gerald
http://www.gerald-loeffler.net
|
|
|
Message #204990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA is not a development only
SOA is an architecture that includes the following repeatitive phases :
1. Modeling
2. Assembling (Development)
3. Deploying
4. Monitoring
and go again in that cycle from start. Development is just the second phase.
|
|
|
Message #204991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
WebServices don't provide transactions at the moment, so the only thing you can integrate with them is something as mission-critical as a weather service and a socks selling website. Corba or MoM does better with it.
Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten.
|
|
|
Message #204993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten.
Ditto! I'm seeing exactly the same thing on a large scale SOA project I'm working on at the moment.
The Service contracts are being drawn up by business analysts in practical isolation. They view the contracts purely on a document basis with little/no regard for how those contract definitions will get consumed by the end user i.e. when Java stubs are generated from them, the resulting model is a mess and the stubs would be a pain to use.
I think there needs to be more balance in situations like this. Sure these contracts can be viewed as business entities blah blah blah but at the end of the day some poor developer is going to have to use them. If they're a steaming pile of unuserfriendly poo????
Of course, I do believe it is possible to draw up solid contracts that translate into usable interfaces at a code level. I just don't think it's likely to happen when these contracts get thrown over the wall by analysts.
|
|
|
Message #204994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
Is SOA a buzzword - sure. The IT industry is always going through buzzwords. Remember Component based development and Client server? In all cases they are just a way of thinking and have nothing to do with specific technology per se.
So you can build a SOA using pretty much anything at all from files, to MOM to CORBA to Tuxedo to HTTP. Pointy brackets are not manadatory :). The simplest way to start building a SOA is typically just to use a MOM; then all you need to worry about is getting messages on and off the bus - not grokking the whole WS-* and the issues of getting different vendors WS-* to work together.
FWIW I remember working on my first SOA back in '89 (yes I am that old :-) at JP Morgan where we had a distributed trading system with real time pricing, P&L, position keeping, order matching and settlement gateways live in multiple countries over WAN & LAN. Back in those days we wrote our own SOA technologies in C/C++. Thankfully these days you can just reuse a bunch of great open source code to make a SOA - most of what you need is all at Apache these days.
I tend to think of the talk of SOA as similar to that of Design Patterns; a discussion of best practices which you can implement using whatever technology you choose.
James
LogicBlaze
Fuse: the Open Source SOA runtime
|
|
|
Message #204995
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
The Service contracts are being drawn up by business analysts in practical isolation.
Are you using any formal development process (eg. Rational Unified Process)?
According to RUP interfaces (especialy the high level ones) should be specified by the architect (architecture team). Architect is the person who understand both business and technology aspects of the system. And interfaces are extremely "architecture-significant" elements of the system.
And in my opinion low level interfaces shouldn't implemented as WebServices.
Marquis de Flore
IBM RUP Certified
www.enterpriseware.pl
|
|
|
Message #204996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Are you using any formal development process (eg. Rational Unified Process)?
The requirements gathering and analysis process is RUP based. The whole process is a mishmash of RUP and SCRUM and prob others. I'm not sure where it came from!
According to RUP interfaces (especialy the high level ones) should be specified by the architect (architecture team).
I guess I meant that somewhat tongue in cheek, but in my situation it is the case that the analysts "own the public interface". If they don't like something that goes in there it comes back out, but not necessarily the other way around. I'm sure the architects have (on paper at least) a degree influence, but I'm not convinced how effective it is. Of course a lot of this could be the individuals involved - we're talking about a large org here so I'm not totally familiar with all the personalities.
I personally think the interfaces needs to be modeled in an iterative way with feedback coming from all levels - analysts, architects, dev, qa. These business interfaces are used by different people in different ways and, as much as possible, should be user friendly to all. I think this requires an iterative process and no one group should "own" anything.
|
|
|
Message #205004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
I think this requires an iterative process and no one group should "own" anything.
I totaly agree about the iterative aproach and feedback from different users but it is a good practice that every artifact has a person responsible for. (and the basic management rule says that if someone is responsible for something he also has to have decision making permisions for it - no one wants to be responsible for someone else decisions).
If many people are responsible for something it means no one realy cares. It is especialy true in large organisations :-)
Marquis
www.enterpriseware.pl
|
|
|
Message #205007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
...it is a good practice that every artifact has a person responsible for....
I totally agree with you, someone/somegroup always needs to have ownership and responsibility. I guess what I'm really saying is that no one discipline should own something as important as this. Perhaps that means some sort of "overview" type group which has representation from all disciplines. If it fails after that, these people get their asses kicked.
Another point on the responsibility and ownership topic. I often see that because organisations reorg at sometimes ridiculous rates, it ends up that nobody is effectively responsible anyway because by the time that crap decision starts a fire somewhere, the person that made it is off working on something else and whoever "owns it" now simply blames the reorg and the fact that they didn't make the decision.
|
|
|
Message #205015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation.
How will that work when more often than not one programmer can't explain the interface to his class to the programmer sitting next to him?
I know, I'm mixing metaphors (or something like that). The said programmer probably can (with a little training or reference material) write a magical SOA descriptor for his class (or service, or whatever you want to call it). But that doesn't change the fact that no one but him understands what it does.
|
|
|
Message #205016
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Another point on the responsibility and ownership topic. I often see that because organisations reorg at sometimes ridiculous rates, it ends up that nobody is effectively responsible anyway because by the time that crap decision starts a fire somewhere, the person that made it is off working on something else and whoever "owns it" now simply blames the reorg and the fact that they didn't make the decision.
From the Tao of Programming:A novice asked the master: ``In the east there is a great tree-structure that men call `Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying `Go, Hence!' or `Go, Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity be?"
The master replied: ``You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?''
|
|
|
Message #205019
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA indifference among developers?
Mule is looking like the new Spring, I'm also following with great interest.
|
|
|
Message #205020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
The essence of SOA is being able to describe a service interface in a standard, platform-independent format, and being able to map that interface to an underlying implementation. How will that work when more often than not one programmer can't explain the interface to his class to the programmer sitting next to him?I know, I'm mixing metaphors (or something like that). The said programmer probably can (with a little training or reference material) write a magical SOA descriptor for his class (or service, or whatever you want to call it). But that doesn't change the fact that no one but him understands what it does.
This is a good point.
One of the things that companies creating service registry products have realised is that creating a service doesn't mean that everyone will magically use it, even in closed internal environments. Newer registry products have alot of space where the service designer/developer can document their service, including constraints, contracts, QoS, etc.
Quite apart from detailing the service technically, it can also act as a marketplace for services.
Regards
Kit
|
|
|
Message #205022
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
BTW, are you the Dru I used to know in Chicago?
Hi Bill,
Yep, that's me. :)
Dru
|
|
|
Message #205033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Another thing is that SOA on low level can break OO designs. I saw already a couple of Java/J2EE systems where everything was "services" and OO design/programming was considered by developers as some problematic idea that's better to be forgotten. Ditto! I'm seeing exactly the same thing on a large scale SOA project I'm working on at the moment.The Service contracts are being drawn up by business analysts in practical isolation. They view the contracts purely on a document basis with little/no regard for how those contract definitions will get consumed by the end user i.e. when Java stubs are generated from them, the resulting model is a mess and the stubs would be a pain to use.I think there needs to be more balance in situations like this. Sure these contracts can be viewed as business entities blah blah blah but at the end of the day some poor developer is going to have to use them. If they're a steaming pile of unuserfriendly poo????Of course, I do believe it is possible to draw up solid contracts that translate into usable interfaces at a code level. I just don't think it's likely to happen when these contracts get thrown over the wall by analysts.
Hmmmm.... I am not sure this is a problem with SOA or just stupid developers. Some folks tend to take an idea and pound it to death.
Example: I've seen this "if design patterns are good, then I should try to use every design pattern in the book". I've seen it done, and it ain't pretty.
Another Example: I've seen people do some strange things with AOP and DI. This does not mean AOP and DI are bad.
Unlike AOP and DI, SOA will become a very large marketing mumbo jumbo mess and will loose all meaning.
Our XYZ product is fully SOA compliant.
SOA already seems to have so many definitions that the term is near useless.
|
|
|
Message #205035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Of course it goes without saying that Design Patterns (DP) are good. But, like anything (SOA), they can be misapplied.
I was refering to using DP just for the sake of it (and as many as they could. You could tell where they stopped reading in the book b/c those DPs were not there.)
|
|
|
Message #205036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Of course it goes without saying that Design Patterns (DP) are good. But, like anything (SOA), they can be misapplied.I was refering to using DP just for the sake of it (and as many as they could. You could tell where they stopped reading in the book b/c those DPs were not there.)
Here. I'm in total agreement with you. It's called the Golden Hammer syndrome/anti-pattern... "if all you have is a hammer, everything looks like a nail!".
I'm also in agreement with you re AOP and DI. Are you working on the same project as me by any chance ;-)
On AOP, I've always sorta avoided using AOP because I always seemed to be able to find another way of doing whatever I was trying to do without AOP. I'm a conservative sort of guy - been burned too many times before. I've been waiting for a project where someone with AOP experience could show me how to use AOP sensibly. So, along came the project I'm currently working on and there's AOP.... loads of AOP... in fact, the way things are going we're soon going to just have empty main methods with Spring configs full of interceptors. It's a royal PITH in my opinion. An interceptor is the answer to every problem. So, I guess I've learned how not to use AOP at any rate!
This goes for anything - AOP, DI and whatever else you're having... There's usually a place for them all, but not on every project or every problem...
|
|
|
Message #205039
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
Example: I've seen this "if design patterns are good, then I should try to use every design pattern in the book". I've seen it done, and it ain't pretty. Another Example: I've seen people do some strange things with AOP and DI. This does not mean AOP and DI are bad.
Usually the victims of Pattern Compulsive Disorder also fall prey to the "let's find a convoluted way to use AOP because it's cool" mental disease. The consequences are disasterous.
Unlike AOP and DI, SOA will become a very large marketing mumbo jumbo mess and will loose all meaning.Our XYZ product is fully SOA compliant. SOA already seems to have so many definitions that the term is near useless.
I'd say it has already lost all meaning and become utterly useless. Just re-read this whole thread and count the number of meanings: to each his own. It's a new concept but everyone was doing it 20 years ago; it's entirely XML/WS*-based but has nothing to do with XML/WS*; it's a paradigm and a philosophy... Etc ad infinitum.
I'm sure sinners use SOA whitepapers to fuel the furnace in hell.
|
|
|
Message #205050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA w/o Web Services
SOA definitely doesn't mean Web Services. The site I work on is very service oriented, we dispatch to the services using all kinds of various methods:
- Straight HTTP (REST-ish)
- MQ
- EJB
- JINI
- and some Web Services
The product vendors may be rallying around Web Services but you can certainly do SOA without them.
|
|
|
Message #205054
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
After reading these posts I get the feeling SOA is too lofty and out-of-the-scope of mere developers. Maybe it has to be bought on the golf course by CIOs and crammed down the throats if IT as a top-down strategy. Sounds like this group is at the "expose an api as a web service on an ad-hoc basis or setup an internal queue" level of adoption.
On Maslow's Hierarchy of Needs, SOA must be on the high end for most developers or even companies. I don't hear developers being forced to use an existing package in these posts.
The trends that will drive SOA as I see it are mergers & acquisitions driving integration, Microsoft parity, and continuous flow batch processing across cheap boxes. Sort of SETI@work.
Services are an abstraction and don't dictate web services. But! Web services are driving the latest CORBA-esque markitecture. Yes, old wine in new bottles but the wine has aged a bit and mellowed. Sommalier oriented architecture.
-andrew
|
|
|
Message #205058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
There is no reason SOA would necessarily break OO designs. SOA extends component based architecture, but services realize use cases. The components you compose services from are high level objects from your object model. Components are not pure problem domain objects themselves. They are controllers that wrap objects that implement certain functionality. CBA derives from OO but incorporates notions of frameworks and architecture. Though individual components may become services, they are often too fine grained to be good services. They may not be a complete unit of work either. CBA is the parent of SOA and its certainly consistent with good OO design.
Investigate component-based architectures to get a better understanding of components and how to define and implement them. Amazon has some good books on the subject.
|
|
|
Message #205060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA acceptance among developers?
SOA is not web services! SOA extends component based and 3-tier architectures. Web services are just a buzz word for some technologies that can be used to implement services. You can do SOA in Tuxedo in C if you want. For internal services I prefer MOM and an ESB over HTTP ptp. The XML SOAP stacks that try to imitate what MOM already does over HTTP may have some use on the edges, but if you really needed to use a number of them you'd be better off using MOM. (For Java folks: you use JMS to access MOM.) BTW - SOA is the mainstream of for Federal government work these days.
I'm repeatedly shocked at how few people actually understand this concept. William is 100% correct. The WS-* stack is simply one of many wire protocols for services. IMO, nothing about SOA requires you to use web services.
|
|
|
Message #205082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Statefull SOA using POJO and Spaces
Developers also admitted to scalability problems, and the majority of participants responded positively when asked whether their applications had high performance requirements or unmet high throughput requirements. This sentiment may be reflected in the POJO movement gaining traction.
I believe the POJO based approach for SOA is the right way to go. Projects like mule provides a very good reference on how this could be accomplished.
"Stateful SOA applications are distributed applications that require integration with each other on two dimensions: communication and state. Many workflow scenarios fall into this category, as well as distributed computing applications. Normally, state iz shared through a centralized resource - such as a file system or a database which often creates a scalability and performance bottleneck. Maintaining consistency in such environments also requires the use of a distributed transaction coordinator with an XA interface, which significantly impairs performance. Typical deployment environments require three separate sub-systems: messaging, database and transaction coordination, which significantly add to the complexity of such environments from a programming perspective (complexity of APIs and number of APIs). From a deployment perspective, maintaining high availability in such systems often involves integration of separate high availability solutions for each of the three sub-systems. From a cost and licensing perspective, this approach can be relatively costly as it introduces a need for multiple licenses, often from different vendors. This lack of efficiency also results in a requirement to use additional costly hardware resources to meet the application's scalability and performance requirements."
You can find more detailes on this approach in the following paper:
Stateful Service-Oriented Architectures Using Mule and GigaSpaces
You can try a free version using the following url:
http://mule.codehaus.org/JavaSpaces
Nati S
CTO GigaSpaces
"Write Once Scale Anywhere"
|
|
|
Message #205164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reliability of WebServices ?
I'd say it has already lost all meaning and become utterly useless. Just re-read this whole thread and count the number of meanings: to each his own. It's a new concept but everyone was doing it 20 years ago; it's entirely XML/WS*-based but has nothing to do with XML/WS*; it's a paradigm and a philosophy... Etc ad infinitum.I'm sure sinners use SOA whitepapers to fuel the furnace in hell.
But that has as much to do with ignorance than ambiguity. Much of the definitions of SOA on this thread seem to be loaded with ignorance.
(The rest of the post is not aimed at the previous post).
We all know what object orientation means now because people had time to define it's meaning and come up with some clear definitions. It too had been around in practise for a long time before it became distilled into languages and hit mainstream appeal. It had mainstream appeal because the complexity companies and developers were dealing with was exploding, the complexity of systems in even small companies was requiring a paradigm which helped to manage the complexity.
SOA is no different really, it's a concept that's bean around for a while but has not been a priority for many companies since they have had a handful of services and systems. Now with the IT systems explosion even small companies can end up with dozens of little IT systems. So it's now a priority to reuse existing services rather than existing code and to manage the complexity again with a paradigm that encourages you to abstract a complex system into smaller subsystems. In time the definitions will become clearer also.
To me the parallel is very clear and SOA unlike AOP has immediate and large scale usages and appeal. The ignorance comes when developers see the usual nonsense trotted out by venders to sell their SOA systems.
So stay clear of the nonsense, look carefully at some of the developer friendly SOA products (like Mule) and see how it allow us to work at a higher level of abstraction at development time, not just at design time.
|
|
|
Message #205283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
heard before
Excuse me, but I remember, I heard a lot of these arguments 20 years ago, when I argumented for using OO. 'Nothing new here', 'You can do this in Cobol or C too' etc.
Never mind if the arguments were right or wrong, it is unquestionable, the OO sat focus on modelling and encapsulation, and so did a lot to quality and reuseability.
Same thing with SOA, a lot of discussions on technical aspects (no offending, because we are technicians), but the important part of SOA is, that it sets focus on modelling with services, which are high-level, business things, and so will do lot to quality and reuse, I hope.
/Hardy Henneberg
|
|
|
Message #205335
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Newbie question
What's SOA all about after all?
Is it SOA a component architecture with a OPEN, EASYLY IMPLEMENTABLE, WHICHEVER IT IS, communication stack?
|
|
|
Message #205440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Newbie question
What's SOA all about after all?Is it SOA a component architecture with a OPEN, EASYLY IMPLEMENTABLE, WHICHEVER IT IS, communication stack?
Simple! It stands for Service Oriented Architecture.
It is a term coined by service providers used to refer to an architecture that will lead to increased sales of services.
IBM Global Services estimates that for every customer that it convinces to switch to SOA there will be a 75% in revenue (meaning IBM will sell more services).
Other, smaller service providers are expecting even greater increases in revenue from customers transitioning to SOA.
|
|
|
Message #205593
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA is the computing platform of the future
Leaving aside the hype and greediness boiling around SOA, my opinion is that SOA based in WS-* (i.e. not abstract SOA) is the platform of the future, which will allow to run, interoperate with, integrate and reuse most software developed by anyone. It will deliver the long soughted goal of reuse of code, in practice.
It is not that WS-* it is the best technology or that it is superior to other ones doing the same (CORBA, Jini, RMI, DCOM, whatever). It is that everybody supports it. This delivers interoperability in practice, not in theory.
More about this at http://javicamara.blogspot.com/2006/01/soa-platform-to-rule-them-all-and-in.html .
I do not care whether it is WS-*, REST or whatever, but we need such a universal interoperability framework in practice. WS-* is the best positioned to be so, because the key is not technology, but endorsement.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
