Abstract WSDL vs Concrete WSDL

In recent times, the abstract WSDL terminology is used more than ever and I am seeing more & more coffee-table discussions on this topic. In this post I will make an effort to provide an illustrated explanation in regards to the differences & usage of concrete and abstract WSDL.

First up, abstract WSDL is not a new technology. A typical WSDL (Web Services Description Language) consists of the following sections; types, messages, portType, binding & service elements. A quick look at what each of these sections define will ease the task of clarification of the differences;

Types - Defines the data type definitions for messages that will be exchanged by the web service. Generally defined from a schema (XSD)

Message - Defines the set of actual messages that will be exchanged. A message can consist of one or more parts which is a logical separation which together constitutes the message.

PortType - Defines the abstract operations provided/available and abstract messages involved. Operation refers to the messages involved in the transaction.

Bindings - Defines the message format and protocol information for operations defined by the portType.

Service - Defines the endpoint where the webservice will be exposed

Based on these definitions, we can figure out that the Types, Message & PortType sections of a WSDL definition is abstract (since it has no information pertaining to the communication protocol & how or where the service is exposed) where as the Bindings & Service section is concrete.

Hence, if we have a WSDL which just has these elements (excluding the Bindings & Service sections), then the WSDL is referred to as "Abstract WSDL". This WSDL definition cannot be used to connect to the webservice due to the 'missing information' on where & how the service is exposed. But there are certain advantages with abstract wsdl which we will see in a bit.

Definition of concrete WSDL now becomes a no-brainer. If a WSDL has all the sections - including the concrete parts such as Bindings & Service then it is referred to as a concrete WSDL. This WSDL defnition can be used to connect to the actual service since it has the protocol and service endpoint information.

Now, where exactly do we use an abstract WSDL?

Coming to the world of SOA, I am taking the example of Oracle SOA composites referencing external services. Ever wondered why some SOA composites are in "Invalid State" even though all the services that it references are up & available? This is because of the usage of concrete WSDL reference where the referenced service is not available yet when the caller service composite starts up. There is no way for the server to know about the service dependencies when it starts. By leveraging the concept of the abstract WSDL, we would be able to effectively resolve dependencies both at design time as well as runtime.

BPEL Faults

"Handling Faults" - Like in every other language there are number of mechanisms to handle exceptions that may arise while invoking certain piece of code. In BPEL as well there is a meachanism for handling faults.These faults should be handled and required actions should be taken in event of failure at any stage.There are two categories of BPEL faults:

1. Business Faults
2. Runtime Faults

Business faults are application-specific faults that are generated when there is a problem with the information being processed (for example, when a social security number is not found in the database). A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. The fault name of a business fault is specified by the BPEL process service component.A business fault can be caught with a faultHandler using the faultName and a faultVariable.

<catch faultName="ns2:BusinessFault" faultVariable="BusinessFaultVar">

Runtime faults are the result of problems within the running of the BPEL process service component or web service (for example, data cannot be copied properly because the variable name is incorrect). These faults are not user-defined, and are thrown by the system. They are generated if the process tries to use a value incorrectly, a logic error occurs (such as an endless loop), a Simple Object Access Protocol (SOAP) fault occurs in a SOAP call, an exception is thrown by the server, and so on.

Several runtime faults are automatically provided. These faults are included in the http://schemas.oracle.com/bpel/extension namespace. These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown below defines the messageType:

<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
targetNamespace="http://schemas.oracle.com/bpel/extension"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="RuntimeFaultMessage">
<part name="code" type="xsd:string" />
<part name="summary" type="xsd:string" />
<part name="detail" type="xsd:string" />
</message>
</definitions>

If a faultVariable (of messageType RuntimeFaultMessage) is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.
bindingFault
A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.

remoteFault
A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.

replayFault

A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.

In this example I'll demonstrate how to handle different types of BPEL faults inside any BPEL process and take required actions.BPEL process will be created based on a schema and it will be exposed as web service.To showcase diferent types of faults we will be using primarily two activities such as Throw and Catch.

Throw Activity is used to generates a fault from inside the business process.
Catch Activity is used to catch specific faults indiviually such as business,runtime or binding fault.Catch All activity catches all the faults that are not being catch in other catch activities.



For my tutorial i am using below WSDLs :








Lets start with the tutorial

1. Create a new SOA project with name "FaultHandling".Drag and drop BPEL process onto the components lane.Pop will open up, give BPEL process the name "FaultHandlingProcess" and in tmplate select "Base on a WSDL".



2. Click the cog icon next to WSDL URL to generate WSDL from schema.Create WSDL pop will open up.

