 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2006What is SOA?
I have been trying to read and understand what it means by SOA (Service Oriented Architecture). Are there any definitive guides/tutorials/references that I can refer to? It will be better if the references avoid clutter and fluff and give some tangible examples about why SOA matters. I am especially interested in this because of a recent article: http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci119821 1,00.html Thanks, >I have been trying to read and understand what it means by SOA (Service > Oriented Architecture). Are there any definitive > guides/tutorials/references that I can refer to? > > It will be better if the references avoid clutter and fluff and give > some tangible examples about why SOA matters. I asked a similar question in an Eclipse newsgroup, and someone pointed me to: http://www-306.ibm.com/software/rational/mda/papers.html I haven't actually read all of the articles there yet, and I still don't have a clear understanding of what SOA is exactly, but maybe this'll get you started in the right direction. - Oliver >>I have been trying to read and understand what it means by SOA (Service >> Oriented Architecture). Are there any definitive [quoted text clipped - 5 lines] > I asked a similar question in an Eclipse newsgroup, and someone pointed > me to: http://www-306.ibm.com/software/rational/mda/papers.html Oops, after actually re-checking the link, I noticed that it only deals with MDA, and not SOA. Here was the original question I had asked on the newsgroup: <quote> If I'm just a lowly Java programmer, and I'm hearing "SOA is the next big thing, MDA is the next big thing, if you want to do MDA, you should use EMF" and I want to find out more about what all these TLAs mean, is there a document out there for me? </quote> So I guess the poster addressed the MDA part, but not the SOA part. Sorry about that. - Oliver >>>I have been trying to read and understand what it means by SOA (Service >>> Oriented Architecture). Are there any definitive [quoted text clipped - 9 lines] > with MDA, and not SOA. Here was the original question I had asked on the > newsgroup: Okay, after a bit of googling on my own, I found these: http://en.wikipedia.org/wiki/Service-oriented_architecture Wikipedia article on the topic. http://java.sun.com/developer/technicalArticles/WebServices/soa3/ "Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK" By Gopalan Suresh Raj, Binod P.G., Keith Babo, and Rick Palkovic, May 2006 It sounds like a fancy name for a pretty simple concept: A bunch of computers communicating to each other over the Internet. More accurately, you have a bunch of servers on the Internet, each providing some high-level service. For example, Google offers the service of letting you search the web. Amazon offers the service of letting you buy stuff. Previously, it was mostly humans using this service, but there isn't any reason why you couldn't write a bot to do the web surfing for you, and act as a consumer of those services. So it sounds like SOA basically a formalization of that idea. You've got Google Maps, which provides a nice UI for map-related services, and exposes a useful API for web developers. You've got eBay which lists auctions along their approximate locations of the sellers. You've got FedEx which lists estimated shipping costs and time from one location to another. You could write a new service (in PHP, J2EE, RubyOnRaisl, or whatever you want) which consumes those three services and provides a new one: An local-availability auction-searching tool. Let's say I want to search for an XBox360 near my city, Montreal Quebec. This new service will show a map (using Google Mapses service), and put icons at each of the approximate location of the sellers who could be in Canada, the United States, Great Britan, Japan, Australia, etc. (using eBays service), and have arrows flowing from those locations to my locations with estimate shipping charges and time (using FedExs service). Maybe a little table on the left hand corner so I can sort by ascending total cost (including shipping), or ascending duration of shipping. That's my understanding of it, anyway. - Oliver > >>>I have been trying to read and understand what it means by SOA (Service > >>> Oriented Architecture). Are there any definitive [quoted text clipped - 49 lines] > > - Oliver Yep, and on top of that there are transaction specs so, you can effectively make a roll back processes across multiple servers. There are security specs, and on and on. One thing that has me perplexed though is Monsol-Haeffel's (sp?) latest schtick about how SOA will destroy Java EE. Java EE sounds great in developing SOA systems. http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf found this diagram....very cool http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf > found this diagram....very cool Or, as I would prefer to call it, "horrifying". -- chris > http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf > > [quoted text clipped - 3 lines] > > -- chris Eh, if they put all the packages from java.* and javax.* in a single diagram, it would be just as scary to noobies. http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf > > > found this diagram....very cool > > [quoted text clipped - 4 lines] > Eh, if they put all the packages from java.* and javax.* in a single > diagram, it would be just as scary to noobies. Java class libraries are /supposed/ to be made up of lots of small classes which interact in potentially complex ways -- that's how we manage the necessary complexity of programming. Standards are /not/ supposed to be complex assemblages of interacting documents. When I look at a chart like the one linked to above, I see a design/standardisation process gone horribly wrong. -- chris > Java class libraries are /supposed/ to be made up of lots of small classes > which interact in potentially complex ways -- that's how we manage the [quoted text clipped - 5 lines] > When I look at a chart like the one linked to above, I see a > design/standardisation process gone horribly wrong. The other interesting thing worth noting is that the "standards" there range between several different standardizing organizations, or in many cases none at all. A lot of the basic stuff is W3C-based, but then the others (including most of them that I haven't heard of before now) are documents published by one vendor or another, or standardized by OASIS, which is a standardization body that appears to have popped up for the *sole purpose* of writing and approving yet more specifications for web services. Good thing we can ignore all that and just write relatively straight-forward web services with SOAP and WSDL.  SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation > The other interesting thing worth noting is that the "standards" there > range between several different standardizing organizations, or in many [quoted text clipped - 5 lines] > services. Good thing we can ignore all that and just write relatively > straight-forward web services with SOAP and WSDL. And even the SOAP and WSDL specs seem to have been written by two groups who have never spoken with each other. > http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf >> >> found this diagram....very cool > > Or, as I would prefer to call it, "horrifying". You think the diagram's horrifying? Try reading most of the standards. http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf > > > found this diagram....very cool > > > > Or, as I would prefer to call it, "horrifying". > > You think the diagram's horrifying? Try reading most of the standards. You mean to say they don't have the relative simplicity and orthogonality of the classes in java/javax ? That's a crushing disappointment. ;-) -- chris P.S. my personal "favourite" standard is RFC 2543 ("Session Initiation Protocol") -- 150-odd pages of impenetrably complicated and intricate design to achieve almost nothing. > http://www.innoq.com/soa/ws-standards/poster/Web_Services_Standards_09_2005.pdf > > > > [quoted text clipped - 10 lines] > > -- chris java.util.Date, java.util.Calendar, java.util.GregorianCalendar, java.sql.Date, java.sql.Timestamp, java.sql.Time. C'mon, we are java programmers who love our language but let's be realistic, many java and javax classes are not a) simple or b) orthogonal. Take managing a date in java for example. [me:] > > You mean to say they don't have the relative simplicity and > > orthogonality of the classes in java/javax ? That's a crushing > > disappointment. > [...] > java.util.Date, java.util.Calendar, java.util.GregorianCalendar, > java.sql.Date, java.sql.Timestamp, java.sql.Time. Am I not allowed to exaggerate a little when making a point ? Usenet would collapse ;-) -- chris > [me:] > > > You mean to say they don't have the relative simplicity and [quoted text clipped - 8 lines] > > -- chris Alright, alright, good point. ;) All right folks. That was a delightful thread. Thank you. One small follow-up question though -- it appears to me that if I am reasonable comfortable with web-service paradigm of programming on the web, can I say I am comfortable with SOA (at least conceptually)? The problem I have is that of feeling. I get scared with jargon. Regards, > All right folks. > [quoted text clipped - 6 lines] > > Regards, Yep, Check out JSR 208 (http://www.jcp.org/en/jsr/detail?id=208), the Java Business Interface on more details how java will be handling SOA. JSR 208 currently is also integrated in project glassfish too. > One small follow-up question though -- it appears to me that if I am > reasonable comfortable with web-service paradigm of programming on > the web, can I say I am comfortable with SOA (at least > conceptually)? Web Services are one, not particularly elegant, means of implementing an SOA. SOA and Web Services are, however, not synonyms. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) Dhurandhar says... > I have been trying to read and understand what it means by SOA (Service > Oriented Architecture). Are there any definitive > guides/tutorials/references that I can refer to? SOA is a marketing term. It has no meaning. That being said, it generally refers to the applications that use web- services, and generally SOAP in particular. The word "architecture" in SOA generally implies that this use of web services is central to the design, such as it being used for communication between major modules that are both essential to the core function of the project. In practice, I don't find that's the case of everything that calls itself SOA. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation > I have been trying to read and understand what it means by SOA > (Service Oriented Architecture). Are there any definitive > guides/tutorials/references that I can refer to? There is a very active Yahoo! Group that discusses SOA (http://groups.yahoo.com/group/service-orientated-architecture/). Disclaimer: It's run by a friend of mine. Here's a quick summary I put together for a client: "Service Oriented Architecture" (SOA) is a term that describes any distributed, enterprise scale software system having a design with four core characteristics: - Functionality is exposed as a set of services. - Services make themselves available by registering with a lookup mechanism. - Clients find services only via the lookup mechanism. - Clients bind to services dynamically. A service is a cohesive set of business functionality aggregated into a single interface. That interface is implementated by one or more software artifacts, which may be local or remote. Implementing an SOA enables an enterprise to define the essential services it requires to meet its core business needs efficiently, and to adapt rapidly to changing business conditions. The loose coupling inherent in SOAs results in resiliency (self-healing), scalability, deployment flexibility, and increased reuse. Loose coupling also makes it possible to incorporate existing components with minimal intrusiveness to working systems. SOAs can mix and match implementation technologies, using the options that are best for each service (e.g. synchronous vs. asynchronous communication, participation in distributed transactions, idempotency, etc.) without impacting the decisions made for other services. The technical benefits of SOAs, in turn, provide real business benefits, including business agility, the ability to leverage existing software investments, and support for Business Process Management (BPM). These benefits come from the elimination of "silos" and the increased availability of business functionality previously locked in legacy systems. Regards, Patrick PS: Some people will try to convince you that SOA is synonymous with Web Services. This is usually because those people are trying to sell you a Web Services product or Web Services consulting. ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) > A service is a cohesive set of business functionality aggregated into > a single interface. That interface is implementated by one or more > software artifacts, which may be local or remote. Implementing an SOA > enables an enterprise to define the essential services it requires to > meet its core business needs efficiently, and to adapt rapidly to > changing business conditions. Yeah... did you get the memo about the TPS reports? SignatureDavid N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ > > I have been trying to read and understand what it means by SOA > > (Service Oriented Architecture). Are there any definitive [quoted text clipped - 30 lines] > participation in distributed transactions, idempotency, etc.) without > impacting the decisions made for other services. An example would be nice. Let's say we have a time of day service, a current weather service and a stock quote service on a server of mine and everyone loves it at Groupiesoft. How does loose coupling (I agree it's inherent in a generic xml interface) result in resiliency (self healing?). If it simply means failover that's been in J2EE since 1999 technically and earlier practically. What about the xml being a loosely coupled interface have anything to do with whether that system is going to alert or automatically do something to stay online or bring back online? Is this implying a requirement that SOAP is also used to tell other servers to reboot if they don't respond in time? Is there a standard for that which is part of SOAP or associated web technology, web service or "set of services with lookup" available somewhere that is identifiable that we're not mentioning out of say, not trying to drop a vendor name or something or does it just sound smart to the listener in a kind of Sokal Affair kind of way? > The technical benefits of SOAs, in turn, provide real business > benefits, including business agility, the ability to leverage existing [quoted text clipped - 15 lines] > | systems design and implementation. > pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) > > The loose coupling inherent in SOAs results in resiliency > > (self-healing), scalability, deployment flexibility, and increased [quoted text clipped - 10 lines] > and everyone loves it at Groupiesoft. How does loose coupling (I agree > it's inherent in a generic xml interface) Before answering the question, I'd like to emphasize that XML is not a requirement for an SOA. > result in resiliency (self healing?). Self-healing arises from the dynamic register-find-bind characteristics of an SOA. If an instance of a service becomes unavailable for whatever reason, the clients of that service can simply acquire a reference to another instance. Either manual or automatic monitoring tools can bring up new instances as necessary. > If it simply means failover that's been in J2EE since 1999 > technically and earlier practically. What about the xml being a loosely > coupled interface have anything to do with whether that system is going > to alert or automatically do something to stay online or bring back > online? Is this implying a requirement that SOAP is also used to tell > other servers to reboot if they don't respond in time? SOAP is also not a requirement for an SOA. The SOAs I've designed typically expose external interfaces used by business partners, suppliers, and customers as Web Services but use Jini (http://www.jini.org) internally. > Is there a standard for that which is part of SOAP or associated web > technology, web service or "set of services with lookup" available > somewhere that is identifiable that we're not mentioning out of say, > not trying to drop a vendor name or something or does it just sound > smart to the listener in a kind of Sokal Affair kind of way? Just the opposite, in fact. SOA is basically a name given to a set of practices that have, individually, been around for quite a while. Pulling them together provides a useful, practical means of better aligning IT with the business (yes, it sounds like marketing speak, but it's true in this case). A number of vendors are attempting to appropriate the term for their own products, which is why it is important to emphasize the generic features. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) > > > The loose coupling inherent in SOAs results in resiliency > > > (self-healing), scalability, deployment flexibility, and increased [quoted text clipped - 47 lines] > attempting to appropriate the term for their own products, which is > why it is important to emphasize the generic features. Yes, that's a rather helpful reply and one which my further reading confirms. I realize it can be any kind of "protocol" for server to server data exchange or "client type agnostic" even. It would be interesting to know if there is a formal definition to these "sets of practices" but they sound similar to a J2EE stack of technologies if you ask me. Being able to automatically go down the list in a registry seems more like a mirrored cluster. 'Self healing' sounds misleadingly better than what it is. It sounds like a protocol might be able to diagnose and restart offline mirrors in so many cases. What it seems like it really is would be the simple ability that is found in TCP/IP and that is routing around or perhaps "self healing" the connection if the connection breaks. Perhaps "session" is involved. I'll have to look up more on jini.org but this seems to contradict what is being said on Java World about SOA soon to replace J2EE. What I think might be more true would be multiple core support and SOA might give some languages and advantage over others as these two new trends take a foot hold in enterprise. It's clear there is support for SOA and all kinds of projects for various CPU architectures, real time etc etc. out there in Java. It comes across as a mere whinge about J2EE's complex set of technologies. > > Just the opposite, in fact. SOA is basically a name given to > > a set of practices that have, individually, been around for quite [quoted text clipped - 9 lines] > interesting to know if there is a formal definition to these "sets > of practices" Sorry for the delay in replying -- I was busy building an SOA. ;-) The set of practices is, indeed, somewhat ill-defined. The Oasis organization recently produced what they call a "reference model" for SOA, available at: http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf I'm not a big fan of the creation of standards in an attempt to define a technology rather than documenting existing practice, but I know that at least one of the contributers to that document isn't an idiot so it is worth reading. The definition debate sparks up periodically on the Yahoo! SOA group list. The dynamic register-find-bind characteristics are at the core, so that's what I stick with. > but they sound similar to a J2EE stack of technologies if you ask > me. Being able to automatically go down the list in a registry seems > more like a mirrored cluster. Some SOA technologies, notably Jini, support multiple lookup services running simultaneously. Lookup services can be added and removed dynamically. In practice it is far more lightweight and flexible than an application server cluster. > 'Self healing' sounds misleadingly better than what it is. It sounds > like a protocol might be able to diagnose and restart offline mirrors > in so many cases. What it seems like it really is would be the simple > ability that is found in TCP/IP and that is routing around or perhaps > "self healing" the connection if the connection breaks. Not exactly. While resiliency can be improved through active monitoring, it arises from the ability to automatically request a proxy for a different service instance if the instance currently being used becomes unavailable. This, in turn, is supported by the ability to run an arbitrary number of service instances on multiple machines across the network. > Perhaps "session" is involved. I'll have to look up more on jini.org > but this seems to contradict what is being said on Java World about > SOA soon to replace J2EE. That sounds like hype to me. No doubt the Web Service vendors see J2EE application servers as competition, but I hardly think that the concept of SOA is going to lead to their demise. > What I think might be more true would be multiple core support and > SOA might give some languages and advantage over others as these two > new trends take a foot hold in enterprise. It's clear there is > support for SOA and all kinds of projects for various CPU > architectures, real time etc etc. out there in Java. It comes across > as a mere whinge about J2EE's complex set of technologies. Well, J2EE is complex and getting ever more so ("J2EE" in this context including EJBs, containers, application servers, and pretty much everything other than just JSPs and servlets). It's not a good choice for implementing an SOA because it is so heavyweight and complex, but there is a fair bit of business functionality inside existing application servers that can be exposed as services. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.