[BIGNAMI] Design Patterns in Java – Parte 3

§INTERFACE PATTERNS§ – FACADE pattern

La programmazione OO permette di creare toolkits e sottosistemi di carattere generico, che possono poi essere sfruttati da applicazioni legate ad uno specifico dominio.
Tali sottosistemi espongono spesso interfacce complesse e molto diverse fra loro, l’intento del pattern FACADE è di fornire un’interfaccia che renda il sottosistema facile da usare, esponendo una interfaccia più semplice.

Una classe facade può avere tutti metodi statici, in questo caso è chiamata classe utility (in UML).

La classe JOptionPane (javax.swing package) è uno dei pochi esempi di facade contenuto nelle librerie di classi Java:
questa classe semplifica la creazione di un dialog box pop up.

[BIGNAMI] Design Patterns in Java – Parte 2

§INTERFACE PATTERNS§ – ADAPTER Pattern

Un oggetto è un client se ha necessità di chiamare il tuo codice.
Lo scopo del pattern ADAPTER è quello di esporre al cliente una interfaccia a lui nota per sfruttare servizi di classi con differenti interfacce.

Il pattern ADAPTER consente di utilizzare una classe esistente per soddisfare le esigenze di un client.

Se il client specifica i requisiti in un’interfaccia, si sfrutta tale interfaccia per la classe adapter: l’adapter implementerà l’interfaccia nota al client e allo stesso tempo estenderà la classe che contiene i metodi richiesti, ma con diversa signature. Questo approccio crea un class adapter che traduce le chiamate del client in chiamate ai metodi della classe esistente.

Quando il client non specifica l’interfaccia, si può applicare il pattern creando una sottoclasse del client che usa una istanza della classe esistente.
Questo approccio crea un object adapter che inoltra le chiamate a un’istanza della classe client esistente. Questo
approccio può essere pericoloso, soprattutto se non si fa override di tutti i metodi che il cliente potrebbe chiamare.

Esempio

Adapting to an Interface
Una classe client fa chiamate al metodo requiredMethod() che è dichiarato in una interfaccia. In una classe esistente si ha già implementato il metodo usefulMethod(),
che soddisfa le esigenze del client. Si può creare una adapter class creando una nuova classe, NewClass(), che estenda la classe esistente (ExistingClass) e implementi l’interfaccia che il client si aspetta
(RequiredInterface).

class adapter

class adapter

Class and Object Adapters
Quando il client non dichiara i metodi *da adattare* in una interfaccia, si può sfruttare un object adapter: un adapter che usa la delegazione al posto dell’ereditarietà.

object adapter

object adapter

NewClass è un esempio di object adapter.
Un’istanza di questa classe è un’istanza della classe RequiredClass. In altre parole,
la classe NewClass soddisfa le esigenze del cliente. La classe NewClass è in grado di adattarsi alla classe ExistingClass per soddisfare le esigenze del cliente, utilizzando un’istanza di ExistingClass.

[BIGNAMI] Design Patterns in Java – Parte 1

Il libro di riferimento è: Design Patterns in Java(TM) (Software Patterns Series) by Steven John Metsker.

Un pattern è *un modo per fare qualcosa*, una tecnica già sperimentata e consolidata per espletare un dato compito.

In modo analogo, un design pattern è un pattern che usa classi e metodi in un linguaggio object oriented per risolvere problemi noti.
Un pattern rappresenta una idea, non una particolare implementazione.

Si possono classificare i Design Patterns secondo i problemi che risolvono:
1. Interfacce (Interfaces)
2. Responsabilità (Responsibility)
3. Costruttori (Construction)
4. Operazioni (Operations)
5. Estensioni (Extensions)

In particolare:

  • Interfaces
    • ADAPTER
    • FACADE
    • COMPOSITE
    • BRIDGE
  • Responsibility
    • SINGLETON
    • OBSERVER
    • MEDIATOR
    • PROXY
    • CHAIN OF RESPONSIBILITY
    • FLYWEIGHT
  • Construction
    • BUILDER
    • FACTORY METHOD
    • ABSTRACT FACTORY
    • PROTOTYPE
    • MEMENTO
  • Operations
    • TEMPLATE METHOD
    • STATE
    • STRATEGY
    • COMMAND
    • INTERPRETER
  • Extensions
    • DECORATOR
    • ITERATOR
    • VISITOR
§INTERFACE PATTERNS§  – INTRODUZIONE ALLE INTERFACCE

Una interfaccia è una collezioni di metodi e variabili che rappresentano la parte visibile della classe che implementa l’interfaccia: in altra parola una interfaccia si può considerare come
*una dichiarazione di intenti*.

