The South East Asia SOA Weblog

I have been doing a little research on Android development lately. Not so much because of the mere cool factor but more so the obvious potential for Android to become the OEM platform of choice for mobile. Looking back at some of the key reasons why x86 PC’s and DOS prevailed back in the 80’s and even why Java has gained such wide acceptance in the enterprise through the 90’s and 2000’s, we can glean some possible insight into what fosters strong adoption in the user community. To me it comes down to a few key factors:

o User interface acceptance, abilities and “coolness”
o Availability of key/killer applications for the platform.
o Ease of Development and SDK (leading to availability of key applications.
o Portability across multi-vendor OEM hardware platform.
o Strong support from developers and the OEM market.

Looking at the overall smartphone market which is arguably led by RIM at around 40% (depending on whose numbers you look at and excluding Nokia/Symbian which is number 1 if you take every handset ever sold into account) it seems that the market kind of resembles the minicomputer market of the 1970’s in terms of overall market development, standardization and proprietary platform domination. It should be interesting to see how this all plays out. Taking a closer look at Android…

1) It seems just as cool as any of the other smartphone UI’s out there… including iPhone
2) There is a burgeoning market for applications already after less than a year in the market.
3) Development seems pretty straigtforw3ard to me… I was up, coding, debugging and running on Eclipse in no time.
4) It is built on a Linux/Java base… what could be more portable?

I am not one for predictions so I won’t indulge in that but nonetheless it does seem that Android has a bright future and could gain a significant share of the smartphone OS market through OEM’s over the coming two or three years. Let’s see.

SOA standards have long been maturing and as of the last few years we now have a fairly complete suite of interoperable standards to work with in the web services world other than a few minor vendor nuances. One of these standards is the WS-Eventing standard (http://www.w3.org/Submission/WS-Eventing/) which leverages other key SOA standards such as SOAP 1.1 SOAP 1.2 and WSDL 1.1 among others.

Building an applications integration framework is still a steep challenge as SOA standards, tools and frameworks have not yet matured to the same extent as the preceding generation of integration solutions loosely falling under the EAI (Enterprise Applications Integration Banner). That being said there is still hope.

The WS-Eventing standard provides the SOA platform with key messaging capabilities similar to the way that JMS and other messaging frameworks provided those capabilities for the previous generation of EAI style integration components. The basic principles of WS-Eventing are in fact very similar to JMS but of course operate at application level and inter-operate nicely with other SOA standards. As with the other SOA protocols, the transport for WS-Eventing may be implemented across multiple underlying technologies such as HTTP and JMS. In my opinion this is one of the innate strengths of the web services stack as it allows applications to route messages at application level across multi-vendor environments thus freeing the application from vendor specific integration.

In this article I will outline the basics of the required components. In later articles I will provide detailed guidance regarding how to create an application-to-application integration infrastructure using WS-Eventing and SOA web services.

Application Integration Componentry: When implementing applications integration there are a few necessary types of component that normally comprise a strong architecture:

The Common Bus or Hub
The Application Adapter
The Common Schematic View
The Application Schematic View
Message Transformers

The common Bus or Hub: normally incorporates facilities such as transport, security, routing, common schema definition, common transformation, logging and other features. The modern SOA incarnation of this is of course the ESB. The quintessential difference between the modern ESB and previous message brokers and hubs is that it supports the use of key SOA web services standards and is built to accommodate the needs of a service oriented architecture.

The Application Adapter: is usually delivered as a pre-built component and possibly an API which provides developers a way of integrating data and transactions vertically to applications. Typically the applications adapter provides two major interfaces, the inbound interface and the outbound interface. The inbound interface handles any messages (transactions & data) bound for the application. The outbound interface “senses” any changes in the data within an application and publishes outgoing messages to the bus or hub to notify other applications that an application event has occurred. Typically it is the role of the adapter to transform the format of outbound messages from the application schematic view to the common schematic view and inbound messages from the common schematic view to the application schematic view. A good example of such a standard is/was JCA. Many JCA adapters exist today and many of the current generatio9n of applications adapters also support SOAP based interfaces. The great weakness in most of today’s applications adapters is lack of support for WS-Eventing which relegates the use of such adapters to northbound integration with older technology and over-complicates matters.

Presently the suites of SOA standards do not provide a standard for applications adapters in the same way that J2EE provided JCA.

The Common Schematic View: is usually defined within the context of the central bus or hub and provides a schema to which all applications adapters should conform when sending and receiving messages. Typically this schema is implemented with XML documents. Older implementations use XML DTD but most modern implementations use XML XSD.

The Application Schematic View: is defined within the context of an application. It provides a transformed schema that supports the way in which data should be represented within specific applications. Like the common schematic view this is usually defined with XSD.

Message Transformers: provide the components and logic to transform messages from one format to another. With XML messages this is typically accomplished using XSLT. Of course the broad requirements of integration usually also dictate that non-XML messages be handled therefore message transformers may exist to handle transformation to and from any specific formats (usually to and from the XML representation or from one XML representation to another). An example of a message format that is becoming popular is REST (representation state transfer) which uses an internal schema based on JSON data types. An emerging common application requirement is transformation between JSON and XML.

The Current SOA Technology Situation…

The current situation is that no standards exist that cover all of the aforementioned components and address the end to end framework required for implementing EAI-style integration using SOA technology. That being said, WS_Eventing does provide a very neat transport mechanism for outbound applications adapters to publish events to and ESB. Our favorite ESB right now is WSO2 ESB which provides a full implementation of the WS-Eventing specification with the ability to route, transform and manage subscriptions in a durable manner. We are in the process of developing a framework and API that delivers applications adapters and transformations that leverages WS-Eventing.

Watch this space…
Over the coming weeks we will be releasing an application adapter framework based on WS-Eventing that can be used with any ESB or server infrastructure that supports WS-Eventing and SOAP. Watch this space.

Most of the blogs and comments I have found around the place with this issue are either out of date or just do not work at all. I managed to find some time to get this going because we were having issues with WSO2 ESB 3.0 deadlocking on the H2 database. Please bear in mind that we are yet to fully test this configuration but at least the ESB starts up and functions normally.

Most of the documented problems and solutions were centric to getting the JDBC side of things configured correctly but none of the comments I viewed were correct. The environment I am using is Oracle 10g release 2 on RHEL with WSO2 ESB 3.0. This should also work with 11g Database.

To get the JDBC issue resolved and get ESB up and running I ended up doing exactly as follows:

1) Set up the account for wso2carbon in Oracle and grant it resource