3. In the input section, click on "+" icon to add message part.In the next window change the partname to paylaod and click the torch button.


4. Type chooser window will come up.Drill down to Employee.xsd and select "EmployeeDetails" and click OK.


5. Click OK again.


6. BPEL process is configured based on WSDL.Click Finish.


7. Since we have chose the option to expose as web service.Our composite will look like this.


8.Double click and open up the BPEL process.Drag and drop switch activity after receive activity.


9. We will be using this switch activity to throw different faults explicitly.Add a switch case.


10. Under first switch case, add the condition to check for City name "Canada".


11. Similarly for the second switch case do it for "London".


12.Save all.Your BPEL process will look like this so far.


13. Drag and drop throw activity inside first switch case. In this activity we will be throwing Business Fault.


14. Open up your BusinessFault.wsdl and copy namesapce from there "http://xmlns.example.com/service/fault/businessfault".


15. Double click the throw activity and under namespace URI paste the copied namespace and give local name as "BusinessFault".What this activity does is it will throw a business fault and all the details of the fault such as faultcode, details and summary will be stored under "Fault Variable".


16. Create new variable "BusinessFaultVar" of message type as "Business Fault Message".




17. Inside throw activity browse for fault variable that we just created.Click OK.



18. Inside second switch case drag and drop one more throw activity.And for Fault QName click Browse.


19. Window that will pop up, you will see number of system faults that cane be there.Since we are throwing binding fault in this switch case.Select Binding Fault.


20. Like we did for business fault ,similarly create variable for binding fault as well.But this time it should be of "RunTimeFaultmessage" type.
Because binding fault is a part of runtime fault.Its details will be captured using this variable only.





21. Click OK.


22.In the otherwise case configure thorw activity to throw remote fault.




23. Now add 3 catch blocks for the main scope activity,by clicking the "Add Catch branch."


24. Similarly add one catch All activity.


25. Your process will look like this.As explained earlier, we will be using three catch activities to handle business,remote and binding faults indiviually and all other remaining fault that may come will be catch by CatchAll activity.


27. Double click first catch activity.Populate the fields like we did for throw activity.In the first catch we will be catching Binding Fault.




28. Similary catch remote and business fault in other two catch activities.




29. Now we will assign values to these variables that will be used inside catch activities.As we are explicitly throwing faults thats why we are populating these fault variables,otherwise in real case scenario thses will get automatically populated.Drag and drop three assign activiies under each throw activity.


30. In the first assign in case of Business Fault we will populate "BusinessFaultVar".


31. Same for Binding and remote fault.

32. Create a variable of FaultMessage type using FaultSchema.xsd.Now we will assing the fault details such as code, summary to this fault variable just to show how to fetch the fault details in case of any Fault.


33. Drag and drop assign activity under each catch and catchAll activity and map Fault details to the FaultMessage variable.






34. Now our composite will look like this.


35. Save all, compile and deploy it.Open EM and drill down to your SOA Composite.Click on Test Button.First we will check Binding Fault.So enter City name = "Canada" rest other any random details.Test WebService.


37. Open up the flow trace.You will see binding fault being thrown and it is being caught in Catch Binding Fault block.


38. Similarly like this test Business and remote fault as well.

So, in this way you handle faults in any BPEL process. Please note in real case scenarios you dont have to explicitly use throw activity to throw faults such as binding or remote fault.Only use throw activity whenever you want to raise Business exception such as invalid credit card no or negative balance for instance.Binding or remote or any other fault that may raise during execution of code can be catch using catch activity and remaining using CatchAll activity.

RESTful Vs SOAP

Understanding SOAP and REST Basics

Simple Object Access Protocol (SOAP) and REpresentational State Transfer (REST) are two answers to the same question: how to access Web services. The choice initially may seem easy, but at times it can be surprisingly difficult.

SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.

REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.

Before I go any further, it’s important to clarify that both SOAP and REST are protocols: a set of rules for requesting information from a server using a specific technique. The rules are important because without rules, you can’t achieve any level of standardization. The best way to view a protocol is as if it is a diplomat who is making a request on your behalf from another entity. Some people I’ve talked with just don’t understand the entire concept; they have the idea that some sort of magic is occurring. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information.

A Quick Overview of SOAP

SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.

After an initial release, Microsoft submitted SOAP to the Internet Engineering Task Force (IETF) where it was standardized. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a whole laundry list of these standards on Web Services Standards.

The point is that SOAP is highly extensible, but you only use the pieces you need for a particular task. For example, when using a public Web service that’s freely available to everyone, you really don’t have much need for WS-Security.

