Service Oriented Architecture (SOA) promises to provide us with the ability to assemble complex, distributed systems by selecting and creating compatible parts called services. So far, SOA has delivered a lot of hyperbole to the Web. Gartner recognized it as one of the five hottest IT trends in 2005, claiming that "By 2008, SOA will provide the basis for 80 percent of development projects." At JavaOne 2005, 82 of the 168 technical session PDFs contained "SOA." In July of 2005, there were 1.4 million Google hits for "service oriented architecture." By February, 2006, there were 72 million. SOA is riding a rising tide as the next big thing for enterprise developers.
Unfortunately, most developers find it hard to cut through this tide of hype to learn just what service oriented architecture is about. Forests of three-letter acronym (TLA) standards sprout, bloom, and are overgrown before any of us can learn enough about them to decide if they are appropriate for our own projects. The standards compete for our attention and allegiance. Further, most articles and presentations focus on a specific TLA, and how to make some legacy system fit within someone else's favorite web service plumbing. "Legacy" seems to mean "the software that has to keep working to keep the system alive and useful to the business."
I started working with distributed messaging systems in 1995 and can understand most of the articles, but I find the volume of hype daunting and largely irrelevant. This article focuses on what you can get out of SOA to make developing and maintaining software easy, and help your businesses run better. Here's what you can get out of service oriented architecture:
Better understanding of the system being developed.
That list is a huge promise. No wonder there's so much hype. Unfortunately, the list doesn't hold anything we can code. Aside from being able to restart a service, it's not specific at all. Service oriented architectures bring together specific good ideas from the 1980s and 1990s to create a complex system from simple parts. Service oriented architectures have these characteristics:
Services have strong software contracts.
Services are encapsulated.
Messages are documents.
Services share a message bus.
Services are loosely coupled.
Services have a life cycle.
Systems of services are assembled at runtime.
Services can be discovered.
Systems of services can grow into systems of systems.
Services Have Strong Software Contracts
A strong software contract defines the role that the service plays. Services are a realization of software design-by-contract. A service's contract describes what messages a service will receive, what messages a service will send, and what error signals a service will send when things go wrong. In service oriented architecture contracts, hidden state invariants tend to be less important. High-level descriptions of any side effects-- especially changes in exposed internal state--take center stage. The software contract serves as a design guide, test plan, and programmer's interface. Share the service's software contract with people when they ask you what the service does. Use the software contract to help your managers decide which services to build first, to address some immediate needs of your business.
Java's JavaDoc provides a nice start for software contracts. By using JavaDoc, especially package.html files, you can guide other developers to the important parts of your code and share the important details. Most Java developers have learned to read the JavaDoc if they read anything at all, so it is your best bet for describing your contract to them. WSDL files include a very precise description of a service's programming interface in a computer-readable format. However, WSDL files are separate from code (so they won't be found) and hard on the eyes (so important details will be missed). I like to create Java interfaces to hold specific details of services in my system. JDK 5 annotations can help, too, especially those from JSR-181, which will be standard in JDK 6. Annotations are computer-readable, available in JavaDoc, and are embedded in code. I think they are the best choice for the structural part of a software contract, but are no substitute for a solid written description.
Services Are Encapsulated
Services are encapsulated. A service only exposes the behaviors in its contract. Nothing outside the service can observe internal state and state transitions. How a service fulfills the contract remains hidden. No interesting service can achieve ideal encapsulation; even a service on dedicated hardware will still share limited bandwidth on a network. The best way to handle these details is to add them to the contract; if something that matters to the rest of the system is not in the contract, then the service's contract is incomplete. Fixing bugs in your contract is much easier than fixing encapsulation. Observing and enforcing encapsulation helps prevent creeping complexity growth, a maintenance nightmare.
The goals of encapsulation line up well with the original promise of object oriented programming: keep responsibility localized and defined. I'm not sure there can be a positive standard for encapsulation, a feature defined by an absence. I have used some existing language features to set boundaries. Java's access keywords (public, protected, default, and private) and JavaDoc provide a nice start. By controlling accessibility, you can keep some parts of the programmer's interface hidden. Language designers at Sun have muttered about some kind of friends keyword in JDK 7, but I haven't seen anything concrete yet.
Message Contents Are Atomic Documents
Part of service oriented architecture is document oriented architecture. The contents of the messages that flow in the system are well-defined data structures--like documents. Sending a message effectively makes a copy of a data structure. Once sent, the message can not generally be pulled back and changed. Message data structures need to be complete and compact, and have consistent rules for how to maintain referential integrity. You can easily and directly reference one part of this document data structure from another, but referencing something outside of the structure means extra work with foreign keys. The Java Data Object specification section 6.3 describes this dichotomy well. Good JDO first-class objects are like documents, constructed of subordinate second-class objects. XML uses a slightly more implicit approach. XML files are documents that use IDs and IDREFs or XPath expressions for internal references. Most systems of services have a small local service responsible for finding the right document using foreign keys.
Obviously, one service needs to be able to understand messages received by another. Agreeing on syntax is the easy part; try Java's serialization if you've got Java on both ends, XML otherwise. If you pick XML, decide how your system will handle referential integrity inside the document. XStream provides a very simple solution that plays havoc with XMLSchema. JAXB 2.0 does a very good job. If you are trying to get services produced by separate groups to communicate for the first time, expect to spend an extraordinary amount of time getting the services to understand each other. Sorting out semantic meaning and corner cases is far more difficult than deciding on syntax.
Services Share a Message Bus
Services communicate with each other by sending messages over a shared message bus. SOA proscribes messages to avoid the coupling that comes from services sharing a call stack; if the called service fails silently, the calling service has to wait for it to return. Services use messages in three main styles: request/reply, commands, and events. In request/reply, one service sends a request to another, and dedicates resources, usually a thread, to waiting for the reply. This style leads to coupling almost as tight as when sharing a call stack. One service can send another service a command: a fire-and-forget instruction to do something. The command style leads to modest coupling; the commanding service expects some other service to fulfill the command eventually, but does not dedicate any resources to make sure. A service can simply publish events--notifications that something of interest has happened--without depending on any service to receive the message. Event-based systems of services are very loosely coupled, and can scale up to the limit of the message bus. Monitoring the message bus provides great insight into how well the system works, and creates a reassuring picture for your manager.
My favorite API for messaging is the Java Messaging Service standard. There are many implementations, most of which focus on reliability in enterprise-scale environments, and some of which include APIs for non-Java systems. Some JMS implementations use peer-to-peer technologies to survive transitory internet and wireless networks. I created SomnifugiJMS for messaging between threads in a single Java process for small-scale systems. If you need to scale to something even smaller, try using BlockingQueues from java.util.concurrent. For large-scale systems on unreliable networks, try using JXTA to construct a reliable network.
Services Are Loosely Coupled
Ideally, services only interact by fulfilling their contracts over the message bus. The closer you can come to that ideal, the better. Try to discover and record hidden dependencies like shared call stacks, static tunnels in singletons, and shared processors, memory, disks, databases, and networks. Any dependency can lurk in the background, waiting to break your system. Be aware of coupling between services on the message bus. A service that issues commands and requests is assuming that some other service will fulfill these commands and requests. Even services that expect only events assume that some other service will publish the event. Try to catalog potential problems, but focus your energy on decoupling specific trouble spots before they matter. Loose coupling between services makes replacing one service with another possible. When your manager asks what will be involved in integrating a replacement service, you will have a sound answer.
A service's reaction to a message should be an atomic action, so services work best as optimistic transaction engines that record and attempt to fix problems. Two-phase-commit transactions across services tightly couple those services. Luckily, most systems larger than a database rarely need to roll back the transaction. Instead, a troubleshooting service in the system needs to be alerted to the problems so that the problems can be sorted out. The troubleshooting service fits surprisingly well into most business workflows because the business wants to reroute the problem transaction instead of wiping it out of existence.
Services Have Independent Life Cycles
Each service has its own life and life cycle independent of other services. Individual services may be stopped, restarted, and replaced without stopping the whole system. Batching services like end-of-day processes can start, process all pending messages, and stop. A service can join a wireless network briefly, when a connection is available, and then disconnect later without causing harm. You can even replace an obsolete service with a new version without downtime. I haven't found a good standard for turning services on and off, but it isn't that hard to build. Simple volatile flags in a Runnable's main loop have worked fine so far. W3C has a description of possible states and transitions, but it seems like overkill to me. If you start building your own elaborate system, steer towards that W3C standard. The feature you want is the ability to stop one service and start another to replace it, without stopping the whole system.
Orchestrators Assemble Services into Systems at Runtime
Orchestrators are special services that gather and assemble services into larger systems at runtime. Some orchestrators match contracts to orchestration instructions to registered services. Orchestrators often start the services they need. Assembling a service this way is a lot like using Simulink blocks; you choose the parts, connect them to a message bus, and sometimes stimulate the system with an initial message. BPEL and workflow engines like Dalma hold a lot of promise for orchestrating large systems, but I haven't used either for more than simple experiments. The java.net website uses Dalma to coordinate registering new projects. For the systems I have actually built, I used simpler, more general-purpose tools like Jython and Beanshell scripts, and simple Java code to orchestrate the services. I haven't found a language I like that lets me specify a workflow yet, although I am hopeful.
Orchestrators Can Discover other Services Dynamically
Services generally register themselves with a service locator. An orchestrator can then use the service locator to find the services it needs dynamically, at runtime. The idea is similar to using the Java Naming and Directory Interface (JNDI) to find the right database connection. I have found service locators much more useful within a single process than on a large scale. I think that's because small systems tend to have a lot of diverse parts, and the larger scale systems I design use events, meaning there's less for them to look up. Systems where distributed services appear and vanish, like the battlefield, the internet, and wireless networks, need reliable large-scale service locators. JNDI works quite well as a service locator on a small scale. Jini works great on a larger scale. Jini can find services that implement a specific Java interface, which is very close to finding services by contract. Others report success with Universal Description, Discovery, and Integration (UDDI) when some services are not in Java.
Systems of Services Grow into Systems of Systems
A system composed of services can be a service in its own right. The more that messages are treated like events (instead of requests), the better your system can scale up. Scaling up this way can be the technology jewel in a business plan, and is the most interesting feature for academics and hobbyists. We software engineers need to avoid being too charmed by it. We have to stay focused on the problems at hand. However, compatibility and stability on a large scale will make our next project more gentle.
To make sure that your system of services can be a service in its own right, make sure the larger system has all of the features that a service should have. The larger system should have a strong service contract, be encapsulated, use atomic messages to communicate, be decoupled from other services, have an independent life cycle, and be discoverable. If all of that is true, a larger-scale orchestrator can use your system as service to assemble something bigger.
Life in the Standards Zoo
A large zoo of standards already exists for Java coders. If you can use some of these standards, you will save yourself some effort now. With a little luck, your choice will help you be compatible with some undiscovered service later. WSDL and Java interfaces help define software contracts and encapsulation. Shared messaging busses can come from an ESB, JMS, or java.concurrent.BlockingQueues. Messages as documents can come from XML or serializable objects. Assembly at runtime can come from business languages or scripting, plus a service locator like JNDI, Jini, or UDDI. New standards roll out every week. I use JavaOne Online as a starting point, since these days, Google turns up too many pages trying to sell you something.
Practice some suspicion when you shop for standards. New standards generally haven't been tried in the field. They may solve problems you don't have, and may not solve the problems you care about. Learning how to get the most out of a standard requires some investment of your time; you won't have time to learn many of the standards before the next batch comes out. Welding your project to some new standard involves risk. If you pick the wrong one, you may wind up maintaining a useless, complex layer for a long time. Enterprise computing pundits battle for control of the standards bodies; they want your attention, your participation, and ultimately, want your money.
Getting encapsulated, well-designed services to fit behind some new standard is relatively easy. The standard tools get better in leaps and bounds. My own career shows the evolution. From 1998 to 2000 my team created an SOA framework ourselves. Needing three days to explain what we were selling contributed to the company's demise. In 2001, I was part of a contracting team that built a system of services using JMS, Perl and databases. In 2003 at a new job, we wrote our own WSDL to use with WSIF, JMS, and Jython, and put together a demonstration system of services in about a month. Converting an existing system has taken about a year. We ultimately dropped the WSDL in favor of Java interfaces, and stopped using WSIF. Restructuring the code was wonderfully straightforward, and will get easier over time. In June 2005 (post-JSR-181), creating a Java web service involved adding Sun's reference implementation JARs and adding @webmethod annotations to existing code. When JDK 6 provides JSR-181, we get the supporting parts just by adding the annotations.
Wrapping Up
Service oriented architecture is a collection of ideas and patterns from the 1980s that survived the 1990s. The concepts behind SOA are sound, solid, tested, and proven. SOA ideas directly address details in business plans about how you will deploy, grow, and evolve your system. Creating encapsulated, loosely coupled software that obeys a clear contract requires discipline, but shows immediate benefits. Getting loosely coupled, encapsulated software behind some new web services standard will be easy.
David Walend started learning Java with the alpha 3 release in 1994 after a kind computer science professor at Tufts University overheard his tantrum on distributed simulations, memory management, multithreaded code and meteorologists of questionable parentage.
A valiant try but irrelevant....
2006-04-10 10:57:00 threadweaver
[Reply | View]
Part of service oriented architecture is document oriented architecture. Not really, but people in this industry tend to think that way since that is how web services work and they are very confused.
Other than that, the rest of your argument is logical and very well done but:
I don't think that there is any value in trying to define a vacuous term like SOA. If its originators had intended to provide a useful solution instead of a buzz word on which they could sell products they would not have intentionally left its definition so vague and ambiguous.
Trying to define SOA as something useful in the real world, rather than coming up with something useful in the real world and giving it a name is confused pedagogy and exactly the opposite of what we should be doing. Coming up with a model that fits the real world is science. Trying to make the real world fit the imaginary model is religion.
Like every cult before it the SOA cult is going to fall flat on its face because it is comprised of a bunch of wackos who have abandonded reality.
A valiant try but irrelevant....
2006-04-10 12:25:56 vfrisina
[Reply | View]
"Coming up with a model that fits the real world is science. Trying to make the real world fit the imaginary model is religion."
I beg to differ. Trying to make the real world fit the imaginary model is the basis of all technology and progress. We look at what currently exists, imagine something better, and then create it.
I am not just being pedantic. Part of the impatience that many developers show feel about SOA seems to be that one cannot point to a piece of code and say "That is SOA". Unfortunately, it is still a concept rather than a code library, so there is legitimate debate about what SOA is and should be. This is analogous to the long ago debates about what an object is. The existence of the debates did not mean that OO is just marketing fluff (although there were plenty of marketers exploiting the ambiguity). Rather the concept was still being hammered out. We are in roughly the same situation with SOA.
A valiant try but irrelevant....
2006-04-11 21:16:55 threadweaver
[Reply | View]
Ok. I guess that wasn't very straight forward. You are refering to physical acts of creation. I am refering to what is actually going on irrespective of people's imaginations.
SOA is not a technology, it is a buzz word that a few marketers created. It is no more a piece of technology than the word "dajslfkjsladjflsjafljas".
In order for something to be useful, it must hold up to real world empirical analysis. An example of a so-called technology that has failed like CMP-EJB. SOA is not even as close to technology as CMP-EJB because although CMP-EJB failed, at least it had a definition in the real world. In other words, even though EJB-CMP was a step backward or at best a lateral step, it had more value than SOA.
If I said, I had a new paradigm that was going to revolutionize software development called "Pluggable Popsicles" and didn't bother to define it, no one would pay attention. But when Oracle and BEA come up with a new meaningless term in order to sell their crappy products everyone jumps on board because Oracle and BEA are assumed to be experts. Sorry, but I refuse to believe that anyone at IBM, Oracle, Sun, or BEA is the messiah because in most cases they are even dumber than I am. Web Services is a technology (a poor one). SOA is hype.
SOA as most people define it (and as this article defines it) is pretty much the same as CORBA which, after 20 years of experiment, has proven to be a mess.
A valiant try but irrelevant....
2006-04-13 10:00:47 vfrisina
[Reply | View]
> SOA is not a technology, it is a buzz word that a few marketers created.
Not quite. SOA is not an API or code library. There is no referenece implemenation or specification. If there were, I would agree that is is worthless BS simply because we are nowhere near the point of defining a spec. Instead SOA is a concept, and idea about how to structure distributed systems. As you noted, there have been many, many years of spectacular failures. However, I would say that the reason CORBA and DCOM systems failed was not because they are inherently awful technologies (athough they certainly have their warts), but rather because of the way they were used. Service-oriented architecture is an idea currently being hammered to fix that part of the problem, regardless of what technology you use to implement it. Because it is essentially an on-going argument, there is not currently a consensus position that you can point to and call The One True Definition of SOA.
Again, I remember the same arguments when OO was first introduced to the masses (as opposed to the LISP and Smalltalk gurus who always knew everything before the rest of us unwashed barbarians). Many people claimed that OO was just marketing fluff because there was nothing there that could not be done in C or even assembly, given the right discipline. They were missing the point. OO was not the language or dev tools, it was the discipline and the approach to building software. The real debate was not about languages. Instead it was about what consistituted object orientation, what its strengths and weaknesses were, and how to apply it. That took years of arguing and experiementing to work out, and frankly we are still learning.
It seems that part of the issue is that there is no official standard for SOA. I think one of the worst things for our industry is the idea that as soon as someone has an idea, there must be a standard for it. even if the problem is not yet understood. Sun and other large vendors are among the worst offenders in that they create standards to fit their latest tools as soon as they come out. I point to EJB and JSF in the Java space. Standardize from a consensus of best practices and a good understanding of the solution, rather than just declaring one by fiat so you can claim your product is "standards compliant". I already ranted about spec-envy in my blog
A valiant try but irrelevant....
2006-04-23 09:51:38 dwalend
[Reply | View]
vfrisina, I think you're on to something comparing SOA to OO. In OO there are simple but deep concepts to grok, followed by things to experiment with and practice before it works. I think SOA is the same sort of thing. Instead of the cells of the system being objects, they are services.
A lot of OO and SOA is marketing fluff. Marketing is good; business guys learn what we can do for them and pay us for our work. Fluff is annoying because you have to chop through it to get to something solid. SOA is currently snowed under fluff, just like OO in 1994.
I think its valiant to define some standards to help with SOA, so long as people realize that today's standards probably won't be the ones we use next year. They are handy for coordinating productions of big systems built by big teams, even if only to shorten debates. I share Dr. Waldo's fear that the standards will quash innovation, but so far innovation seems quite healthy. Older good things like JINI seem to rise to the top. I don't know of anything bad that's been lost yet.
A philosophical argument?
2006-04-12 07:27:24 dwalend
[Reply | View]
Wow... I didn't expect a philosophical discussion. I was hoping more for comments like, "I'm using technology X to get feature A," so I could skip over the drab also-ran technologies to the good stuff.
<p/>
Threadweaver, you've told us you don't like CMP-EJB and don't like CORBA. What do you like to use?
<p/>
Threadweaver, treating your data-bearing objects as immutable documents works wonders in concurrent systems. Less-gifted developers understand just what they're dealing with. Throwing them into thread-aware thread-safe transactional code is inviting disaster. In a distributed system, you get half of DOA just because each process gets its own deep copy of the data.
<p/>
Vfrisina, I'm with you. The working title was Smells like SOA. At one start-up, we figured out how to make this stuff work, but it was very hard to describe. There is value to having solid definitions. Industry was distracted by academia's traveling computing agents in the late 1990s. If they'd focused on messaging instead, we wouldn't have needed a week-long seminar to make the pitch. Now I can go to a customer and pitch "a distributed system of services." The customer nods his head, refers to his own strategic initiative and we dive into details.
<p/>
Threadweaver, you've uncovered an interesting dichotomy between concepts and bits, and dived into the problem of making them match up. CMP-EJB is bits. It comes in a .jar file, and has a fat PDF spec. (New EJB specs are like a bad sequel to a bad movie, "EJB 4: CMP -- The Apology.") Vfrisina is right. Using WS-2 standards is as likely to get SOA benefits as using Java is to get good OO benefits. If someone shortcuts your architecture, things will break.
<p/>
I see new conceptual approaches to coding coming from two sources: academia and industry. LISP university labs created object-oriented programming (and constantly point out how we got it wrong and they got it right) and now are pushing aspects. Universities came up with web agents. Industry is for profit; either they want to sell us something expensive or they want us to build something interesting. The former results in application servers and the later results in brilliant things like JINI.
<p/>
CORBA has some serious problems. I started working with this thing in 1995. Some of the people we work with still use it. The biggest problem in CORBA is its reliance on IDL. Basically the IDL rigidly defines the pipe that the data flows through. If the IDL changes, the code through the entire pipe has to change. (Anything relying on XMLSchema in the pipes risks the same sort of woe.) Other serious problems I've observed are an over-reliance on RPC-style programming and on hard addresses for distributed parts. When the system makes a jump in scale, it tends to fly apart. Later add-ons to the spec try to fix these problems, but the culture already jelled into weaker forms.
<p/>
I always have trouble naming my projects. "Pluggable Popsicles" would be a great name for a persistence engine. Can I steal it?
A philosophical argument?
2006-04-12 10:15:40 threadweaver
[Reply | View]
>> I always have trouble naming my projects. "Pluggable Popsicles" would be a great name for a persistence engine. Can I steal it?
Sure go ahead. ;P
I agree with everything you said. I just think we ought to be focusing on what creates value (technology) and not on buzzwords.
>> Threadweaver, you've told us you don't like CMP-EJB and don't like CORBA. What do you like to use?
For persistence, Hibernate, which I think has held up very well in the real world. For services, I still like EJB although I have not had time to really play with Jini or anything other than RMI (JRMP) yet. What about you?
>>(New EJB specs are like a bad sequel to a bad movie, "EJB 4: CMP -- The Apology.") LMFAO.
>> Threadweaver, treating your data-bearing objects as immutable documents works wonders in concurrent systems. Agreed. I was just saying that is not required in strict-english interpretation of the term SOA since, any service could represent SOA under the terms defined in the dictionary.
>> Wow... I didn't expect a philosophical discussion. I was hoping more for comments like, "I'm using technology X to get feature A," so I could skip over the drab also-ran technologies to the good stuff.
I have been attacked for that in other circles (if you want more info let me know). Ultimately, I think that people that are good natured generally want answers rather than to cling to some dogma. I want working answers as well, but it seems logical to me that it is impossible to arrive at a result other than confusion without a mutual definition of terms at the outset. In other words, I think it will be easier to arrive at things that work in the real world if we are speaking the same language.
A philosophical argument?
2006-04-12 18:54:17 dwalend
[Reply | View]
>>For persistence, Hibernate, which I think has held up very well in the real world. For services, I still like EJB although I have not had time to really play with JINI or anything other than RMI (JRMP) yet. What about you?
Current project is very lightweight: JMS for comms (both between threads and between remote processes). Mostly immutable objects flowing between things via serialization. For the moment, we're using serialization for persistence. (I'm trying to keep a database out of our part of the system.) We've just hard-coded the orchestration in Java for now. JNDI for a service locator. We might eventually use JINI to build up a larger system.
EJB was originally for coordinating transactions over multiple XA resources. Are you actually using it for that? It does a great job, but the problem doesn't come up that often. I gave up tracking the spec after it passed 800 pages.
>>I agree with everything you said. I just think we ought to be focusing on what creates value (technology) and not on buzzwords.
I'm interested in what makes one technology useful, and another just resume crud. I think those things can be characterized, and the characterization can be collected into something that makes sense as a whole.
Buzzwords are an interesting facet of the problem, along with things in "util," things named "*Manager" and "*tion" words. People imagine them to mean whatever fits their view of the universe, then are disappointed when things don't work out. (Think of experiences with the word "documentation." Does it mean writing documents, reading documents, or doing something vague, not coding? How do you know when you're done?)
I think we're just now getting to the point where we can define what we want and start asking for it. I'm hoping we'll recognize it when we see it. JINI's an example of something great that most of us missed.
A philosophical argument?
2006-04-13 09:56:09 threadweaver
[Reply | View]
>>People imagine them to mean whatever fits their view of the universe, then are disappointed when things don't work out.
I could not have said it better. That's why I thought your article was noble to a large extent.
I agree that we ought to take what works and abandon things that do not. At the same time, I think we need to always be pushing to simplify things so that we can solve bigger problems. No one should have to read a 800 page spec.
I have been stuggling with coming up with a system to accomplish this. I wanted to devise and formalize a method for "How to approach Computer Science as a Scientist." If you would like to participate, I would love that, but if not, you have already helped me greatly and given me hope.
You will probably never know how much your article and this conversation has meant to me, but this has been the first real, rational conversation I have had with someone in IT since graduating from college. Thank you. It has been like breathing fresh air for the first time.
>> EJB was originally for coordinating transactions over multiple XA resources. Are you actually using it for that?
Yes and no.
We have multiple databases on which the application depends but no JCA or anything like that. EJB is used for remoting specifically. I wrote our transaction API to be an abstract factory. The current implementation is based on JTA. The problem that I saw with using both BMT and CMT is that it couples your transaction logic to EJB.
>> I think we're just now getting to the point where we can define what we want and start asking for it.
I hope you are right and I hope you reply again. Thank you.
A philosophical argument?
2006-04-23 09:23:14 dwalend
[Reply | View]
Sorry for not getting back to this sooner. Vacation.
Watch out for the seduction of simplicity. Some things, especially physical things, really do rate an 800 page spec. An example: i can solve bigger problems by using multiple threads and multiple processes. However, doing that means giving up the simplicity of the stack. A few generations of EJB specs got wrapped around this idea of defining roles instead of transactions.
"How to approach Computer Science as a Scientist." sounds interesting. Are you more interested in observing systems, like a naturalist, or setting up experiments like a chemist? I've always seen myself as an engineer; I build stuff.
A philosophical argument?
2006-04-23 10:39:02 threadweaver
[Reply | View]
Watch out for the seduction of simplicity. - Certainly we don't want to be overly simple.
Essentially the job of software developers is to create models. I haven't found good criteria yet for evaluation of models. In physics, a model is considered valid it reflects what is going on in the realm of our sensory experience. I would also add the criteria: inclusion, coherence, simplicity, and flexibility.
So, in my mind the method for determining the best model for a particular problem would be:
1. Realization that there are no paradoxes in nature. Paradoxes exist only in our constructs.
2. Throw away all invalid models.
3. Whatever is the most inclusive, coherent, simple, flexible out of what remains the best choice.
All of this caught up in the bi-directional communication (requirements gathering) between the development team and the people who are sponsoring the development. I am working on formalizing all of this as well. I have a real problem with both use cases and user stories which are fundementally the same thing: the description of a single isolated event.
"How to approach Computer Science as a Scientist." - I can email you a copy of what I have going in a few weeks, but it will be a rough draft. Unfortunately, at this point in time I don't know enough about probablity theory and statistics to make it really powerful yet (it's a matter of detail) but I still think that it is useful.
I've always seen myself as an engineer; I build stuff.
If by engineer, you mean that you use scientific knowledge to modify your environment, we all are.
Every sentance spoken is an act of engineering and creation. A technology is just an application of science in our 4(+)D sensory world.
A philosophical argument?
2006-04-29 12:01:40 dwalend
[Reply | View]
threadweaver, have you had a look at the latest EJB spec? The page count seems to have stabilized, they've chopped it into three, and they've added features to keep us from having to make so much boiler plate. I might wade back in if I get a project that can have the overhead of an application server.
You're in for a great journey trying to define what we do with that kind of rigor. You're more ambitious than Dijkstra. I'd love to look over your shoulder from time to time to see how it's going.
I'll a gree that every sentence spoken is an act of creation. The world would be a better place if every sentence were all an act of engineering.
A philosophical argument?
2006-05-03 09:31:19 threadweaver
[Reply | View]
I haven't read the EJB 3 spec yet. Unfortunately, I just don't have time to read everything that I would like so I have to make sacrifices. I think I will let some other people try it out first and see what they think. Let me know what you think. I hope the ORM works out better this time. It's hard to get into everything early and be a generalist at the same time.
>> You're in for a great journey trying to define what we do with that kind of rigor. You're more ambitious than Dijkstra.
No kidding. I'm just trying to make things better any way that I can.
>>I'd love to look over your shoulder from time to time to see how it's going.
Sure. I'll email you what I am working on in a few weeks if you want.
>>I'll agree that every sentence spoken is an act of creation. The world would be a better place if every sentence were all an act of engineering.
Ha. Ha! I love it. Can I quote that?
A philosophical argument?
2006-05-11 05:02:57 dwalend
[Reply | View]
Understanding Service Oriented Architecture
java.net RSS Feeds
