Upon rereading my original post on SCA and Java world, I've realized that it's a little bit on the long winded side, so I thought I would summarize the key points in the following paragraphs.
What and why SCA?
· SCA is a set of specifications dedicated to developing a platform neutral service component model.
· SCA extends Web services to include multiple binding technologies (REST, RMI, JMS, and yes WSDL/SOAP) under a consistent model
· SCA makes SOA simple and possible by providing a clean POJO (or POCO, or POPO, etc.) development model, dirty nasty protocol details and service platform API calls are completely removed from service code,
· SCA does for service architecture what Spring did for the Java platform
Why is SCA better than JAX-WS, JAX-RS, etc.?
IMHO SCA is a better approach than comparable offerings from the JCP world (e.g. Jax-WS, Jax -RS, JBI, etc.). SCA is a true community process backed by both vendors, independence, and professional services organizations. We all heard complaints about Sun's dominance in the JavaEE world. The specifications have been submitted to Oasis for proper standardization, I have contributed to the process, although less than I like, but it truly is an open approach.
SCA offers a consistent programming model that is simpler, dependency injection-based, and consistent. We all know the realities of JavaEE, I know it's getting better, but in my opinion no comparison.
Tuscany is a great open source implementation of SCA, with real-world production implementations
Jean-Sebastien Delfino and Mario Antollini gave a incredible presentation on Tuscany my favorite open source implementation of SCA. The highlight of the presentation (IMHO) was when Jean-Sebastien showed had easily extend the SCA specification to include mashups/Web 2.0 component creation. My opinion this is one of the highest values of SCA, a truly comprehensive component model that spans technologies, from simple AJAX/ATOM components to more complex WSDL/SOAP style services. Brilliant.
This session really showed how easy it was to make services, or components of any nature using SCA
Sun has no intention of working with SCA, and there are some concerns about a fracture within the Java community
David Chapelle moderated a panel that included all the big SCA vendors. David made a big deal about the fact that SCA is causing a splinter in the Java community by offering another programming model. He also expressed big concerns around the fact that not everybody at the panel agreed on the level of support for the proposed programming model. I think David is being a little ridiculous, possibly intentionally so, he does come off as a really clever guy, and he is a "Microsoft" guy.
First of all, Java already has a multitude of programming models; Spring explicitly says that it has its own component model. Not to mention that working with components in a scripting language (like jRuby) is going to use a very different programming model than working with components using the core Java platform language. One of the core strengths of the Java platform is the diversity offers, Microsoft seems to like one approach, one platform, one model, sadly this approach suffers from getting rapidly date, and irrelevant to the people who actually need to use this stuff i.e. the developers.
Secondly, the SCA programming model is a POJO programming model, it's based on annotations, XML configurations, and dependency injection. So is uneven adoption somewhat of a concern? Sure because it's a great programming model, but the beauty of DI is that code can be easily plugged into different containers regardless of the model being supported, as long as it's a POJO one, (or POPO) with very little pain, so I think this big concern about disparate programming models is a much ado about nothing.
I did speak to Peter Walker from Sun after the panel was over, and certainly a good thing that Sun was actually at the panel this year, but according to Peter, Sun still sees no need to adopt SCA. As far as he is concerned, his "users" aren't asking for it. Ridiculous, there was a CapGemini employee as part of the panel, and I also know that Deloitte has huge interest in SCA. (I won't say why hint, hint) so the two major technology consulting firms don't count as users then who do? I think I smell a e-mail letter campaign coming...
Tuesday, May 13, 2008
JavaWorld 2008 part 2: Service Component Architecture
For the second part of my JavaOne 2008 coverage I'd like to talk about Service Component Architecture (SCA). I was very lucky in that I was able to go to three sessions talking about SCA pretty much in a row.
What is exactly SCA?
For those of you who are unaware of what SCA is, I'll give a brief introduction. SCA is a suite of specifications being considered on the the oasis mantle dedicated to defining a protocol and platform neutral service oriented component language. The primary purpose of this language is to allow developers or service assemblers to define a set of services, references, and bindings into a suite of composite structures.
SCA allows a developer to take code assets developed in a number of languages such as Java, Python, BPEL or C++ and wire them together with a minimum of protocol or SOA infrastructure knowledge. This wiring is typically done using the type of dependency injection techniques that many Java developers may have first come across when looking at the Spring framework.
In point of fact, when trying to describe SCA to people who have never heard of it before, I often compare frameworks using SCA to the Spring framework. But where Spring is focused on providing cross cutting concerns and dependency injection within a service platform, SCA focuses on how to use dependency injection to wire various components together regardless of the protocol of the wire, or the target platform/language of the service.
Services built using the SCA specifications have no inheritance or API dependencies like services often built using the set of JAX/Java EE approach. The approach is much more Spring like, with a focus on XML configuration and annotations where appropriate.
SCA is in my opinion, an extremely important specification, the "why" is hopefully self evident.
SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications
The first session I went to was titled SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications. The session was held by Mike Edwards, who's one of the main authors and contributors of the SCA specification, and is a SOA strategist for IBM.
The session was pretty good, basically a general overview of SCA, its value proposition, along with a couple of examples/usage scenarios. I had seen most of the information before, and much of it can be found at the OpenSOA website. The important point to note about this session was that it was full, also thousand people attended, which is a great indicator of the interest in SCA from members of the Java community.
Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany
The following morning I went to the Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany session. The session was presented by Mario Antollini, Jean-Sebastien Delfino and the topic was focusing on an open source implementation of the SCA specification.
I've had the opportunity to work with the Tuscany group developing an SOA solution so I have to admit that I am a little bit biased, but I thought that this session was fantastic. Mario gave an overview of SCA, and its importance as well as a general overview of Tuscany, talking about the number of downloads, and the size of the community. I'll admit to not be nailed to remember the exact numbers, but the growth looked impressive. Mario also mentioned that Tuscany was in production, and that the project had been implemented by Deloitte, which I thought was a great plug.
Jean-Sebastian then gave a great demo of Tuscany, using a fruit and vegetable store as an example. She sure how to do some examples using typical SCA functionality, i.e. how to create a component, expose some of its functionality as services and how to bind the component to other services using references and wires.
From a technical point of view, the demo is interesting because it showed two things. One, the service code was completely uncluttered with any service API or service protocol concerns. The only way one could differentiate the services in the examples from a regular POJO was the import statements necessary to bring in the @remottable and @reference annotations. I've yet to see any examples from the JAX/Java EE world that comes close to creating business services that are this clean.
Secondly, was the fact that the services were using two different protocols (JSON and ATOM believe) for each operation, not necessarily a realistic scenario, but as Jean-Sebastian put it, it was certainly "fun to do" and also more importantly it should have easily it was to switch binding protocols and have no impact on the service code.
Next, Jean-Sebastian showed how Tuscany was being used to prototype various bindings and implementation types that the formal always has SCA specification have not yet considered. One of the mission statement of Tuscany is to act as a live test bed for the specification work, providing very realistic feedback on what works, and what doesn't. Jean-Sebastian extended the demo to include "Web 2.0" style bindings. Showcased the
Jean-Sebastian demoed the use of a "implementation.widget" to create a JavaScript style component that would be hosted by the browser and was able to take advantage of the same annotations they were used in the Java examples. These JavaScript SCA Web 2.0 widgets were able to take advantage of asynchronous communications à la Ajax, while using the same dependency injected, nonintrusive approach showcased in the server-side components. I think the ramifications of this are incredible, a common component model that can describe how to wire components together, regardless of whether they are JavaScript/Ajax widgets, EJBs, REST services or full-blown WSDL/soap web services.
Open Standards for SOA and Java Technology
The final session they went to concerning SCA was titled Open Standards for SOA and Java Technology, and was basically a discussion panel hosted by David Chapelle, and attended by the following SCA experts.
What is exactly SCA?
For those of you who are unaware of what SCA is, I'll give a brief introduction. SCA is a suite of specifications being considered on the the oasis mantle dedicated to defining a protocol and platform neutral service oriented component language. The primary purpose of this language is to allow developers or service assemblers to define a set of services, references, and bindings into a suite of composite structures.
SCA allows a developer to take code assets developed in a number of languages such as Java, Python, BPEL or C++ and wire them together with a minimum of protocol or SOA infrastructure knowledge. This wiring is typically done using the type of dependency injection techniques that many Java developers may have first come across when looking at the Spring framework.
In point of fact, when trying to describe SCA to people who have never heard of it before, I often compare frameworks using SCA to the Spring framework. But where Spring is focused on providing cross cutting concerns and dependency injection within a service platform, SCA focuses on how to use dependency injection to wire various components together regardless of the protocol of the wire, or the target platform/language of the service.
Services built using the SCA specifications have no inheritance or API dependencies like services often built using the set of JAX/Java EE approach. The approach is much more Spring like, with a focus on XML configuration and annotations where appropriate.
SCA is in my opinion, an extremely important specification, the "why" is hopefully self evident.
SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications
The first session I went to was titled SCA: Flexible and Agile Composition of Distributed Service Oriented Architecture Applications. The session was held by Mike Edwards, who's one of the main authors and contributors of the SCA specification, and is a SOA strategist for IBM.
The session was pretty good, basically a general overview of SCA, its value proposition, along with a couple of examples/usage scenarios. I had seen most of the information before, and much of it can be found at the OpenSOA website. The important point to note about this session was that it was full, also thousand people attended, which is a great indicator of the interest in SCA from members of the Java community.
Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany
The following morning I went to the Open-Source Service-Oriented Architecture with Service Component Architecture and Apache Tuscany session. The session was presented by Mario Antollini, Jean-Sebastien Delfino and the topic was focusing on an open source implementation of the SCA specification.
I've had the opportunity to work with the Tuscany group developing an SOA solution so I have to admit that I am a little bit biased, but I thought that this session was fantastic. Mario gave an overview of SCA, and its importance as well as a general overview of Tuscany, talking about the number of downloads, and the size of the community. I'll admit to not be nailed to remember the exact numbers, but the growth looked impressive. Mario also mentioned that Tuscany was in production, and that the project had been implemented by Deloitte, which I thought was a great plug.
Jean-Sebastian then gave a great demo of Tuscany, using a fruit and vegetable store as an example. She sure how to do some examples using typical SCA functionality, i.e. how to create a component, expose some of its functionality as services and how to bind the component to other services using references and wires.
From a technical point of view, the demo is interesting because it showed two things. One, the service code was completely uncluttered with any service API or service protocol concerns. The only way one could differentiate the services in the examples from a regular POJO was the import statements necessary to bring in the @remottable and @reference annotations. I've yet to see any examples from the JAX/Java EE world that comes close to creating business services that are this clean.
Secondly, was the fact that the services were using two different protocols (JSON and ATOM believe) for each operation, not necessarily a realistic scenario, but as Jean-Sebastian put it, it was certainly "fun to do" and also more importantly it should have easily it was to switch binding protocols and have no impact on the service code.
Next, Jean-Sebastian showed how Tuscany was being used to prototype various bindings and implementation types that the formal always has SCA specification have not yet considered. One of the mission statement of Tuscany is to act as a live test bed for the specification work, providing very realistic feedback on what works, and what doesn't. Jean-Sebastian extended the demo to include "Web 2.0" style bindings. Showcased the
Jean-Sebastian demoed the use of a "implementation.widget" to create a JavaScript style component that would be hosted by the browser and was able to take advantage of the same annotations they were used in the Java examples. These JavaScript SCA Web 2.0 widgets were able to take advantage of asynchronous communications à la Ajax, while using the same dependency injected, nonintrusive approach showcased in the server-side components. I think the ramifications of this are incredible, a common component model that can describe how to wire components together, regardless of whether they are JavaScript/Ajax widgets, EJBs, REST services or full-blown WSDL/soap web services.
Open Standards for SOA and Java Technology
The final session they went to concerning SCA was titled Open Standards for SOA and Java Technology, and was basically a discussion panel hosted by David Chapelle, and attended by the following SCA experts.
- Mike Edwards of IBM
- Steve Jones of Capgemini UK
- Patrick Leonard of Rogue
- Mark Little of Red Hat
- Sanjay Patil of SAP AG
- Michael Rowley of BEA Systems, Inc.
- Scott Vorthmann of TIBCO Software Inc.
- Peter Walker of Sun Microsystems, Inc.
David started out with an extremely fast "SCA in less than five minutes" introduction. I must say that for the most part I found David to be quite entertaining, a great speaker, and he did a great job of introducing SCA.
The format of the question-and-answer portion was as follows. David asked a question to one of the members of the panel, going from left to right (top to bottom on this list) once the panel member had answered, other members of the panel were free to join in with their own opinions. Rather than try to repeat every question-and-answer code like to get to the heart of the controversy of the panel, namely that David seemed intent on representing SCA as a fracturing of the JavaEE community, and that it was mainly a competition to the JavaEE model. Although many different kinds of questions were asked of the panel, David kept circling back to this idea. David also seem to take a lot of pleasure in stating that SCA was an awful lot like the Microsoft method of composing components, known as WCF. I guess I could agree with the statement, if SCA was built by one vendor, had no grassroots community involvement, supported one platform, and one real language, (sorry Visual Basic is not a language)
One of the first questions asked by David was "is SCA reinventing the wheel?" Mike Edwards responded to this one, stating that SCA is being worked on by a diverse group of industry and non-industry members, under the Oasis umbrella. While currently SCA is only a specification, it has been submitted to oasis as an official standard. He then commented on the fact that while SCA does include a Java programming model that defines how to code Java in the SCA world, it does have a much larger scope than many of the JavaEE branded specifications. Mainly, SCA is concerned with how to compose services out of components using a variety of languages and platforms including but not limited to the Java platform. Eventually COBOL components could be wired together with SCA
Mike Edwards also discussed the fact that we are SCA did compete with Java (mainly the programming model) SCA offered a much more declarative, API free, dependency injection -based approach it was not limited to just the Java language, but also to other languages that could support it like Python for example.
Other members of the panel also jumped in to state that a new JavaEE SCA specification was also being built to allow components built in the JavaEE world to also be extended with SCA specific annotations and configurations.
Another contentious question asked by David was whether SCA was causing a serious fracture in the Java community, namely because Sun was not supporting it. David then stated that it looks like the Java community has lost "it's fear of Microsoft" because they are no longer united. It was entrusting that unlike last year, a member of Sun was present. Peter, that there has been a lot of distorted press around a comparison of SCA and the Sun backed JBI specification. Peter stated that the JBI specification is a bottom up infrastructure technology. JBI is meant to address concerns of the much lower-level than SCA.
Throughout the panel David repetitively came back to the issue of a fracture within the Java community because of the alternate programming model offered by SCA. Sanjay Patil of SAP had in my opinion a very eloquent response. According to Sanjay, while it is true that the originals of J2EE may have come out of a vendor unification is Microsoft, it is long since matured past those humble beginnings. Currently Java is now about bringing together a extremely diverse community that plays in a extremely diverse ecosystem. Java now caters to the "tattooed, and orange haired" scripters, as well as the business oriented application developers, as well as mobile software implementers.
This means that there are a large number of programming models out there already everything from the vanilla JavaEE, to the more scripting oriented ones offered by jRuby, Jython, to the spring programming model, to the one offered by SCA . This diversity is good for the platform, as it makes it stronger, and able to cater to different needs. An excellent comment, and one I'm not sure that an advocate of Microsoft would ever understand. That, or I believe David is just being extremely clever, and trying to add a little bit of confusion where possible.
Steve Jones, the only non-vendor at the table, (a member of Gemini) also made an excellent point around the value of SCA. Namely that SCA allowed one to declaratively describe the architecture of the system from the point of view of the various component technologies being used, and how these technologies relate to each other. This would allow very large programs to structure teams according to each component technology, with the programming provided a explicit description around how these terms should interface with each other. This sounds an awful lot like a bounded context map described by Eric Evans' Domain Driven Design book. In my opinion, this point of view alone was worth the price of admission for this panel. After the panel made sure to discuss this with him, and was very pleased to receive his opinions which were insightful.
Once the panel was over speak to Peter, as I want to get his opinion on whether Sun would ever think about formerly incorporating SCA into JavaEE. In my opinion piercing slightly defensive, and quickly tried to switch the discussion around the benefits of glass fish, the benefits of JBI, et cetera. What I certainly had no disagreements in anything that he was saying, I again tried to press him concerning the rationale of why Sun would not consider SCA, I certainly don't see anything being offered comparably by Sun. His response was that Sun would certainly be open to it, but that their users were simply not asking for it. So my final comment on this would be that if any of you out there see SCA as being something of value let Peter know, because he is currently unaware.
Tuesday, May 6, 2008
JavaOne 2008 conference San Francisco, Day 1 report
I've just finished the first day of attendance at the JavaOne 2008 conference at San Francisco.
The morning was kicked off with a general session where the general vision of what the objectives of the Java platform would be over the next year was presented. I have to say, after being a little bit skeptical lately about the relevance of Java, and specifically the Sun version of Java, I was pretty impressed. Maybe it was the 80s style breakdancing fighting, or presence of Neil Young on the stage, but I was impressed by Sun's vision of Java going forward.
Sun shared a very collaborative, Web 2.0, and dare I say agile vision on how technology was going to evolve over the next year. One of the key statements concerned the removal of various barriers. Barriers between corporate and personal workspaces, between business users, content owners, and designers and developers, and barriers between different kinds of information.
A key message was that organizations trying to hold onto information within the corporate firewall are going to be big losers going forward. Sharing and collaboration are vital ingredient for ongoing success. Another key message was that no technology or even business solution would be successful using big upfront design or planning. The emphasis needs to be on rapid turnaround time, short iterations, and small teams working in collaborative environments that can provide a large variety of technology, creative design, and business skills. Sounds a lot like agile to me.
So how does this all relate to the Sun vision for Java going forward?
The first thing is the official separation of the Java platform from the Java language. Going forward multiple languages (122 currently) will be supported. Many scripting languages are being targeted, after all, the open source community has long proven the developer productivity of things like Ruby, Python and others. The next version of Java will include an official scripting extension mechanism, to better support and integrate things like JRuby, JPython and Groovy into the platform. Multilanguage support especially scripting support is now integral to the Java stack.
Another very interesting and relevant announcement is support for Rich Internet Applications. A new scripting language called JavaFX, will enable Java developers to create unified workspaces taking advantage of rich multimedia capability. The platform supports deep integration with applications like Photoshop and illustrator to allow developers and graphic designers to work together to build the next generation of truly rich desktop applications. JavaFX also provides Web 2.0 style APIs to support the merging of information from different providers, instrumentation of user activity for powerful analytics, and aggregation of services. The goal of JavaFX is to support a mashup environment where developers can find, merge, deploy, share and monetize using a Web 2.0 model. JavaFX is being touted as one of the key components enabling to build applications "free from a hostile OS (think Windows), free from a hostile provider (Google), owned by the developer"pure
Personally, I think Java is found a relatively unique space offering some of the cloudlike platform capabilities of Google, but allowing people to retain more control than currently being offered by either Google or Microsoft. Of course the breakdancing was really impressive.
Finally, there's going to be emphasis over the next year to make Java more modular, extensible, and easier for developers to use.
JDK 9 is going to have support for in Module visibility, something I have personally been waiting seven years for. There's also going to be support for better packaging and bumbling including OSGI compatibility. Better packaging means glass fish is going to be offered in a extremely small (9 kB I believe) base package with a subsection of the time. Various containers can be redeployed, undeployed, and exist in parallel at run time. (Think multiple EJB containers being deployed as necessary)
It looks like Java annotations are going to become even more robust, with support for much stronger type checking, so things like no pointer exceptions, write once objects, and other neat tricks will be supported at compile time.
All exciting stuff, I'll try to comment in equal detail for every day of the conference.
The morning was kicked off with a general session where the general vision of what the objectives of the Java platform would be over the next year was presented. I have to say, after being a little bit skeptical lately about the relevance of Java, and specifically the Sun version of Java, I was pretty impressed. Maybe it was the 80s style breakdancing fighting, or presence of Neil Young on the stage, but I was impressed by Sun's vision of Java going forward.
Sun shared a very collaborative, Web 2.0, and dare I say agile vision on how technology was going to evolve over the next year. One of the key statements concerned the removal of various barriers. Barriers between corporate and personal workspaces, between business users, content owners, and designers and developers, and barriers between different kinds of information.
A key message was that organizations trying to hold onto information within the corporate firewall are going to be big losers going forward. Sharing and collaboration are vital ingredient for ongoing success. Another key message was that no technology or even business solution would be successful using big upfront design or planning. The emphasis needs to be on rapid turnaround time, short iterations, and small teams working in collaborative environments that can provide a large variety of technology, creative design, and business skills. Sounds a lot like agile to me.
So how does this all relate to the Sun vision for Java going forward?
The first thing is the official separation of the Java platform from the Java language. Going forward multiple languages (122 currently) will be supported. Many scripting languages are being targeted, after all, the open source community has long proven the developer productivity of things like Ruby, Python and others. The next version of Java will include an official scripting extension mechanism, to better support and integrate things like JRuby, JPython and Groovy into the platform. Multilanguage support especially scripting support is now integral to the Java stack.
Another very interesting and relevant announcement is support for Rich Internet Applications. A new scripting language called JavaFX, will enable Java developers to create unified workspaces taking advantage of rich multimedia capability. The platform supports deep integration with applications like Photoshop and illustrator to allow developers and graphic designers to work together to build the next generation of truly rich desktop applications. JavaFX also provides Web 2.0 style APIs to support the merging of information from different providers, instrumentation of user activity for powerful analytics, and aggregation of services. The goal of JavaFX is to support a mashup environment where developers can find, merge, deploy, share and monetize using a Web 2.0 model. JavaFX is being touted as one of the key components enabling to build applications "free from a hostile OS (think Windows), free from a hostile provider (Google), owned by the developer"pure
Personally, I think Java is found a relatively unique space offering some of the cloudlike platform capabilities of Google, but allowing people to retain more control than currently being offered by either Google or Microsoft. Of course the breakdancing was really impressive.
Finally, there's going to be emphasis over the next year to make Java more modular, extensible, and easier for developers to use.
JDK 9 is going to have support for in Module visibility, something I have personally been waiting seven years for. There's also going to be support for better packaging and bumbling including OSGI compatibility. Better packaging means glass fish is going to be offered in a extremely small (9 kB I believe) base package with a subsection of the time. Various containers can be redeployed, undeployed, and exist in parallel at run time. (Think multiple EJB containers being deployed as necessary)
It looks like Java annotations are going to become even more robust, with support for much stronger type checking, so things like no pointer exceptions, write once objects, and other neat tricks will be supported at compile time.
All exciting stuff, I'll try to comment in equal detail for every day of the conference.