KeepResident plugin for Eclipse/Jdeveloper

Jdeveloper being slow when shifting the application in windows. Reason being the windows swapping the jdeveloper memory even when large amount of physical memory is available.Application has a working set size. The default value is much too small for big Java applications like Eclipse. Hence, windows does a swapping. To prevent this, one thing that can be done is to increase the minimum water mark of this working set size. Then, there is another problem that when the user memory is less than the minimum working set size, windows will think that the application is not used and will do swapping again. Using VirtualLock() will prevent this and force Windows to keep Eclipse in memory.

Got this information from the blog : http://www.orablogs.com/gdavison/archives/001659.html

FAQ on this plugin also provides a clear information : http://suif.stanford.edu/pub/keepresident/faq.html

SOA Suite - Developer Preview

SOA Suite developer preview is available from : http://www.oracle.com/technology/software/products/ias/soapreview.html

Documentation for SOA, ESB, BPEL available from : http://download-east.oracle.com/otn_hosted_doc/soa/docs/index.htm

WSIF Notes

1. The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web services, no matter how or where the services are provided.


2. WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model.


3. WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.


4. The separation of the API from the actual protocol also means you have flexibility - you can switch protocols, location, etc. without having to even recompile your client code.


5. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service.


6. You can exploit WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.


7. In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software's functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.


8. The WSIF API allows clients to invoke services focusing on the abstract service description - the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols.


9. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.


10. The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols, etc.


11. WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.


12. A provider is a piece of code that supports a WSDL extension and allows invocation of the service through that particular implementation. WSIF providers use the J2SE JAR service provider specification making them discoverable at runtime.


13. Some bindings for which provider is available : java, ejb, jms, jca

WSDL Notes from W3C Spec

1. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.


2. Elements in WSDL:
   
   
   
   1. Types - a container for data type definitions using some type system (such as XSD).
   
   
   2. Message – an abstract, typed definition of the data being communicated.
   
   
   3. Operation – an abstract description of an action supported by the service.
   
   
   4. Port Type – an abstract set of operations supported by one or more endpoints.
   
   
   5. Binding – a concrete protocol and data format specification for a particular port type.
   
   
   6. Port – a single endpoint defined as a combination of a binding and a network address.
   
   
   7. Service – a collection of related endpoints.
   
   
   
   


3. WSDL doesn't introduce a type definition language. Supports XSD as canonical type system. Allows using other type definition languages via extensibility.


4. Binding mechanism is used to attach a specific protocol or data format or structure to an abstract message or operation or end point.


5. It introduces specific binding extensions for the following protocols and message format : SOAP 1.1, HTTP GET/POST, MIME. Other binding extensions can also be used.


6. Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format.


7. WSDL has four transmission primitives that an endpoint can support:
   
   
   
   1. One-Way:endpoint receives a message.
   
   
   2. Request-Response:endpoint receives a message, and sends a correlated message.
   
   
   3. Solicit-Response :endpoint sends a message, and receives a correlated message.
   
   
   4. Notification : endpoint sends a message.
   
   
   
   


8. There may be any number of binding for a port type. A Binding must specify exactly one protocol. Binding must not specify address information.


9. A port must not specify more than one address. It must not specify any binding information other than address information.


10. Ports within service have the following relationship:
    
    
    
    1. None of the ports communicate with each other (e.g. the output of one port is not the input of another).
    
    
    2. If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).
    
    
    
    


11. SOAP Binding extends WSDL with the following extension elements:
    
    
    
    1. soap:binding - Signify that the binding is bound to the SOAP protocol format: Envelop, header and body. URI for the transport attribute of this element signifies which transport of SOAP. Can be HTTP, SMTP, FTP etc.,
    
    
    2. soap:operation - Required for the HTTP protocol binding of SOAP. For other SOAP protocol bindings, soap:action attribute must not be specified and this attribute may be omitted.
    
    
    3. soap:body - specifies how message parts appear inside soap body element. May be abstract schema defintiions or concrete. If abstract, then serialized according to some encoding style. The soap:body element is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Body section is structured:
       
       
       
       1. If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body
       
       
       2. If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element.
       
       
       
       
    
    
    4. soap:address - The SOAP address binding is used to give a port an address (a URI). The URI scheme specified for the address must correspond to the transport specified by the soap:binding.
    
    
    
    

SOAP Message Embedded in HTTP Request

POST /StockQuote HTTP/1.1 
Host: www.stockquoteserver.com 
Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
SOAPAction: "Some-URI"  

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org

/soap/envelope/"> 
    <soapenv:Body> 
        <m:GetLastTradePrice xmlns:m="Some-URI"> 
            <m:tickerSymbol>DIS</m:tickerSymbol> 
        </m:GetLastTradePrice> 
    </soapenv:Body> 
</soapenv:Envelope>

SOAP Message Embedded in HTTP Response

HTTP/1.1 200 OK 
Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn  

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org

/soap/envelope/"> 
    <soapenv:Body> 
        <m:GetLastTradePriceResponse xmlns:m="Some-URI"> 
            <m:price>34.5</m:price> 
        </m:GetLastTradePriceResponse> 
    </soapenv:Body> 
</soapenv:Envelope>

Accessing class in another class

1.using packaged class in non-packaged or packaged class: Need to use import.

2.using non-packaged class in non-package class : can be present in same directory. Else if different directory, should be available from classpath. No need(and can't) to use import.

3.using non-packaged class in packaged class: not possible at all(since the non-packaged class name mentioned in packaged class will be interpreted as belonging to the pacakged class's package and so the compiler will take this class as package.class and so will report wrong class file.