Monday, November 21, 2011

WS-RM enabling a Web Service Client on Jboss

This post is about configuring a web application that acts as a web service client deployed on Jboss 5.1.0 GA .

The reason for preparing this post is that altough parts of this information exist in various forums and in the CXF documentation, we were unable to find a single place to summarize all necessary steps so far.

The actual web service is another application running on a Weblogic 10.3 cluster. The main WS-RM related characteristics are directly encoded in the WSDL:

 1. A policy has been defined to specify the related WS-RM characteristics:

       <wsp:Policy wsu:Id="wsrm10policy">

              <wsp:ExactlyOne>

                     <wsp:All>

                           <wsam:Addressing>

                                  <wsp:Policy />

                           </wsam:Addressing>

                           <wsrmp:RMAssertion xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">

                                  <wsrmp:BaseRetransmissionInterval

                                         Milliseconds="4000" />

                                  <wsrmp:DeliveryAssurance>

                                         <wsp:Policy>

                                                <wsp:All>

                                                       <wsrmp:ExactlyOnce />

                                                       <wsrmp:InOrder />

                                                </wsp:All>

                                         </wsp:Policy>

                                  </wsrmp:DeliveryAssurance>

                           </wsrmp:RMAssertion>

                     </wsp:All>

              </wsp:ExactlyOne>

       </wsp:Policy>

2. The policy is referenced in the binding of our Web Service:

<wsdl:binding name="AsyncDeliveryRMServiceSoapBinding" type="tns:AsyncDeliveryRMServicePortType">

              <wsp:PolicyReference URI='#wsrm10policy' />

              . . . . . .

       </wsdl:binding>

The focus of this post is on the client side (Jboss). The following steps outline the WS-RM specific configuration:

  • Use the server WSDL to generate the required artifacts (Web Service interface, etc.) using wsdl2java.
  • Configure a  jaxws:client and a decoupled endpoint to receive WS-RM responses:
  • <jaxws:client id="asyncRMClient"

                xmlns:h="http://namespace.my/"

                serviceClass="my.namespace. AsyncDeliveryRMServicePortType"

                serviceName="h:AsyncDeliveryRMService"

                endpointName="h:AsyncDeliveryRMServicePort"

                wsdlLocation="http://192.168.56.120/wsserver/AsyncDeliveryRMService?wsdl"

                >

           . . . . .

    </jaxws:client>

     

    <http:conduit name="{http://namespace.my/}AsyncDeliveryRMServicePort.http-conduit">

                  <http:client DecoupledEndpoint="http://192.168.56.1:9990/decoupled_endpoint"/>

    </http:conduit>


  • Add the following dependencies in the pom.xml of the Maven project (notice the inclusion of cxf-rt-transports-http-jetty as it is necessary for the decoupled endpoint to be created) :

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-frontend-jaxws</artifactId>

            <version>${cxf.version}</version>

        </dependency>

 

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-transports-http</artifactId>

            <version>${cxf.version}</version>

        </dependency>

 

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-ws-rm</artifactId>

            <version>${cxf.version}</version>

        </dependency>

 

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-ws-addr</artifactId>

            <version>${cxf.version}</version>

        </dependency>

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-ws-policy</artifactId>

            <version>${cxf.version}</version>

        </dependency>

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-common-utilities</artifactId>

            <version>${cxf.version}</version>

        </dependency>

 

        <dependency>

            <groupId>org.apache.cxf</groupId>

            <artifactId>cxf-rt-transports-http-jetty</artifactId>

            <version>${cxf.version}</version>

            <exclusions>

                <exclusion>

                    <artifactId>geronimo-servlet_2.5_spec</artifactId>

                    <groupId>org.apache.geronimo.specs</groupId>

                </exclusion>

            </exclusions>

        </dependency>

  • Create a class (RMRequestPoster in our case) to invoke the client configured above and wire this dependency in the Spring configuration:

    <bean

        class="my.sender.RMRequestPoster"

        id="rmRequestPoster">

 

        <property name="rmPort">

            <ref bean="asyncRMClient"/>

        </property>

 

   </bean>

  • Add code to invoke the service:

