4 Replies Latest reply on Apr 21, 2005 12:34 PM by infectedrhythms

    Ideas need for a service.

      Am pretty new to writting services and I think I finally have it down on how to create them, but I need some ideas for this one service I want to write and if it's worth writting. So am not sure if I can post this here or not... :D

      For some legacy purposes, I want to write a TCP/IP ServerSocket service and would like to use it with my other services to give them server capabilities...

      1- Should the service create one ServerSocket listening on one port and using some type of handler so the other services can register themselves and using some method to dispatch the incomming messages to the appropriate handler registered for each service?

      2- Should the service create a ServerSocket on request by another service? I see this no different then just importing the ServerSocket classes directly in my services and doing the work there...

      Thanks

        • 1. Re: Ideas need for a service.
          dimitris

          Generally speaking, we choose to model or wrap as MBean Services coarce grain entities.

          In your case you seem to be creating some kind of Adapter for a socket-based protocol. Wrapping the socket into an MBean doesn't seem to offer much value. Wrapping a socket AND the protocol handling may make some sense, but it depends very much on the dynamic behaviour of your network protocol and your overall design.

          For example, does the network protocol involve just listening to events, translating them and do something with them? Do you want to have many message handlers per message? Do you want message processing to be synchronous or asynchronous. Do you need to send back replies to those clients?

          Answering those question will let you decide how best to design your MBean Services.

          • 2. Re: Ideas need for a service.

            ok bassically this how my current "services" work. The ones I want to port.

            On start up, they create a listening server on a specified port. Once they receive a connection they spawn a thread, read the incomming data and take some action and then respond back.

            So every service that runs, will create it's own server on a specified port.

            So I was thinking if I port 2-3 of these services and maybe more, to maybe have them share that one server. This way I can standarize the protocol used by all of them. It's a very crewd RPC.

            Question is if I create a service that creates one server how would I forward the incomming data to the appropriate service and how would each service respond back to the client?

            Thanks

            • 3. Re: Ideas need for a service.
              leonardosalvatore

              I suggest you to assign a JMSqueue/topic to a service.
              Send message (Byte or Object ...) is very easy and for receiving you can implemente a message listener or use a Message Driven Bean

              • 4. Re: Ideas need for a service.

                lol It's been a while I havent touched this... :P

                But my services are synchronous...

                Bassically some "client" computer connects to them sends a request they process the request with a 3rd party connecting to them externally, either through http, tcp/ip or any protocol required and they finally respond back to the client.

                This is also realtime, meaning the "client" is expecting a response right away.

                If I rethink it over now... I would implement them as simple servlets with an XMLRPC interface or something to that extent. Like this I wouldn't have to worry about life cycle management etc... And web apps can be monitored as well, servlets can be reloaded etc... So it's all good.

                Thanks