One of my personal objectives for this JavaOne conference is to get a clear – of if that is too ambitious at least a clearer – view of what SDO and SCA are or will be in the near future. It seems that from various presentations I should be able to piece together the picture step by step. And pretty major step in that direction was made through Doug Tidwell’s (IBM) presentation “Open for business – making SOAs safe for developers with open standards”. Besides delivering an informative talk, he managed to make it a highly entertaining one as well. I would not have believed it, but the audience laughed or at least chuckled its way through an hour of XForms, SDO and SCA. If he ever comes to a theater near you, try it out!
Doug’s objective with this talk was to make the audience understand how XForms, SDO and SCA will make life easier and how to get started with those technologies. A quick poll of the audience – some 300 people – revealed that some of them were using SDO and or SCA; however none was currently working with XForms.
XForms
XForms as a better way to implementing input facilities in browser based applications, with a tighter integration between the Form displayed in the browser and a backing data model, can be a valuable replacement for the HTML Form we are typically struggling with. XForms are defined through a simple XML based markup language, somewhat similar to JSF notation and not too far from HTML itself. I think probably everyone agrees that XForms are a better way of defining the data input elements in an HTML page than the normal HTML way of doing things. However, for some reason – and XForms has been around since 2003 or so – XForms never has really caught on. We still need plugins for the browser to get an XForm going. Doug used the XForms plugin for Firefox, and that seemed to be working pretty well.
Note that XForms are a standard defined by W3C, the organization that brings us specifications such as HTML, XML, SVG and many more. However, with most JSP libraries, JSF components and AJAX frameworks focused on good old HTML Forms, it is hard to see how a momentum for XForms will start to build.
Standards
Doug pointed out how important standards are for the industry as well as individual developers. Thanks to standards, applications can interoperate, developers can talk to one another, overall developments in the IT world can go much faster and the concept of SOA can become or already is a reality. Major vendors joining forces, undoubtedly with some personal agenda as well, but with a clear mutual alignment – to the greater good of all of us. Well, in many areas it seems to be working. SDO and SCA are just about to become two of those areas it would seem.
Then, on a slightly less serious note, Doug suggested that some standards, or perceived standards may not be all they are cranked up to be. He tried out eDoug and when that did not catch on tried out Doug 2.0. His wife suggested that was the same old crap with a new name, so he dropped the 2.0 label again.
Standards can become overwhelming though and that may be a threat to their value or at least their effectiveness. He polled to the audience for knowledge of (all) the WS-^ standards and reached the conclusion that perhaps God knows half of them.
SDO – Service Data Objects
SDO is an industry standard for accessing data. SDO gives you a single API to a wide variety of data sources. Developers can focus on CRUD against the SDO API, they do not (need to) care where /what the data source is (database, WebService, XML file, JCA, EJB..).
SDO adds a layer of abstraction on top of specific various data sources, a disconnected interface. Doug pointed out that the concept of ActiveRecord, a design pattern implemented for example in Ruby on Rails, is in fact quite similar to SDO.
Code can be more robust and stable, not necessarily more productive, with applications built on top of the SDO API, independent of the current underlying data source. Switching the data source, from Relational Database to Object Database, from Web Service to XML Files, should all be pretty much transparent to the developer and the application.
Recently the OSAA at OASIS published the 2.1 release of SDO. Implementations of SDO are gradually appearing, including the Apache Tuscany project (http://incubator.apache.org/tuscany/). More implementations are referenced at http://osoa.org/display/Main/Early+Implementation+Examples+and+Tools#EarlyImplementationExamplesandTools-sdo.
To me this sounds very much like JSR-227 – the data binding spec proposed by Oracle and implemented by ADF Model aka Data Binding. Some discussions later it seems that ADF Model probably should be seen as one implementation of the SDO specification. However, it needs some additional wrappers to implement the SDO interface.
That would make it seem as though we can have Toplink providing an implementation of EJB 3.0 JPA and EJB 3.0 JPA itself providing an implementation – for which we would require some additional wrappers – of SDO.
I do still not know in detail what SDO looks like and how I code against the interface, but Doug certainly managed to get me interested more.
SCA – Service Component Architecture
SCA attempts to provide to developers in the area of Services what SDO provides for data sources: give developers a single programming model for using services. This means that whether the developer has to program against interfaces in EJB, RMI, JCS, Java APIs for XML – JAX-WS or JAX-RPC, it does not matter. The developer codes against the SCA APIs and the SCA aware container (?) knows how to turn those calls into the proper protocol or technology specific invocation. It would seem that that is to certain extent what ESBs are doing as well: virtualizing services by providing a technologicall uniform API and internally turn service calls into invocation to specific technology interfaces. Whether that means that for vendors their ESB will be the core component of their SCA implementation would seem logical, but I may be misreading things.
The benefits of SCA include:
if it is not convenient to convert everything (every API in your organization and the organizations you interoperate with) to a Web Service, it may be hard to deal with many different protocols and technologies. SCA provides an easy means of integrating many kinds of components. The SCA ‘container’ deals with technology impedance mismatch, the developers only need to know SCA. That is the theory at least. That also minimizes the learning curve for developers => just connect them without learning new APIs, except for SCA. No need for JCA, SOAP, EJB etc.
Of course using SCA to access services, rewiring of components and data resources or integrating additional services or SDO data sources can be done without changing the code. Again, in theory. SCA allows developers to focus on reusable business logic; SCA provudes the SOA model and hides the middle ware complexity from developers. SCA give a declarative way to establish policies, such as “this component must provide level of QoS” or “all data on the wire between these components need to be digitally signed”.
Some terms from the SCA specification: Components represent services or APIs in any one specific technology. Composites are components grouped together with “internal” wiring, offering a coarser grained service to consumers. Wires are the hooks between Components and Composites. In SCA a binding specifies how to access a service.
Doug then made a strong statement, on behalf of IBM: “In our view: you will not be able to handle complexity of SOA without SCA.” Well, that sounds like a serious endorsement!
Several vendor
s
claim they have implementations of SCA containers available or in the works. It is hard to determine exactly what is available today, and that is one of this week’s remaining challenges I suppose. Yesterday I was given a brief demonstration of the upcoming JDeveloper 11g release that has support for visually modeling with SCA Components, Composites and Wires. The run-time SOA Suite infrastructure in the application server is not yet available for 11g unfortunately.
Bracketology
Doug’s talk concluded with a demo – based on the game of Bracketology from his home state. He writes about it on his blog as well:
http://www-03.ibm.com/developerworks/blogs/page/Doug_Tidwell?entry=bracketology. I cannot explain what it is, except that the demo was good fun.
The demo application has User Interface in X-Forms – running with the Firefox plugin -, does data access through SDO and has services tied together with SCA. He did not show any code for this, just the running application. So while being a nice feel-good demo, it not do much to further explain the SDO and SCA concepts. Doug promised that the code for demo application will be on his blog later this week, so I will go and give it a closer look: : http://www-03.ibm.com/developerworks/blogs/page/Doug_Tidwell.
