The debate sorrounding SOA(Service Oriented Architechture) and WOA(Web Oriented Architecture) is getting fiercer by the day and the blogosphere is abuzz with pundits claiming that WOA is the *in* thing citing plethora of reasons like simplicity, cost-effectiveness, decreased time to market, better manageability and so on. So, where does that lead SOA to - on the way to extinction? I don't think so.
To set the record straight, there seems to be a lot of misconceptions about both SOA and WOA - may think of them as a technology or an offshoot thereof. This is fundamentally wrong. They are, in fact, different architectural styles, or simply put two different way of doing things. And like similar styles in the same ecosystem, each has its own advantages and shorcomings. To simply put one ahead of the other, which is what is happening, is fundamentaly flawed.
Recently, while perusing an article in InformationWeek I came across some interesting stats about SOA. Let me share them with you.
"IT pros have expressed skepticism about SOA's promised return on investment. A 2007 InformationWeek Web survey of 278 IT pros found that 32% of those using SOA said those projects fell short of expectations. Of those, 58% said their SOA projects introduced more complexity into their IT environments, and 30% said they cost more than expected. Out of all respondents using SOAs, just 10% said the results exceeded expectations."
These are what the figures say, but what is indeed the fact? Well, the fact is that for a relatively new concept as SOA to stake claim to its usefulness in the market, it needs to spend a fair share of time in the market. If you look back 10-15 years from now, you will realize that its precursors like DCOM, CORBA had received the same lukewarm response. I do not put blame on organizations when they claim that the cost of implementing SOA far outweighs its usefullness, but such a statement can only be true for a small organization with relatively smaller number of offerings in their portfolio and when there aren't any pressing complexities. In such cases, it might make sense to go with an alternative to SOA, perhaps WOA.
Interestingly, Gartner Research defines WOA as "a subset of SOA". If you're using WOA, you are in anyway using SOA but not vice-versa. This again brings to fore the fact the debate between the two is on flawed grounds. In fact, for enterprises it is more of a choice between the two - or still better a mix of both, depending on their tech landscape. When it comes to service-enable a company's offerings, SOA (or WOA for that matter) should not be the default choice. A comprehensive study of what needs to be achieved is of utmost importance and this must the done first. Only after considerable thought has gone into this a choice should me made. For start ups and small companies that do not need complex integrations among disparate systems, WOA should be the approach, inasmuch as it is less complex and inexpensive to implement. Investing big money to set up SOA when such a set up serves no real advantage is totally uncalled for. For large oraganizations where huge integration setups are needed, WOA will be unsuaitable. It makes more sense to invest upfront on SOA and then reap the fruits in the long run.
So, it is not as much about SOA vs WOA as it is about the choice between the two. The approach should depend on what is desired and exactly what should be used to reach that goal. Ideally, a design should start with WOA and then add up SOA as and when the need so arises. In conclusion, the two are not diametric as they have been falsely portrayed to be, but are complementary.
Wednesday, August 27, 2008
Tuesday, August 26, 2008
REST Web Services demystified
The cacophony
Recenlty, a lot of dissonance has sorrounded the debate betwee REST(Representational State Transfer) styled web services and SOAP. In fact, proponents of REST group have even gone to the extent of procaliming that it is quickly gaining ground and will one day become the de facto standard of creating web services, forcing SOAP into oblivion in the process. The internet is abuzz with claims that SOA (based on SOAP) is a thing of the past and WOA (Web Oriented Architecture based on REST) is the future. Not wanting to be left behind, the exponets of the SOAP, on the other hand, want to leave no stone unturned to prove the others wrong. Whatever the noises may sound like it makes sense to look into REST. So, here is the REST story
What are REST styled web services?
As already stated, REST stands for Representational State Transfer. REST basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET. Other operations such as POST, PUT can be used to modify the object. In essence, REST it is the repsentation of the current state of a resource on the web.
The debate between REST and SOAP
While SOAP services are built on top of host of specifications laid down by OASIS, REST declares that the already existing WEB 2.0 standards are sufficient to build robust web services. Also, a major faction of REST supporters believe that using HTTP to piggyback payloads like SOAP does, is against the rationale of HTTP and an abuse to the protocol. It also brings in intricate complexities especially on the security front. One worth mentioning is piggybacking allows SOAP messages to get past firewalls and thereby places an additional constraint of detecting piggybacked payloads and scanning them prior to letting them in within the enterprise, which is not what firewalls are innately intended for. This is the main reason why both factions have always been at loggerheads with each other. More on this later.
Benefits of REST
Irrescpective of what the critics say there are some advantages that REST offers over SOAP. We shall now look at a few of them.
Simpler Interface
The REST methodology uses the URI(the way you send requests from your browser to a web site) for its implementation. Thus any request/response is a simple HTTP request/response. This keeps things simple, for nearly all applications on the web support HTTP. Thus, any application that supports HTTP can fundamentally produce and consume REST services. Contrast this with SOAP services, which have to adhere to specifications that go beyond HTTP thereby making it more complicated. Request/response are sent/received in SOAP envelopes which are XML that sit on HTTP for trnasport. So, there is the extra work involved in creating the SOAP request and parsing the response.
Light weight
From the above point it follows, that SOAP needs an additional XML wrapper above and over HTTP. This is unlike REST which is simple HTTP resquest/response. This can result in significant bandwith savings, especially for enterprises whose porfolio has umpteen applications interaction with each other at a massive level.
Security
Since firewalls are intended to restrict traffic by looking at the HTTP command in the request, it becomes inherently easy to apply security policies for REST services. For instance, if a GET operation was used, it can be considered safe since it can't, by definition, modify or alter data. It is here that SOAP can take liberties with the HTTP protocol. SOAP generally use POST and unless one has a good long look at the SOAP envelope, security apprehensions can't be put to rest. Since looking into SOAP messages is not a feature provided by fire walls, one needs to do extra work to enforce security at this level
REST service support in Oracle
In Oracle AS 10.1.3, you can use the command line Web Services Assembler (WSA) in conjunction with ANT or use JDeveloper (10.1.3) wizards to create and test REST services. The rest of the post describes how to create REST services with JDeveloper.
Creating REST services with JDeveloper
For the purpose of demonstration I shall use a simple class that concatenates one string with another and then publish it as a REST web service. Here is my class:
package com.nebulasky.blogspot;
public class HelloWorld {
public HelloWorld() { }
public String sayHi(String s){
return "Hello "+ s; }
}
Once this you have created the class, go back to the application navigator. Right click the context menu of the source java file and click 'Create J2EE web service'. In the second step of the wizard select the checkbox for REST Support (as seen in figure below) in the Java Web Service Wizard.
You can now click 'Finish' to complete creating the serb service. Deploy the service.
Testing the REST Service
You can test the process from the Enterprise Manager console by clicking on the 'Invoke REST POST' or 'Invoke REST GET'
Or you can even create the HTTP request and pass parameters using a query string. In my case it is
http://172.28.0.54:7777/BlogDemo-RESTHelloService-context-root/SayHiServiceSoap12HttpPort/sayHi?s=sankash
You should see something as this
Recenlty, a lot of dissonance has sorrounded the debate betwee REST(Representational State Transfer) styled web services and SOAP. In fact, proponents of REST group have even gone to the extent of procaliming that it is quickly gaining ground and will one day become the de facto standard of creating web services, forcing SOAP into oblivion in the process. The internet is abuzz with claims that SOA (based on SOAP) is a thing of the past and WOA (Web Oriented Architecture based on REST) is the future. Not wanting to be left behind, the exponets of the SOAP, on the other hand, want to leave no stone unturned to prove the others wrong. Whatever the noises may sound like it makes sense to look into REST. So, here is the REST story
What are REST styled web services?
As already stated, REST stands for Representational State Transfer. REST basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET. Other operations such as POST, PUT can be used to modify the object. In essence, REST it is the repsentation of the current state of a resource on the web.
The debate between REST and SOAP
While SOAP services are built on top of host of specifications laid down by OASIS, REST declares that the already existing WEB 2.0 standards are sufficient to build robust web services. Also, a major faction of REST supporters believe that using HTTP to piggyback payloads like SOAP does, is against the rationale of HTTP and an abuse to the protocol. It also brings in intricate complexities especially on the security front. One worth mentioning is piggybacking allows SOAP messages to get past firewalls and thereby places an additional constraint of detecting piggybacked payloads and scanning them prior to letting them in within the enterprise, which is not what firewalls are innately intended for. This is the main reason why both factions have always been at loggerheads with each other. More on this later.
Benefits of REST
Irrescpective of what the critics say there are some advantages that REST offers over SOAP. We shall now look at a few of them.
Simpler Interface
The REST methodology uses the URI(the way you send requests from your browser to a web site) for its implementation. Thus any request/response is a simple HTTP request/response. This keeps things simple, for nearly all applications on the web support HTTP. Thus, any application that supports HTTP can fundamentally produce and consume REST services. Contrast this with SOAP services, which have to adhere to specifications that go beyond HTTP thereby making it more complicated. Request/response are sent/received in SOAP envelopes which are XML that sit on HTTP for trnasport. So, there is the extra work involved in creating the SOAP request and parsing the response.
Light weight
From the above point it follows, that SOAP needs an additional XML wrapper above and over HTTP. This is unlike REST which is simple HTTP resquest/response. This can result in significant bandwith savings, especially for enterprises whose porfolio has umpteen applications interaction with each other at a massive level.
Security
Since firewalls are intended to restrict traffic by looking at the HTTP command in the request, it becomes inherently easy to apply security policies for REST services. For instance, if a GET operation was used, it can be considered safe since it can't, by definition, modify or alter data. It is here that SOAP can take liberties with the HTTP protocol. SOAP generally use POST and unless one has a good long look at the SOAP envelope, security apprehensions can't be put to rest. Since looking into SOAP messages is not a feature provided by fire walls, one needs to do extra work to enforce security at this level
REST service support in Oracle
In Oracle AS 10.1.3, you can use the command line Web Services Assembler (WSA) in conjunction with ANT or use JDeveloper (10.1.3) wizards to create and test REST services. The rest of the post describes how to create REST services with JDeveloper.
Creating REST services with JDeveloper
For the purpose of demonstration I shall use a simple class that concatenates one string with another and then publish it as a REST web service. Here is my class:
package com.nebulasky.blogspot;
public class HelloWorld {
public HelloWorld() { }
public String sayHi(String s){
return "Hello "+ s; }
}
Once this you have created the class, go back to the application navigator. Right click the context menu of the source java file and click 'Create J2EE web service'. In the second step of the wizard select the checkbox for REST Support (as seen in figure below) in the Java Web Service Wizard.
You can now click 'Finish' to complete creating the serb service. Deploy the service.
Testing the REST Service
You can test the process from the Enterprise Manager console by clicking on the 'Invoke REST POST' or 'Invoke REST GET'
Or you can even create the HTTP request and pass parameters using a query string. In my case it is
http://172.28.0.54:7777/BlogDemo-RESTHelloService-context-root/SayHiServiceSoap12HttpPort/sayHi?s=sankash
You should see something as this
Monday, August 25, 2008
Handling Exceptions: Creating and using fault policies
Back then...and now
Prior to patch 10.1.3.3, we had to write fault handling code for each and every BPEL process we created. This was done at design time, and more often than not there was a great deal of overlap in the fault handling code for different processes. In essence, we merely ended up writing the same code over and over again. Reusability was thus non-existant as far as fault handling was concerned.
The fault-policy file essentially consists of two sections - condition and action. The condition section is based on a faultName. Each condition has an optional test section and a mandatory action section. The test section tests the occurence of a particular fault and upon the test being true(when that fault has indeed occured ) an action is taken which again is defined in the same file. Several actions can be configured for a particular faultName.
Prior to patch 10.1.3.3, we had to write fault handling code for each and every BPEL process we created. This was done at design time, and more often than not there was a great deal of overlap in the fault handling code for different processes. In essence, we merely ended up writing the same code over and over again. Reusability was thus non-existant as far as fault handling was concerned.
With the 10.1.3.3 patch things have turned over a new leaf. Now, you have the option of creating fault policies(fault handling) that can be applied to an entire domain. Besides, you can bind these policies to a BPEL process at different levels - partnerlink,port type, process and domain. The framework will use the binding in order of the following priority :
- bpel.xml
- policy defined on the server
The reader must note that a fault policy defined on the server will always takes precedence over one that is defined in the BPEL process(catch/catchall blocks), if at all one exists.
Designing a fault policy
A fault policy file defines fault conditions and their corresponding faultrecovery actions. Each fault condition specifies a particular fault or group of faults, which it attempts to handle, and the corresponding action for it. A set of actions is identified by an ID in the fault policy file. Please bear in mind that you can have only one fault-policy for a domain and it must be under SOA_ORACLE_HOME\bpel\domains\domain_name\config\fault-policies. You need to create the fault-policies directory under config as it does not exist by default.
The fault-policy file essentially consists of two sections - condition and action. The condition section is based on a faultName. Each condition has an optional test section and a mandatory action section. The test section tests the occurence of a particular fault and upon the test being true(when that fault has indeed occured ) an action is taken which again is defined in the same file. Several actions can be configured for a particular faultName.
For the purpose of demonstration I have created a fault-policy file which is as follows:
<?xml version="1.0" encoding="UTF-8"?><faultPolicy version="2.0.1" id="SankashPolicy" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<condition>
<action ref="ora-retry"/>
</condition>
<condition>
<action ref="ora-terminate"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>2</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
</retry>
</Action>
<Action id="ora-terminate">
<abort/>
</Action>
</Actions>
</faultPolicy>
If you scroll down to the conditions section you will notice that I am testing for remotefault. If a remoteFault does occur, my remedial action is to retry the connection twice at an interval of 2 seconds. If that does not yeild any result, the final action is terminate the process altogether.
Associating a fault policy
Associating a fault policy
Now that we are done with creating the fault policy, we will see how to bind the policy with a process. As already mentioned the binding can occur at partnerlink, port type, process and domain level. To associate a policy at the process level you need to create the bindings in the bpel.xml file. However, if you want it at the domain level you need to specify the bindings in the fault-bindings.xml under SOA_ORACLE_HOME\bpel\domains\domain_name\config directory. Whichever association you want, the bindings are defined as follows:
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<process faultPolicy="SankashPolicy"/>
<partnerLink faultPolicy="SankashPolicy"/>
</faultPolicyBindings>
In order that the BPEL process manager picks up the policy you created just now, restart the server.
Use case
Use case
To ascertain that the policy is indeed active, create a synchronous BPEL process(wihtout any catch/catchall) that simply calls a java web service. Compile and deploy it. Verify that it executes successfully. Now log in to the enterprise manager console and undeploy the web service that the process was calling. Now, again initiate the process. Open the Activity Audit Trail for the instance. Observe that the process gets terminated. See screenshot below.
Remember nowhere in the process we had written code to terminate it upon the occurence of a remote fault. Evidently, the policy must have caused it to do so.
Friday, August 22, 2008
Handling database package migrations in BPEL
The catch
Recently while working on an integration project for a client, I was told that the custom database packages my BPEL process was referencing needed to be moved to a different database schema. Migration of the packages was promptly done. All that remained was tweaking the BPEL process so that it referenced the packages under the new schema. Since I had used server-side JNDI, my first impression was resetting the data source to the new schema would do the trick. As it turned out, that was not the only thing I needed to do, but a few more.
Recofigure the run-time connection
The first step is to reset the data source so that it points to the new schema. This is fairly easy. Since every data source is tied to a connection pool, it is in essence the connection pool that needs to be changed. To do that, first, log on to the enterprise manager and then modify the existing connection pool by resetting the jdbc url, user name and password. Save the changes. If you insist on creating a new connection pool altogether for better readability, by all means do so. But don't forget to tie it to the data source you are referring to from the JNDI name.
Reset the JCA operation
Go to your BPEL project and open the WSDL files for all the database adapters that were referring to the old schema. Scroll down to the jca:operation tag. You will find something like this:
<jca:operation
SchemaName="APPS"
PackageName="XXALV_BPEL_UTILITY_LIB_PKG" ProcedureName="SUBMIT_JOURNAL_IMPORT" InteractionSpec="oracle.tip.adapter.db.DBStoredProcedureInteractionSpec" > </jca:operation>
Notice that the SchemaName is set to the one you were referring to previously. Reset it to the new schema name. For instance, in my case the new schema is BOLINF. Thus, I will set it as:
...
SchemaName="BOLINF"
...
Leave everything else the same.
Compile and redeploy
You are done. Save the changes and deploy the process. It should now pick up the packages under the new schema.
Gotchas
Most of the time your procedures will call other procedures and functions that may not be under the same schema as your packages are. In such cases your schema will need privileges to perform operations on objects that are outside your schema. Be sure to ask the DBA to grant you the necessary permissions. Also, it is recommended that you qualify all the database objects you create with the schema name so that all references are made explicit.
Recently while working on an integration project for a client, I was told that the custom database packages my BPEL process was referencing needed to be moved to a different database schema. Migration of the packages was promptly done. All that remained was tweaking the BPEL process so that it referenced the packages under the new schema. Since I had used server-side JNDI, my first impression was resetting the data source to the new schema would do the trick. As it turned out, that was not the only thing I needed to do, but a few more.
Recofigure the run-time connection
The first step is to reset the data source so that it points to the new schema. This is fairly easy. Since every data source is tied to a connection pool, it is in essence the connection pool that needs to be changed. To do that, first, log on to the enterprise manager and then modify the existing connection pool by resetting the jdbc url, user name and password. Save the changes. If you insist on creating a new connection pool altogether for better readability, by all means do so. But don't forget to tie it to the data source you are referring to from the JNDI name.
Reset the JCA operation
Go to your BPEL project and open the WSDL files for all the database adapters that were referring to the old schema. Scroll down to the jca:operation tag. You will find something like this:
<jca:operation
SchemaName="APPS"
PackageName="XXALV_BPEL_UTILITY_LIB_PKG" ProcedureName="SUBMIT_JOURNAL_IMPORT" InteractionSpec="oracle.tip.adapter.db.DBStoredProcedureInteractionSpec" > </jca:operation>
Notice that the SchemaName is set to the one you were referring to previously. Reset it to the new schema name. For instance, in my case the new schema is BOLINF. Thus, I will set it as:
...
SchemaName="BOLINF"
...
Leave everything else the same.
Compile and redeploy
You are done. Save the changes and deploy the process. It should now pick up the packages under the new schema.
Gotchas
Most of the time your procedures will call other procedures and functions that may not be under the same schema as your packages are. In such cases your schema will need privileges to perform operations on objects that are outside your schema. Be sure to ask the DBA to grant you the necessary permissions. Also, it is recommended that you qualify all the database objects you create with the schema name so that all references are made explicit.
Subscribe to:
Posts (Atom)