public class RMRequestPoster {

. . . .

//This is the jaxws:client configured in step 3

private AsyncDeliveryRMServicePortType rmPort;

. . . .

public void postRequest() {

      

//Perform any application specific actions

. . . . .

 

//Invoke a one-way operation on the port

rmPort.postMessage(<required parameters>);

       

. . . . . .

}

       

    }

  • IMPORTANT: Copy jetty.jar and jetty-util.jar under <%JBOSS_HOME%>/server/<your server>/deployers/ jbossws.deployer
  • If the decoupled endpoint must operate behind a proxy, it may be necessary to change the replyTo address in the WS-Addressing headers. An interceptor can be used to achieve this: 

public class ReplyToInterceptor extends AbstractPhaseInterceptor<Message>

{

    public ReplyToInterceptor() {

        super(Phase.PRE_LOGICAL);

        addAfter(MAPAggregator.class.getName());

    }

    @Override

    public void handleMessage(Message message) {

        AddressingProperties maps = ContextUtils.retrieveMAPs(message, false,

           true);

        EndpointReferenceType replyTo = maps.getReplyTo();

        replyTo.getAddress().setValue(

           "http://192.168.56.1:9999/decoupled_endpoint");

    }

}

Friday, March 11, 2011

Περί Προμηθειών Πληροφορικής στο Ελληνικό Δημόσιο

Ξεκίνησα πριν από μερικές ημέρες να κάνω κάποια σχόλια σε post φίλου σχετικά με τις διαδικασίες διενέργειας διαγωνισμών για προμήθειες στο χώρο της Πληροφορικής.

Τελικά, τα σχόλια ήταν τόσα που αποφάσισα να το κάνω ένα ξεχωριστό post.

Διατυπώνεται συχνά η άποψη ότι το πλαίσιο διενέργειας προμηθειών είναι «υπερ-ρυθμισμένο». Δική μου άποψη είναι ότι το πλαίσιο διακατέχεται από τη νοοτροπία του στρατού: Ολα απαγορεύονται και όλα επιτρέπονται (αρκεί να μη σε πιάσουν).

Μετά από αρκετά χρόνια εμπλοκής στο χώρο και με διάφορες ιδιότητες (ως προσφέρων,σύμβουλος στη δημιουργία RFP, μέλος επιτροπών παρακολούθησης, project manager) άποψή μου είναι ότι το όλο πλαίσιο παραγωγής αλλά και λειτουργίας συστημάτων Πληροφορικής χρήζει ριζικής αναδιάρθρωσης.

