SCDJWS 5, web service design patterns notes

Web Service Design Patterns

The
design patterns related to Web Service help to enhance
maintainability of the solution or to minimize QoS impact associated
with building applications using web service frameworks. Web Services
based interaction might be expensive because of

• operation
  is expensive in term of server-side processing
• communication
  overhead (amount of data transfer/bandwidth)
• encoding/decoding
  may be expensive

Application
designers should look for alternatives in this situation.

Asynchronous Interaction Pattern

Goals
of this pattern are:

• decouple
  input and output.
• deliver
  output from server to client.
• Associate
  output message with corresponding input message

This
can be achieved with various application level designs to achieve the
above goals which are Server-side push, Client-side pull. JMS-based
and JAX-WS based which are described below.

Server-side
push

Approach
1: Client supplies the address of a web service dedicated to
process specific response to the request, as part of request and the
server contacts the dedicated web service to reply to the query back
to the client.

Approach
2: Client supplies address of a generic web service that can be
invoked to supply the result of operation back to client, along with
unique token to identify this request, The server later invokes this
generic web service to deliver an answer to this client the server
uses the same token as part of response message to identify the
response to client. WS-Addressing defines a way to create these
tokens portably.

Client-side
pull

Client
issues a request along with a unique token to server, the server
accepts the request, allowing client to continue processing. server
process each request to obtain response and stores all responses
indexed by tokens supplied by client in each request in a data
structure accessible as a new Response web service. Each client
queries the new web service for answer to earlier requests using the
same token. Enough storage required on server side to store all
response, until the client retrieves it. For reliability the storage
might need to be persistence. Increases network overhead as client
may poll periodically for it's response.

JMS
based

Non-portable
web service solution, uses JMS as message transport instead of HTTP.
Both Client-side pull and Server-side push can be implemented using
JMS. In case of Client-side pull the client uses multiple requests
first being a JMS message and the subsequent ones being synchronous
and portable.

JAX-WS
based

JAX-WS
introduces Dispatch<T> and Provider<T> interfaces to
describe client and server side of the interaction. On client side it
introduced the ability to indicate whether the interaction is
synchronous or asynchronous, whether it's Client-side pull or
Server-side push or one way.

interface
Dispatch<T>{ // client-side
 
T invoke(T
msg);
 
Response<T>
invokeAsync(T msg);
 
Future<?>
invokeAsync(T msg, AsyncHandler<T> h);
 
void
invikeOneWay(T msg);

}



interface
Provider<T>{ // server-side
 
T invoke(T msg,
Map<String, Object> context);
}

Example

MessagingAPIMessage
request = new MessagingAPIMessage( "sayHello", "Tracy"
);

MessagingAPIMessage
response = MessagingAPIMessage) port.invoke( request );

System.out.println("Response:
" + response.getResult());

AsyncHandler<Object>
responseHandler = new AsyncHandler<Object>() {
 
public void
handleResponse(Response<Object> resp){
  
try {
    
MessagingAPIMessage
result = (MessagingAPIMessage) response.get();
   
  System.out.println(
"Response: " + result.getResult() );
  
} catch(
Exception e ) {  
}
 
}
};
port.invokeAsync(
request, responseHandler );

Advantages:
More responsive application, JAX-WS provides transparent
implementation
Disadvantages: Other
than JAX-WS requires more complex designs

JMS Bridge

The
Characteristics of JMS Bridge pattern are as follow:

• Keep
  different subsystems using their own JMS implementation
• Introduce
  a client which can relay messages from one JMS implementation to
  next
• the
  JMS clients should be implemented as Web Services

Advantages:
No need to develop vendor specific to bridge two underlying
middle-ware vendor. It's vendor and JMS independent.
Disadvantage:
Overhead XML encoding/transmission and decoding

Web Service Cache

Cache
can be introduced at two places which will be transparent to client
(as Endpoint Handlers). The overhead is reduced by short-circuiting
requests that do not need to be executed.

Advantages:
Reduce communication and processing overhead
Disadvantage:
Increased memory
footprint, application must realize when to invalidate or refresh
cache.

Web Service Broker

Can
be used implement some services as Web Service and still address the
concerns that web services don't address like transaction
propagation. Web Service broker is introduced as a middle-man between
the client and the remote service in which the client is interested.
Can be implemented as a state-full session bean.

Advantage:
Simpler client design
Disadvantage:
Complex to implement (not guaranteed)

Web Service Logger

A
common approach to introduce logging into the design of an
application involves the application of Decorator pattern as follows:

• 
  An additional object is
  introduced as a wrapper around the actual service provider.
• The logging functionality is
  captured in the wrapper.

SQLalchemy tweak

If you've been ripping your hair off trying to figure out the "BoundMetaData is not defined" error in SQLAlchemy, the answer is to switch "BoundMetaData" with simply "MetaData", as the first one appears to have been deprecated. The Python code should look like this:

from sqlalchemy import *<br /><br />db = create_engine('sqlite:///MyDb.db')<br />metadata = MetaData(db)<br />

Useful SQLAlchemy links:
http://www.rmunn.com/sqlalchemy-tutorial/tutorial.html
http://www.sqlalchemy.org/docs/05/ormtutorial.html

basic xml-rpc communication between a python server and c# client

Setting up the python server

import calendar, SimpleXMLRPCServer

#The server object
class Calendar:
    def getMonth(self, year, month):
        return calendar.month(year, month)

    def getYear(self, year):
        return calendar.calendar(year)


calendar_object = Calendar()
server = SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost", 8888))
server.register_instance(calendar_object)

#Go into the main listener loop
print "Listening on port 8888"
server.serve_forever()


Setting up the C# client

1. Download the helping DLL's from http://xml-rpc.net/
2. Create a proxy interface: 


using System;
using CookComputing.XmlRpc;

namespace XMLRPCclient
{
   
    [XmlRpcUrl("http://127.0.0.1:8888/")]       
    public interface IClientCalendarProxy : IXmlRpcProxy
    {
        [XmlRpcMethod("getMonth")]
        string getMonth(int p1, int p2);

    }
}


3. Init & run your client using the upper defined proxy interface (make sure the URL points to the port of the web service)

using System;
using CookComputing.XmlRpc;

namespace XMLRPCclient
{

    class MainClass
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
           
           

            IClientCalendarProxy proxy = XmlRpcProxyGen.Create<IClientCalendarProxy>();


            string ret = proxy.getMonth(2002,8);
            Console.WriteLine(ret);

        }
    }
}



