9 Replies Latest reply on Mar 30, 2007 3:10 PM by mauro2

    Seam and RichCliente

    mauro2

      Hi,
      I´m working in a project heare in Brazil that will envolve the entire automation sector from an Province Bank. The first module that is what we are working now will be the new POS, but we will develop the new ATMs solution and the last mile will have an IntraNet solution.
      We are in the first elaboration interaction from the first module(POS) and the
      the Archtecture that we are validatin uses an Jboss Server Application (4.0.5) that will be placed on every unit(Agencia Bancaria) server (since it´s an bank to improve the province economy it has units far from and with not so good links) where we will have the server application that uses EJB3 Statefull and Stateless Session Beans an Mule as ESB (we have links with an Mainframe and xml and texts messages, web services and ....). In this clients we will using an Swing Application that will be up to date using WebStart so we need just Update this units server to replicate this update in all units terminals. This same approach will be used in ATM Application.
      This to Applications nedds to be RichClients becouse it has a deep interaction with hardware (we will use J/XSF to comunicate with they). We will use command patterns and the command handler will comunicate with the sessions beans and its were the questions start:
      I want to know it that is a short path to use SEAMs on client application, since we have JBoss on Servers and in future we will have an AJAX IntraNet stuffs and SEAMS offears some infra instructure, a security module and a stuffs.
      We are implementing the command patterns on client and a command handler that comunicates with sessions beans ... there is way to consume session beans that are seam componetns? Using RMI ?
      We are usin Validation too and since the server are local we will deatach the object and use it on client machine. We are loking Jgodies validation and Binds and maybe integrate this with hibernate validation creating some anottations like @validade and @validateAll to be used on view interface ...

      But the big point is consume SessionBeans that are Seam Components and participatein seams context.

        • 1. Re: Seam and RichCliente
          stu2

          RMI is always an option since you're using EJB. And a major effort in the next release of Seam is to simplify exposing beans as WebServices and allow them to participate in conversations (http://jira.jboss.com/jira/browse/JBSEAM-505).

          • 2. Re: Seam and RichCliente
            mauro2

             

            "stu2" wrote:
            RMI is always an option since you're using EJB. And a major effort in the next release of Seam is to simplify exposing beans as WebServices and allow them to participate in conversations (http://jira.jboss.com/jira/browse/JBSEAM-505).

            You mean that if I consume an Statefull Session beans using jboss client api I will be participating in conversations?

            • 3. Re: Seam and RichCliente
              stu2

               

              "mauro@automaware.com.br" wrote:
              "stu2" wrote:
              RMI is always an option since you're using EJB. And a major effort in the next release of Seam is to simplify exposing beans as WebServices and allow them to participate in conversations (http://jira.jboss.com/jira/browse/JBSEAM-505).

              You mean that if I consume an Statefull Session beans using jboss client api I will be participating in conversations?


              Not sure about how it behaves via RMI - that's one for someone on the Seam team. But there's hope, since the Jira feature above for WS explicitly states that callers will have access to Seam contexts - and conversations are just one of these.

              • 4. Re: Seam and RichCliente
                gavin.king

                There is no good, standards-compliant, way to pass a conversation id transparently over RMI. Even if there was, the semantics are questionable, since conversation state is local, not remotely accessible.

                For WS, the notion of a conversation is better-defined.

                • 5. Re: Seam and RichCliente
                  gavin.king

                  Looking at the original post, I don't really understand the full architecture or the requirements. Are you trying to propagate Seam conversations across the ESB (Mule)? If so, this should be doable once we have Seam/WS, which will include support for JBoss ESB that should be trivial to port to Mule.

                  Or is it something else?

                  • 6. Re: Seam and RichCliente
                    mauro2

                     

                    "gavin.king@jboss.com" wrote:
                    Looking at the original post, I don't really understand the full architecture or the requirements. Are you trying to propagate Seam conversations across the ESB (Mule)? If so, this should be doable once we have Seam/WS, which will include support for JBoss ESB that should be trivial to port to Mule.

                    Or is it something else?

                    the ESB need to integrate with our main-frame with other protocols and the message are not necessarly XML (ISO8582 for example)....and actualy we have an home soluction but 80% of it culd be substituted by mule stuffs ...
                    We has text conversations with our MainFrame to...



                    • 7. Re: Seam and RichCliente
                      mauro2

                       

                      "gavin.king@jboss.com" wrote:
                      There is no good, standards-compliant, way to pass a conversation id transparently over RMI. Even if there was, the semantics are questionable, since conversation state is local, not remotely accessible.

                      For WS, the notion of a conversation is better-defined.


                      I´m a bit confused...
                      What I want to know is if I can use a Statefull Session Beans Seam Component colled remotly by an swing application (via a command handler)...



                      • 8. Re: Seam and RichCliente
                        stu2

                         

                        "mauro@automaware.com.br" wrote:
                        "gavin.king@jboss.com" wrote:
                        There is no good, standards-compliant, way to pass a conversation id transparently over RMI. Even if there was, the semantics are questionable, since conversation state is local, not remotely accessible.

                        For WS, the notion of a conversation is better-defined.


                        I´m a bit confused...
                        What I want to know is if I can use a Statefull Session Beans Seam Component colled remotly by an swing application (via a command handler)...



                        Hmm. Let's back up a bit. Stateful Session Beans are extremely useful in webapps since the main alternative for storing state between requests is generally to use the HttpSession - just a big per-user map. If you're client is a swing app, I would think you'd be fine with Stateless Session beans. Your client is more than capable of storing state on its own.

                        So my question is, given that you have a stateful client to begin with, and that accessing SLSB via RMI is a given, do you really need SFSB access? Seam's SFSB-JBPM integration would be one reason that would still be appealing I guess, but is that what you're after?

                        • 9. Re: Seam and RichCliente
                          mauro2


                          accessing SLSB via RMI is a given

                          SFSB are not?
                          I need SFSB as controllers for long-running conversation...
                          When you have I client in Brazilian Banks you culd add and remove some documents to pay...based on totals and some documents can bt payed with cheks othes not...the total culd be much with taxs tha clientes have in cash...some items culd be added (like bills) some not....
                          The controller for long running conversations like that seam exactly what SFSB are for....
                          And affter all done I submit one block of transactions to be executed....