Una classe astratta senza metodi non abstract è simile ad una interfaccia, ma rimangono alcune differenze.
Differenze tra abstract classes e interfacce in Java:
– una classe può implementare più di una interfaccia ma non può estendere più di una classe abstract.
– una classe astratta può anche implementare metodi non astratti, mentre tutti i metodi di una interfaccia sono per forza astratti.
– una classe astratta può dichiarare e usare variabili di istanza, una interfaccia non può farlo, può solo creare constanti final e static.
– una classe astratta può avere diversi tipi di accesso ai metodi: public, protected, private o package (default). Tutti i metodi di una interfaccia sono implicitamente public.
– una classe astratta può definire costruttori, una interfaccia non può farlo.

Problema da risolvere e relativo pattern Interfaces:
– adattare l’interfaccia di una classe per corrispondere all’interfaccia che il cliente di aspetta: ADAPTER
– fornire una interfaccia semplice ad una collezioni di classi: FACADE
– definire una interfaccia che possa essere implementata sia da oggetti individuali sia da gruppi di oggetti: COMPOSITE
– disaccoppiare una astrazione dalla sua implementazione in modo che le due parti possano variare in modo indipendente: BRIDGE

JBoss 7: configurare ascolto su nomehost

Scenario:

Creando web service di test in locale, sono emersi problemi di connessione: il wsdl ritornato dal web service con una invocazione dei tipo http://localhost:8080/Prototipo/ServizioEcho?wsdl definiva l’endpoint come <soap:address location=”http://nomecomputer:8080/Prototipo/ServizioEcho”/&gt;  e questo indirizzo non veniva risolto dal web service client di test.

Problema:

Jboss è in ascolto solo su localhost.

Soluzione:

Occorre modificare il file di configurazione di JBoss ( usato in modalità standalone):

\jboss-as-.1.0.Final\standalone\configuration\standalone.xml aggiungendo altri indirizzi sui quali Jboss “ascolta”.

Le scelte sono 2: settare tutti gli indirizzi (any, equivalente al vecchio -b 0.0.0.0 delle precedenti versioni di JBoss), settare solo lo specifico IP di interesse.

Settare any:

<interfaces>
        <interface name="management">
            <inet-address value="127.0.0.1"/>
        </interface>
        <interface name="public">
            <inet-address value="127.0.0.1"/>
        </interface>

        <!-- IPv4 -->
        <interface name="any">
            <any-ipv4-address/>
        </interface>
    </interfaces>

   <!-- Use the any interface -->
    <socket-binding-group name="standard-sockets" default-interface="any">
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jmx-connector-registry" port="1090"/>
        <socket-binding name="jmx-connector-server" port="1091"/>
        <socket-binding name="jndi" port="1099"/>
        <socket-binding name="osgi-http" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
    </socket-binding-group>

Ora, richiedendo http://nomecomputer:8080/Prototipo/ServizioEcho?wsdl si ottiene correttamente il WDSL.

See more at:
https://docs.jboss.org/author/display/AS7/Interfaces+and+ports
https://community.jboss.org/message/614962
https://community.jboss.org/thread/169889
http://stackoverflow.com/questions/1032554/how-can-i-use-the-hostname-of-the-server-instead-of-localhost-with-jboss

JBoss 7 SOAP Web Service – JAX-WS 2.2 endorset in JDK 1.6

JBoss 7 mette a disposizione JBoss WS come framework per l’implementazione di web service SOAP.

Fra le funzionalità fornite, è possibile creare l’implementazione del web service a partire dal WSDL (approccio Top Down).

Il tool suppone di default suppone la presenza di JAX-WS 2.2. Il problema nasce dall’assenza della implementazione di riferimento di JAX-WS 2.2 all’interno del Jdk 1.6. Per ovviare al problema si può effettuare l’endorset dei jar necessari dentro il jdk.

Esempio:

IDE eclipse Indigo + plug-in JBoss per web service (JBossAS Tools, JBoss WebService Tools, Hibernate Tools, JBoss JAX-RS Tools)

JDK 1.6.x

Generando il web service da WSDL si ottiene un errore di compilazione:

Errore causato dalla mancanza di JAX-WS 2.2 dentro JDK 1.6

Errore causato dalla mancanza di JAX-WS 2.2 dentro JDK 1.6

Si può risolvere il problema effettuando l’endorset del jar della versione 2.2 dentro il JDK:

  • scaricare la RI di JAX-WS 2.2
  • copiare SOLO i due jar  jaxws-api.jar e jaxb-api.jar all’interno della directory del JDK /jre/lib/endorsed.

Ora, utilizzando il wizard, si può creare il web service:

wizard_creazione_ws wizard_creazione_ws_2

 

(se persiste l’errore di compilazione…chiudere e riaprire eclipse…)

See more at:
http://www.bitspedia.com/2012/03/how-to-use-jax-ws-226-with-jdk-16.html
http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
http://jax-ws.java.net/2.2/docs/ReleaseNotes.html