Τα βασικά σημεία αυτής της αναδιάρθρωσης είναι τα εξής:

  1. Θα πρέπει το συντομότερο δυνατό να αποσυνδεθεί η παραγωγή εφαρμογών (business software) από την προμήθεια εξοπλισμού και γενικά στοιχείων υποδομής (δίκτυα, servers, συστήματα αποθήκευσης, κτλ.). Τα τελευταία θα πρέπει να γίνουν αντικείμενο ενός ενιαίου φορέα (π.χ. ένα data center ανά cluster συναφών υπουργείων) ο οποίος και θα διαχειρίζεται τη λειτουργία της υποδομής καθώς και τις σχετικές προμήθειες.
  2. Συμπληρωματικά στο παραπάνω θα πρέπει να σταματήσει η παραγωγή προκηρύξεων-μαμούθ (τα περίφημα ΟΠΣ – Ολοκληρωμένα Πληροφοριακά Συστήματα). Αυτό που κάνει ένα σύστημα του Δημοσίου ολοκληρωμένο δεν είναι η ένταξη σε ένα έργο διαφορετικών λειτουργιών άσχετων μεταξύ τους αλλά η κάλυψη στοχευμένων αναγκών με τρόπο που εξυπηρετεί όλους τους εμπλεκόμενους (υπαλλήλους, πολίτες, Κεντρική και Περιφερειακή Διοίκηση).
  3. Οσον αφορά τις προμήθειες υπηρεσιών ανάπτυξης συστημάτων (software), αυτές θα πρέπει να οργανωθούν σε διαφορετική βάση. Πιό συγκεκριμένα:
    1. Θα πρέπει να εισαχθεί η έννοια των προγραμματικών συμβάσεων (ή συμβάσεων-πλαίσιο μιάς και ο όρος «προγραμματικές» παραπέμπει σε αμαρτωλές εποχές). Με βάση αυτές θα μπορούσε ένα cluster συναφών υπουργείων και εποπτευόμενων φορέων να διενεργήσει σχετικους διαγωνισμούς και να συνάψει συμβάσεις με περισσότερες της μιάς εταιρείες και στις οποίες στη συνέχεια θα μπορεί να αναθέτει συγκεκριμένα έργα μικρής ή μεσαίας κλίμακας με βάση τη σειρά κατάταξης των εταιρειών στο σχετικό διαγωνισμό. Κατά την εκτίμησή μας αυτά τα έργα είναι και η πλειοψηφία και βασική προϋπόθεση για να πετύχει το σχήμα αυτό είναι η παραγωγή μελετών όπως περιγράφεται παρακάτω.
    2. Επιμέρους Διαγωνισμοί (εκτός των προγραμματικών συμβάσεων που αναφέρθηκαν πιό πάνω) θα πρέπει να γίνονται μόνο για έργα μεγάλης κλίμακας ή εξαιρετικά εξειδικευμένου αντικειμένου.
  4. Οι μελέτες και ο τρόπος που γίνονται είναι, κατά τη γνώμη μου το σημείο κλειδί για τον εξορθολογισμό του συστήματος προμηθειών. Για να λειτουργήσει το πλαίσιο που περιγράφηκε πιό πάνω, θα πρέπει οι μελέτες να καλύπτουν τις φάσεις του έργου μέχρι και τις λειτουργικές προδιαγραφές (functional specifications). Θα πρέπει δηλαδή, όταν κάποιος αναλαμβάνει να παράξει το software να έχει στη διάθεσή του, κατ'ελάχιστο, την σαφή περιγραφή των επιχειρησιακών διαδικασιών (business processes) που θα καλύψει, των κανόνων που τις διέπουν (business rules) καθώς και των διεπαφών (interfaces) που πρέπει να αναπτυχθούν τόσο ως προς τους διάφορους εμπλεκόμενους χρήστες όσο και με άλλα συστήματα.

    Στην πλειοψηφία των περιπτώσεων σήμερα είναι αδύνατο να καταλάβεις από τα περιεχόμενα της προκήρυξης τι ακριβώς είναι αυτό που πρέπει να υλοποιήσεις (εκτός αν έχεις εσωτερική πληροφόρηση) και επομένως είναι αδύνατο ακόμη και στα αρχικά στάδια του έργου να κοστολογήσεις και να οργανώσεις την προσπάθεια που απαιτείται για να ολοκληρωθεί το έργο. Η αιτία που αυτό δεν γίνεται σήμερα είναι σαφής: Οι μελετητές σήμερα δεν καλούνται για να παράξουν προδιαγραφές αλλά να επιτελέσουν το ρόλο του μεσάζοντα ανάμεσα σε στελέχη του οργανισμού που ενδιαφέρεται για το έργο, της αγοράς (μπορεί κανείς να βάλει άφθονα εισαγωγικά εδώ) και της Διοίκησης. Αυτό πρέπει να «σπάσει».

  5. Αφού με τα παραπάνω ουσιαστικά αλλάζει το πλάισιο προμηθειών θα πρέπει να αλλάξει ριζικά και ο τρόπος που γίνεται η Διαχείριση των έργων (Project Management). Σήμερα μεγάλο μέρος της περνάει από την Κοινωνία της Πληροφορίας η οποία όμως (αυτή είναι η αίσθησή μου) πελαγοδρομεί μεταξύ γραφειοκρατίας, ελλειπούς κατανόησης των αναγκών και συνεργασίας με τους εμπλεκόμενους. Κατά τη γνώμη μου ένα αντίστοιχο (ή ακόμα και το ίδιο) σχήμα πρέπει να διατηρηθεί. Θα πρέπει όμως και να αναμορφωθεί και να στελεχωθεί διαφορετικά:
    1. Να διαχωρισθεί η διαχείριση των συμβατικών θεμάτων (contract management) από την τεχνική διαχείριση του έργου. Οι ανάγκες αλλά και οι εμπλεκόμενοι σε κάθε μιά από αυτές τις δραστηριότητες διαφέρουν.
    2. Ειδικά για τη διαχείριση του φυσικού αντικειμένου (προδιαγραφές και υλοποίηση) πρέπει να χρησιμοποιούνται άνθρωποι με αποδεδειγμένη εμπειρία που να μπορούν να κατανοούν τις ανάγκες ενός έργου και ταυτόχρονα να κατανοούν τις επιδιώξεις των εμπλεκομένων (και ό νοών νοείτω).

Κατανοώ ότι τα παραπάνω δεν είναι ούτε ολοκληρωμένα και επιδέχονται προσθηκών, βελτιώσεων, κτλ. Σε κάθε περίπτωση, this is my truth. Tell me yours.

 

Κ.