SOAP Binding - RPC Style vs Document style

	RPC Literal (Wrapped)	Document Literal	Document Wrapped
Request Message	The operation name appears immediately after the soap:body. The operation name is specified by the binding:operation element in the binding section of the WSDL. The name attribute of the message:part follows immediately. It is not qualified by a namespace Thereafter the names of the elements in the types section of the WSDL are specified.	The operation name is not specified in the request. The value specified by the element attribute of message:part is the first line following the soap:body. It is qualified by a namespace. Note that this value of the element attribute is actually the value of the name attribute of the schema element in the types section. Thereafter it is similar to RPC Literal in the way that the names of the elements in the types section of the WSDL are specified.	It is similar to "Document Literal Bare" style with one exception => the value of the "element" attribute in the message:part is defined to be the name of the operation. Therefore the name of the operation is part of the request. The operation name appears immediately after the soap:body. Thereafter it is similar to RPC Literal.
WS-I BP 1.1 Compliance	It is WS-I BP 1.1 compliant even though there are many parts in the input message. This is because the first element after the soap:body is the name of the operation and that encapsulates it all.	Since it can have multiple parts immediately following the soap:body, it is not WS-I BP 1.1 compliant. Therefore to make it compliant, a wrapper needs to be defined and this implies that the web method can only have one argument. You could circumvent this requirement by defining the arguments to be part of the SOAP header instead of the body.	It is WS-I BP 1.1 compliant.
WSDL	There could be many parts in the input message. The parts are always specified with a "type" attribute.	There could be many parts in the input message The parts are always specified with an "element" attribute	There is only one part in the input message. The part is always specified by an "element" attribute. This part is the entire message payload and is completely defined in the types section.

OSB – Publishing to Oracle WebLogic Server v10.3 at localhost…”. requested array is larger than heap

An internal error occurred during : “Publishing to Oracle WebLogic Server v10.3 at localhost…”. requested array is larger than heap

Solution: Goto C:\bea\user_projects\workspaces\default\.metadata\.plugins\org.eclipse.wst.server.core\publish  location

And delete the .bat files starting with publish*.bat e.g: publish0.bat, publish1.bat etc. After deleting try to publish application. This should solve ur problem. Even after doing this if the problem persists then delete the server domain and create new domain.

SOAP VS REST Web Service

SOAP – Simple Object Access Protocol

1. Exposes Operations that implement/represent logic
2. Provides loose coupling for integrating diverse systems
3. Designed for distributed systems.
4. Designed to be extensible – WS-*
5. Standard error messaging – SOAP faults with standard code/ subcode for error types
6. Aligns with enterprise application needs and goals.

• Supports other transport protocols than HTTP – SMTP, JMS
• Supports enterprise security with WS-Security.
• Supports language neutrality
• Supports ACID, Atomic transactions with WS-AT
• Support Reliable Messaging with WS-RM
• Easy governance with strong typing.
• Broad development tool support

REST

- Good for Web service

- Exposes RESOURCES which represent data

- Uses HTTP verbs (GET / POST / PUT / DELETE)

- Emphasis on simple point – to – point communication over HTTP

- Supports multiple data formats

- Emphasizes stateless communication

SOAP

- Good for Enterprise services

- Exposes OPERATIONS which represent LOGIC

- Uses HTTP POST

- Emphasis on loosely coupled distributed messaging.

- Supports only XML and attachments

- Supports stateless and stateful / conversational  operations

- Supports asynchronous messaging

- String Typing

Why Rest is better than SOAP:

- REST can be consumed by any client, even a web browser with Ajax and javascript

- REST is light weight. 1 - Rest doesn’t require XML parsing.   2 - Rest consumes less bandwidth – doesn’t require a SOAP header for every message

- Can learn to use REST very easily.It’s just nouns and verbs

Why SOAP is better than REST:

- Building a client for REST can be challenging and difficult and building client for SOAP will be easy

- I can easily generate client-side artifacts from a WSDL

- I don’t want to write raw http calls

- I don’t want to look at the http response code for success/failure

- REST only supports HTTP/HTTPS

- HTTP is synchronous and in order to scale I need to be able to have asynchronous messaging.

- REST is not secure

- Parameters are part of URL

- No support for acquiring token

- RESTful services have no contract

- Have a WADL that specifies URL’s but not schema for object definition