Useful links:

• Start your exploration of XML-RPC on the official home page. The specification is also a very easy read.
• For reference, use the official Python docs for the XML-RPC client and server modules.
• Browse Useful Information Company's XML-RPC page for more sample XML-RPC services.
• If you plan to do significant work using the protocol, do read and bookmark Eric Kidd's XML-RPC HOWTO.
• Read Using XML-RPC for Web services: Getting started with XML-RPC in Perl, by Joe Johnston for an introduction to XML-RPC, and the follow-up XML-RPC Middleware.
  

[windows] deleting winrar temporary data

If you've ever been in the situation where you have to unzip a large archive and you cancel the unzipping process midway, you will find that upon cancellation, the temporary winrar files will not be erased so you will find yourself losing 6,7 Gb of space just like that. To fix this, go to "Run" and type %temp% - this is the temporary folder on your computer, so just go on and delete all the unused stale data (such as winrar temporary files).

Many-To-Many self reference in Java Persistence API

    Think of the following scenario: you need a many-to-many relationship between a table and itself... how can you accomplish that with JPA annotations ?
    Suppose we have a table Tasks in the database which is mapped to an Entity named Task. A task entry should have a list of parent tasks (prerequisite tasks if you want) and a list of child tasks (tasks which upon the current task's completion would enable them to start). The Task entity class would look a little something like this:

@Entity
@Table (name = "Tasks" , schema = "ProjectManagement" )
public class Task implements Serializable {

// Mandatory @Id PK field

//constructors (including a no-arg constructor)

//fields

// getters and setters


@ManyToMany
@JoinTable ( name = "parent_child_task" ,
                    joinColumns = @JoinColumn ( name = "child_id" , referencedColumnName = "id" ),
                    inverseJoinColumns = @JoinColumn ( name = "parent_id" , referencedColumnName = "id" ))
private List<Task> prerequisiteTasks = new ArrayList<Task>();

@ManyToMany (mappedBy = "prerequisiteTasks" )
private List<Task> childTasks = new ArrayList<Task>();

//.... more

}

Hope this makes sense

Operations allowed in EJB 3.0 session beans

• Operations Allowed in the Methods of a Stateful Session Bean

• Operations Allowed in the Methods of a Stateless Session Bean

SOURCE: EJB 3.0 specification

Bulk Update and Delete Operations in EJB 3.0 JPQL

Bulk update and delete operations apply to entities of a single entity class (together with its subclasses, if any). Only one entity abstract schema type may be specified in the FROM or UPDATE clause.

The syntax of these operations is as follows:
update_statement ::= update_clause [where_clause]
update_clause ::= UPDATE abstract_schema_name [[AS] identification_variable]
                            SET update_item {, update_item}*
update_item ::= [identification_variable.]{state_field | single_valued_association_field} =
                            new_value
new_value ::=
          simple_arithmetic_expression |
          string_primary |
          datetime_primary |
          boolean_primary |
          enum_primary
          simple_entity_expression |
          NULL
delete_statement ::= delete_clause [where_clause]
delete_clause ::= DELETE FROM abstract_schema_name [[AS] identification_variable]

• A delete operation only applies to entities of the specified class and its subclasses. It does not cascade to related entities.
• The new_value specified for an update operation must be compatible in type with the state-field to which it is assigned.
• Bulk update maps directly to a database update operation, bypassing optimistic locking checks. Portable applications must manually update the value of the version column, if desired, and/or manually validate the value of the version column.
• The persistence context is not synchronized with the result of the bulk update or delete.

Caution should be used when executing bulk update or delete operations because they may result in
inconsistencies between the database and the entities in the active persistence context. In general, bulk update and delete operations should only be performed within a separate transaction or at the beginning of a transaction (before entities have been accessed whose state might be affected by such operations).

SOURCE: EJB 3.0 Persistence Specification, pages 104-105