Code:

One of the blog entries I saw said to grant dba… that is an absolute sledge hammer approach. Even granting resource is too much. Any decent DBA will reduce the privileges to an absolute minimum required for run time.

2) Run the wso2esb-3.0.0/dbscripts/oracle.sql script in sqlplus or any other tool using the newly created wso2carbon account of course

Optionally now revoke resource privilege from the esb user to secure the DB

3) Copy the $ORACLE_HOME/jdbc/lib/ojdbc14.jar into the wso2esb-3.0.0/lib/endorsed directory

Many of the other comments around the place say to copy all the drivers from $ORACLE_HOME/jdbc/lib but this is wrong if you intend to user the thin driver. Also it must be copied into the lib/endorsed directory otherwise the JVM permissions will prevent it from being loaded and driver class instances from being created correctly

4) Configure the driver specs in the /wso2esb-3.0.0/repository/conf/usr-mgmt.xml and /wso2esb-3.0.0/repository/conf/registry.xml under the Configuration entry to:

Code:

make sure you add all the colons and use the exact url specification or you will get weird errors like “No suitable driver found"… that can take time to debug or find

5) Next you should then run the ESB using the shell script or batch file to start it… it should start if you have followed the above instructions meticulously.

NOTE: We are yet to fully test this configuration. The reason we migrated to this configuration is that we have several end points and several proxys within the WSO2 ESB for one of the solutions we are building and the ESB was dropping end points from the configuration due to deadlock problems with the default H2 database… at least that is our assessment. We reverted the solution to WSO2 ESB 2.1 and will upgrade to 3.0 again once (hopefully) these problems are resolved and we are fully tested.

My company has been an Amberpoint partner for a couple of years. We have been committed to this product set for SOA Governance for a while now. Disappointingly, Oracle has just announced that they will acquire Amberpoint. As usual Oracle are upbeat about this but you have to start wondering how healthy this is for the IT industry as a whole as the resultant industry after all these acquisitions fundamentally offers customers and systems integrators far less choice regarding the business relationships they need in order to deploy the solution sets they desire. There is also a far broader issue regards the stifling innovation in our industry.

I put it to you and Oracle that smaller, focused and more agile companies like Amberpoint are able to specialize and innovate faster. Behemoths such as Oracle, IBM and HP find it far more difficult to innovate outside their traditional areas of core expertise as they are just not tuned into investing time and resources that way. There is only one beneficiary for this type of acquisition and that is the company making the acquisition. I am convinced that it is not good for customers, integrators or the industry as a whole. Most of the products aquired by the these companies just stagnate after the acquisition (I could cite many many examples of this including most of the 60 odd companies Oracle has acquired over the past 5 years).

Acquisitions of this nature are simply opportunistic, funded with debt and aimed at make rich companies more powerful; and controlling thus disadvantaging the smaller players. This won’t be the first time a corporate software company acquisition has cost me dearly (the other two were NetBeans and Star Office… which incidentally are both now owned by Oracle after the Sun acquisition). Oracle’s web site has a letter for Partners. Unfortunately it only talks about Oracle partners (http://www.oracle.com/amberpoint/partner-letter.html) and does not mention anything about the existing Amberpoint partners which I think is a little careless of them (characteristically).

It appears that the center of innovation in the IT industry at present seems to be the open source companies. Let’s hope that trend continues and isn’t stifled in the same way.