The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML.

Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.

One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work. The error reporting even provides standardized codes so that it’s possible to automate some error handling tasks in your code.

An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports. In fact, developers in some languages, such as Python, are doing just that.

A Quick Overview of REST

Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.

REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.

Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.

As an example of working with REST, you could create a URL for Weather Underground. The API’s documentation page shows an example URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json. The information you receive in return is a JSON formatted document containing the weather for San Francisco. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.

Deciding Between SOAP and REST

Before you spend hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both. The focus of your decision often centers on which Web service best meets your needs, rather than which protocol to use.

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:
Language, platform, and transport independent (REST requires use of HTTP)
Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
Standardized
Provides significant pre-build extensibility in the form of the WS* standards
Built-in error handling
Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:
No expensive tools require to interact with the Web service
Smaller learning curve
Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
Fast (no extensive processing required)
Closer to other Web technologies in design philosophy

REST	SOAP
Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries	Designed to handle distributed computing environments
Minimal tooling/middleware is necessary. Only HTTP support is required	Requires significant tooling/middleware support
URL typically references the resource being accessed/deleted/updated	The content of the message typically decides the operation e.g. doc-literal services
Not reliable – HTTP DELETE can return OK status even if a resource is not deleted	Reliable
Formal description standards not in widespread use. WSDL 1.2, WADL are candidates.	Well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy
Better suited for point-to-point or where the intermediary does not play a significant role	Well suited for intermediated services
No constraints on the payload	Payload must comply with the SOAP schema
Only the most well established standards apply e.g. HTTP, SSL. No established standards for other aspects.  DELETE and PUT methods often disabled by firewalls, leads to security complexity.	A large number of supporting standards for security, reliability, transactions.
Built-in error handling (faults)	No error handling
Tied to the HTTP transport model	Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP
Less verbose	More verbose

Weblogic Basics

WebLogic Server Instance

             

                A WebLogic Server instance is a Java Virtual Machine (JVM) process that runs the Java code. The

instance is the actively working component, receiving client requests and sending them on to

the appropriate components, and sending the processed requests back to the clients.

Weblogic server instance is combination of admin server + manage server.

Administration Server

            A server is an instance of WebLogic Server that runs in its own JVM, and the Admin Server is a special instance of  WebLogic Server designed for managing the domain rather than running applications. There is a one-to-one relationship between domains and the Admin Server—an Admin Server belonging to Domain A can’t manage Domain B.

            You can deploy applications on the Admin Server, but unless you’re operating in a purely developmental environment, use the Admin Server strictly for performing management tasks, not for deploying any applications. Although you can deploy applications on the Admin Server in a development environment, it’s a best practice not to do so in a production environment

Managed Server

            Managed servers are the workhorses of WebLogic Server. Any additional servers you create after the creation of the default Admin Server are Managed Servers. The Managed Server contacts the Admin Server, only when you start it up, to get the configuration and deployment settings. For this reason, you should always start up the Admin Server before you start a Managed Server. Once a Managed Server starts running, it operates completely independent of the Admin Server.

WebLogic Server Cluster

            A WebLogic Server cluster is a group of WebLogic Server instances consisting of multiple Managed Servers that run simultaneously.

Machine

            A machine in the WebLogic Server context is the logical representation of the computer that hosts one or more WebLogic Server instances (servers).

Node Manager

            Node Managers help you remotely start, stop, suspend, and restart Managed Servers.

Services

            Following are some of the main services used in a WebLogic environment:

■ JDBC (Java Database Connectivity) enables Java programs to handle database

connections established through connection pools.

■JMS (Java Messaging Service) is a standard API that enables applications to communicate

through enterprise messaging systems.

■JTA (Java Transaction API) specifies standard Java interfaces between transaction

managers and the parties in a distributed transaction system.

Development and Production Mode

            By default, WebLogic Server domains run in the development mode using the Sun Java Development Kit (JDK). In this mode, auto-deployment of applications is enabled and the Admin Server creates a boot.properties file automatically when you start it up. You can also use the demo certificates for Secure Sockets Layer (SSL) without any warnings from WebLogic Server. The development mode is provided to get developers up and running quickly without having to worry

about advanced deployment, configuration, or security issues.

In the production mode, WebLogic Server defaults to using JRockit as the default JDK. In addition, you can’t use the auto-deployment feature in production, and WebLogic Server issues warnings if you use the demo certificates for SSL. In the production mode, you’re also prompted for usernames and password when you start up the instances.

It’s easy to toggle between the development and production modes