|
|
| Service Oriented Enterprise |
|
|
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. posted by jeff | 8:26 AM 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. posted by jeff | 2:51 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
