Today was a slow day in India.
Only 163 new jobs requiring Java development experience were created on MonsterIndia.com - today (of the well over 5000 current openings).
Most of the positions were paying around $12,000 USD annually.
Today was a slow day in India. Perhaps things will pick up tomorrow.
Wednesday, June 23, 2004
Thursday, June 17, 2004
How many languages do you use?
I love asking Java developers the following question, "How many languages do you use when developing a J2EE application?" They almost always look at me with this pitiful look. It's the, "Jeff is so old that he doesn't even know that J2EE uses Java" look. I'll usually string them along while they try to describe what J2EE is. The answers are great.
After they finish 'educating' me on Java, I follow up with the following set of questions:
1. Is HTML a language and do you ever use it on your J2EE applications?
2. Do you use a 'batch' or 'make' language on your apps?
3. Do you ever use the 'structured query language' (SQL)?
4. Do you ever use JavaScript?
5. Do you ever use JSP?
Usually I stop there - by this time they understand my point.
J2EE is a combination of languages and libraries. We use Domain Specific Languages (DSL) all the time. In the Java world we tend to wrap them with 3-letter acronyms that start with the letter 'J'. We often glue the our languages and libraries together in the form of an application by using an object oriented 3GL (Java).
In many cases, our libraries (JMS, JDBC, JNDI, etc.) merely act as a standardized API to a server (or set of services). These services often need to be customized. We have several ways to customize services: upload metadata, pass in parameters, etc.
J2EE is our container of DSL's and libraries. It acts as the vehicle to pass information from one DSL to another DSL, from one library to another library, from a DSL to a library or from a library to a DSL. The Java language is used to type the data, transform it, perform Boolean logic and pass the data on.
The questions that I've been asking myself are:
What should a library/DSL integration language look like?
Is Java (or any OO-3GL) the best fit for a library/DSL integration language?
What common functionality of the DSL should refactored into a generic 'DSL engine'?
How does a platform architecture provide more consistent extensibility mechanisms across the suite?
To what extent should the components of the platform be mandated to have a symbiotic relationship with the other members?
Back to the original question, "How many languages do you use?" The answer is usually 5-10, and the number is growing. Writing J2EE applications is becoming less about programming in Java and more about mastering domain specific languages, libraries and integrating them across contextually bound Use-Cases.
J2EE has grown organically over the last 7 years. It has not had the opportunity to be massively overhauled. In my humble opinion, the enterprise software community is ready for a massive refactoring of J2EE; one that isn't dragged down by backward compatibility issues. I believe that we are ready to incorporate our lessons learned to design the next-gen software development platform.
After they finish 'educating' me on Java, I follow up with the following set of questions:
1. Is HTML a language and do you ever use it on your J2EE applications?
2. Do you use a 'batch' or 'make' language on your apps?
3. Do you ever use the 'structured query language' (SQL)?
4. Do you ever use JavaScript?
5. Do you ever use JSP?
Usually I stop there - by this time they understand my point.
J2EE is a combination of languages and libraries. We use Domain Specific Languages (DSL) all the time. In the Java world we tend to wrap them with 3-letter acronyms that start with the letter 'J'. We often glue the our languages and libraries together in the form of an application by using an object oriented 3GL (Java).
In many cases, our libraries (JMS, JDBC, JNDI, etc.) merely act as a standardized API to a server (or set of services). These services often need to be customized. We have several ways to customize services: upload metadata, pass in parameters, etc.
J2EE is our container of DSL's and libraries. It acts as the vehicle to pass information from one DSL to another DSL, from one library to another library, from a DSL to a library or from a library to a DSL. The Java language is used to type the data, transform it, perform Boolean logic and pass the data on.
The questions that I've been asking myself are:
What should a library/DSL integration language look like?
Is Java (or any OO-3GL) the best fit for a library/DSL integration language?
What common functionality of the DSL should refactored into a generic 'DSL engine'?
How does a platform architecture provide more consistent extensibility mechanisms across the suite?
To what extent should the components of the platform be mandated to have a symbiotic relationship with the other members?
Back to the original question, "How many languages do you use?" The answer is usually 5-10, and the number is growing. Writing J2EE applications is becoming less about programming in Java and more about mastering domain specific languages, libraries and integrating them across contextually bound Use-Cases.
J2EE has grown organically over the last 7 years. It has not had the opportunity to be massively overhauled. In my humble opinion, the enterprise software community is ready for a massive refactoring of J2EE; one that isn't dragged down by backward compatibility issues. I believe that we are ready to incorporate our lessons learned to design the next-gen software development platform.
Beyond Services
I've been actively writing about services (and mostly web services) for three years now. We've moved from the base specs, to the WS-* functionality, to BPEL, Service Network design, Service Oriented Integration and Service Oriented Development of Applications.
However, the one thing that has been clear to me for the last year is that services will play an important role in enterprise architecture, but will only be successful when combined with other architectural concepts.
In the past, I've thrown out terms like, "Model Driven Services" or "Model Driven Metadata" and "Metadata Driven Services". The fact is, most "web service" companies have been so busy trying to knock out the ws-* spec implementations that they have not had time to think about the converging programming model. But they must!
After the WS-dust settles, we will have solved our LCD problem and hopefully even our GCF problem. What is less clear is how service based development will interact with many of the popular programming concepts (eventing, aspects, code generators, process engines, policy systems, rules engines, etc.) It is relatively easy to create a new specialized brand of computing (like services). It is much harder to weave it with the concepts that are already in place. Failure to do so results in a massively disjointed architecture. The symbiotic relationship between our architectural components must grow.
However, the one thing that has been clear to me for the last year is that services will play an important role in enterprise architecture, but will only be successful when combined with other architectural concepts.
In the past, I've thrown out terms like, "Model Driven Services" or "Model Driven Metadata" and "Metadata Driven Services". The fact is, most "web service" companies have been so busy trying to knock out the ws-* spec implementations that they have not had time to think about the converging programming model. But they must!
After the WS-dust settles, we will have solved our LCD problem and hopefully even our GCF problem. What is less clear is how service based development will interact with many of the popular programming concepts (eventing, aspects, code generators, process engines, policy systems, rules engines, etc.) It is relatively easy to create a new specialized brand of computing (like services). It is much harder to weave it with the concepts that are already in place. Failure to do so results in a massively disjointed architecture. The symbiotic relationship between our architectural components must grow.
Saturday, June 12, 2004
Dynamic Coupling
Loose coupling has more up front costs than tight coupling. The assumption is, over the life of a component (or service) that the loose-coupling device will pay for itself.
A common belief is that software engineers should design services to be 'loosely coupled'. That is, they should verify that the service can speak the 'least common denominator' and do it in a manner that mitigates the impact of location: attempt to minimize the impacts associated with distributed computing (location transparency).
In the physical world, we use devices to decouple entities. Instead of soldering two components together, we connect each component to a plug and then use the plugs to connect the items together. This is necessary in the physical world.
In the logical world, we have the opportunity to attach a 'plug' to the end of a component or a service. And just like in the physical world, it costs more money to buy and attach the plug. But, the plug should make the component more reusable. That is the investment.
Imagine an electrical component that is attached to a printed circuit board. The component has nice plastic plug coming off of it enabling other components to easily connect to it. In addition, the wire lead on the component is exposed and it is mounted in such a way that additional wires can be soldered directly to it. In essence, the component was designed with loose coupling in mind (the plug) but the instantiation (or the use) of the component allowed the engineer to bypass the plug by directly connecting to the wire lead.
Here, the component has both 'component design-time' and 'assembly design-time' properties. The 'component design-time' properties describe the features that the component has; in our case, we are interested in the plug at the end. The 'assembly design-time' deals with the decisions that the engineer makes at design time when they assemble multiple components together (e.g., does the engineer use the plug or solder directly to the wire?)
When we discuss loose coupling or tight coupling, we must remember that there are different issues to consider:
1. The level of investment that was placed on enabling a component to be loosely coupled (e.g., it comes with a plug attached). [POTENTIAL COUPLING]
2. The decisions that the component assembler made when combining the piece components (e.g., they used the plugs everywhere vs. soldered them together everywhere vs. some combination) [ASSEMBLY COUPLING]
3. The option of delaying the assembly interface mechanism decisions to runtime. [DYNAMIC COUPLING]
A significant amount of literature is available on making components/services reusable (creating high potential decoupled devices); thus I won't revisit. Less is written on Assembly Coupling, but I'm still happy with my, "Service Coupling Index" as a foundation. However, very little information is available on the concept of Dynamic Coupling.
In many ways, Dynamic Coupling contradicts the 'loosely coupled' manifest. Rather than stating that something must be implemented in a certain way (asynchronous, document centric, XML based, etc.), it states that the component need only have Decoupling Potential AND that the component be aware of any Dynamic Decoupling Device.
I like to think of the Dynamic Decoupling Device as a "magic printed circuit board". Here, the assembler inserts components into the board. But rather than soldering the components together or using plugs to connect them, the assembler will never execute the actual assembly mechanism. Instead, the assembler tells the printed circuit board which components need to be connected to each other. The "magic printed circuit board" is now responsible for querying the components and determining the best mechanism to connect the piece parts together. We have moved from explicitly stating the connection mechanism to only stating the intent.
In the physical world, creating the "magical printed circuit board" is... well, challenging. In the logical world it is quite easy. At the core, it means:
- We use policies to describe capabilities and interfaces.
- We publish the policies in a consistent manner.
- We perform protocol negotiation at runtime.
- We build components with high decoupling potential.
- We build components that were designed to connect to Dynamic Decoupling Devices.
- We quit hardcoding our assembly mechanisms.
- We mandate the use of Dynamic Decoupling in assembly.
If an architecture is indeed defined by the constraints rather than the features, than the aforementioned may serve as an architectural style that facilitates reuse without giving up performance.
A common belief is that software engineers should design services to be 'loosely coupled'. That is, they should verify that the service can speak the 'least common denominator' and do it in a manner that mitigates the impact of location: attempt to minimize the impacts associated with distributed computing (location transparency).
In the physical world, we use devices to decouple entities. Instead of soldering two components together, we connect each component to a plug and then use the plugs to connect the items together. This is necessary in the physical world.
In the logical world, we have the opportunity to attach a 'plug' to the end of a component or a service. And just like in the physical world, it costs more money to buy and attach the plug. But, the plug should make the component more reusable. That is the investment.
Imagine an electrical component that is attached to a printed circuit board. The component has nice plastic plug coming off of it enabling other components to easily connect to it. In addition, the wire lead on the component is exposed and it is mounted in such a way that additional wires can be soldered directly to it. In essence, the component was designed with loose coupling in mind (the plug) but the instantiation (or the use) of the component allowed the engineer to bypass the plug by directly connecting to the wire lead.
Here, the component has both 'component design-time' and 'assembly design-time' properties. The 'component design-time' properties describe the features that the component has; in our case, we are interested in the plug at the end. The 'assembly design-time' deals with the decisions that the engineer makes at design time when they assemble multiple components together (e.g., does the engineer use the plug or solder directly to the wire?)
When we discuss loose coupling or tight coupling, we must remember that there are different issues to consider:
1. The level of investment that was placed on enabling a component to be loosely coupled (e.g., it comes with a plug attached). [POTENTIAL COUPLING]
2. The decisions that the component assembler made when combining the piece components (e.g., they used the plugs everywhere vs. soldered them together everywhere vs. some combination) [ASSEMBLY COUPLING]
3. The option of delaying the assembly interface mechanism decisions to runtime. [DYNAMIC COUPLING]
A significant amount of literature is available on making components/services reusable (creating high potential decoupled devices); thus I won't revisit. Less is written on Assembly Coupling, but I'm still happy with my, "Service Coupling Index" as a foundation. However, very little information is available on the concept of Dynamic Coupling.
In many ways, Dynamic Coupling contradicts the 'loosely coupled' manifest. Rather than stating that something must be implemented in a certain way (asynchronous, document centric, XML based, etc.), it states that the component need only have Decoupling Potential AND that the component be aware of any Dynamic Decoupling Device.
I like to think of the Dynamic Decoupling Device as a "magic printed circuit board". Here, the assembler inserts components into the board. But rather than soldering the components together or using plugs to connect them, the assembler will never execute the actual assembly mechanism. Instead, the assembler tells the printed circuit board which components need to be connected to each other. The "magic printed circuit board" is now responsible for querying the components and determining the best mechanism to connect the piece parts together. We have moved from explicitly stating the connection mechanism to only stating the intent.
In the physical world, creating the "magical printed circuit board" is... well, challenging. In the logical world it is quite easy. At the core, it means:
- We use policies to describe capabilities and interfaces.
- We publish the policies in a consistent manner.
- We perform protocol negotiation at runtime.
- We build components with high decoupling potential.
- We build components that were designed to connect to Dynamic Decoupling Devices.
- We quit hardcoding our assembly mechanisms.
- We mandate the use of Dynamic Decoupling in assembly.
If an architecture is indeed defined by the constraints rather than the features, than the aforementioned may serve as an architectural style that facilitates reuse without giving up performance.
Monday, May 31, 2004
The Suckline
The other day I bumped into an old friend (Tim) that specializes in Java and database development. He asked what me about my interests and I told him that I have been working with web services. He said, "Oh, aren't those slow?"
Sure, I had 101 smart-ass answers loaded in my arsenal, but this individual was asking a serious question that deserved a real answer.
I answer him, "Well, I guess it depends. Generally speaking, anytime you use distributed computing techniques you will incur extra overhead - and that overhead could lead to poorer performance or response times." This answer clearly annoyed him. He responded, "Yea, I know that you use 'distibuted computing' to distribute computing and the effects that this has... my concern is that web services leverage a bunch of abstract protocols that just weren't designed with performance in mind."
"Ah... I get your point. The protocols suck?"
"Yes - the protocols suck - if you have any concern for performance."
Ok - now we were getting somewhere.
"Tim, the reason they suck is because the big-boys (IBM/MS) chose to roll out 'Least Common Denominator' (LCD) solutions to distributed computing first. When you need to create an ad-hoc computing platform and you don't know the capabilities of all of the participants you must choose only those capabilities that are guaranteed to be available across all nodes. You have to create an LCD baseline (which I call the suckline). The suckline is the decision to use the lowest common denominator capabilities across participating nodes in order to guaranteed communications."
Tim nodded in agreement and commented, "But what you implying is that there is something else out there that doesn't suck - - like a Greatest Common Factor (GCF) solution?"
"EXACTLY - - but there isn't! And that my friend, is the beauty of it...(laugh)..." He looked at me like I was insane - which is a look that I thrive on. "Web services are about protocol negotiation. Currently, we only have one solution for just about any facet of web service computing - encoding, encryption, reliability, transactions, discovery - you name it - we have a version of it that more or less sucks! And you know what - that's ok! IBM and Microsoft have had the patience to work on an LCD platform for as long as they have - and in the face of 'performance critics' - I tip my hat to them. If the protocol negotiation is done correctly you should be able to use a metadata described invocation and interface description mechanism that is linked to a protocol policy for runtime resolution."
Tim asked, "So you believe that it really is just an issue of 'premature optimization'"?
"Absolutely - two communicating java applications will be more efficient at sending serialized java objects then they will be at sending and receiving XML documents. If the applications are on the executing on the same vm, it would be more efficient if they used some kind of shared memory. The GCF capabilities of the participants MUST be determined dynamically (or cached). Should the two applications be prepared to go down to the suckline? Sure - the suckline represents the ubiquity baseline of modern computing."
"Jeff, you just crossed from distributed document oriented to distributed object-oriented computing. I thought that web services was all about document oriented, XML based, loosely coupled, asynchronous..."
"No! - and yes..." - I injected. "This is where I disagree with most of the world. If you ask most people that live and breathe web services... they would agree with your comments. However, I'm not one of them. To me, web services describe a programming model that is evolve-able. The SINGLE most important feature for me is the ability to use protocol negotiation to determine the instance of the programming features and functions that you deem necessary to create a dynamic virtual computing platform. The document oriented problem is really a fatty-chatty problem - and there are solutions to this as well."
Tim commented, "That's cool. But we still have the problem that today web services are slow and we are stuck with the suckline."
"Yep - you are correct. Microsoft has already moved Indigo towards a GCF programming model. IBM is doing the same. What is unclear is if a generic J2EE type solution will become available (in time) to compete against the MS solution. Otherwise, you will see a splintering in the next-gen Java SOA marketplace with only 1 or 2 vendors agreeing to agree on the GCF solution. And yes, it is very possible that the GCF solutions will have patents hung all over them."
"Tim, I can't predict the future, however - I bet on smart people and funded projects. Right now MS, IBM and others are putting their best people on web services and throwing lots of cash at it. Trust me - we will move way beyond the suckline - there is too much money on the table."
Sure, I had 101 smart-ass answers loaded in my arsenal, but this individual was asking a serious question that deserved a real answer.
I answer him, "Well, I guess it depends. Generally speaking, anytime you use distributed computing techniques you will incur extra overhead - and that overhead could lead to poorer performance or response times." This answer clearly annoyed him. He responded, "Yea, I know that you use 'distibuted computing' to distribute computing and the effects that this has... my concern is that web services leverage a bunch of abstract protocols that just weren't designed with performance in mind."
"Ah... I get your point. The protocols suck?"
"Yes - the protocols suck - if you have any concern for performance."
Ok - now we were getting somewhere.
"Tim, the reason they suck is because the big-boys (IBM/MS) chose to roll out 'Least Common Denominator' (LCD) solutions to distributed computing first. When you need to create an ad-hoc computing platform and you don't know the capabilities of all of the participants you must choose only those capabilities that are guaranteed to be available across all nodes. You have to create an LCD baseline (which I call the suckline). The suckline is the decision to use the lowest common denominator capabilities across participating nodes in order to guaranteed communications."
Tim nodded in agreement and commented, "But what you implying is that there is something else out there that doesn't suck - - like a Greatest Common Factor (GCF) solution?"
"EXACTLY - - but there isn't! And that my friend, is the beauty of it...(laugh)..." He looked at me like I was insane - which is a look that I thrive on. "Web services are about protocol negotiation. Currently, we only have one solution for just about any facet of web service computing - encoding, encryption, reliability, transactions, discovery - you name it - we have a version of it that more or less sucks! And you know what - that's ok! IBM and Microsoft have had the patience to work on an LCD platform for as long as they have - and in the face of 'performance critics' - I tip my hat to them. If the protocol negotiation is done correctly you should be able to use a metadata described invocation and interface description mechanism that is linked to a protocol policy for runtime resolution."
Tim asked, "So you believe that it really is just an issue of 'premature optimization'"?
"Absolutely - two communicating java applications will be more efficient at sending serialized java objects then they will be at sending and receiving XML documents. If the applications are on the executing on the same vm, it would be more efficient if they used some kind of shared memory. The GCF capabilities of the participants MUST be determined dynamically (or cached). Should the two applications be prepared to go down to the suckline? Sure - the suckline represents the ubiquity baseline of modern computing."
"Jeff, you just crossed from distributed document oriented to distributed object-oriented computing. I thought that web services was all about document oriented, XML based, loosely coupled, asynchronous..."
"No! - and yes..." - I injected. "This is where I disagree with most of the world. If you ask most people that live and breathe web services... they would agree with your comments. However, I'm not one of them. To me, web services describe a programming model that is evolve-able. The SINGLE most important feature for me is the ability to use protocol negotiation to determine the instance of the programming features and functions that you deem necessary to create a dynamic virtual computing platform. The document oriented problem is really a fatty-chatty problem - and there are solutions to this as well."
Tim commented, "That's cool. But we still have the problem that today web services are slow and we are stuck with the suckline."
"Yep - you are correct. Microsoft has already moved Indigo towards a GCF programming model. IBM is doing the same. What is unclear is if a generic J2EE type solution will become available (in time) to compete against the MS solution. Otherwise, you will see a splintering in the next-gen Java SOA marketplace with only 1 or 2 vendors agreeing to agree on the GCF solution. And yes, it is very possible that the GCF solutions will have patents hung all over them."
"Tim, I can't predict the future, however - I bet on smart people and funded projects. Right now MS, IBM and others are putting their best people on web services and throwing lots of cash at it. Trust me - we will move way beyond the suckline - there is too much money on the table."
Subscribe to:
Posts (Atom)
Posts
