Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/inc/_main.inc.php on line 123

Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/inc/MODEL/generic/_genericelement.class.php on line 112

Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/inc/_blog_main.inc.php on line 306

Deprecated: Function ereg() is deprecated in /home/pwsconsu/public_html/blog/inc/_blog_main.inc.php on line 413

Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/plugins/code_highlight_plugin/_code_highlight.plugin.php on line 528
The South East Asia SOA Weblog - Archives for: May 2010

Archives for: May 2010

05/29/10

Permalink 07:41:47 pm, by david Email , 920 words, 11199 views   English (US)
Categories: SOA Solutions in South East Asia

Adapting to SOA Architecture Using WS-Eventing

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.


Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/skins/_feedback.php on line 102

05/28/10

Permalink 01:26:53 pm, by david Email , 527 words, 46001 views   English (US)
Categories: SOA Solutions in South East Asia

Correct Installation Procedure for WSO2 ESB on Oracle 10G Release 2

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:

grant connect to wso2carbon identified by wso2carbon;
grant resource to wso2carbon;

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:

[Property name="url"]jdbc:oracle:thin:@localhost:1521/orcl[\/Property]
            <Property name="userName">wso2carbon</Property>
            <Property name="password">wso2carbon</Property>
            <Property name="driverName">oracle.jdbc.driver.OracleDriver<\/Property>

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.


Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/skins/_feedback.php on line 102

Hosted by:
hosted by PWS Consulting

The South East Asia SOA Weblog

The intention of this blog is to collect thoughts on the issues, paradigms, process, vendors, solutions, project and any other item related service oriented architecture in South East Asia.


Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/plugins/_calendar.plugin.php on line 135
May 2010
Sun Mon Tue Wed Thu Fri Sat
 << < Current> >>
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

Search


Deprecated: Assigning the return value of new by reference is deprecated in /home/pwsconsu/public_html/blog/skins/_linkblog.php on line 46

XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 23