Discussions

General J2EE: Implementing SOA, without the expensive tools & servers

  1. I'd like to use some SOA concepts on my current project, currently in the design phase. I'm pretty familiar with SOA at the conceptual level, but where it's not clear is at the implementation level. The articles, white papers, and books I've read seem to be too high level. I know IBM has a suite of tools to help me out, but we don't have the budget.

    Our application is very process oriented, which fits well with SOA. However, at the current time, it seems that most of the processes would only be accessed by a single client, and the "client" could be another process in the application itself. In other words, for the moment I don't see major process re-use potential here but if I can keep that option open while at the same time simplying my design then I'm interested.

    I'm hoping someone here will have some input on some specific questions:

    1) The difference between service & process isn't clear. For the moment I'm looking at an object representing several processes. Each process is a method of the object. A hypothetical example:

    OrderService
    +processOrder()
    +getOrderStatus()

    2) Should this be modeled as:

    - regular java class? it would be injected into the other classes that need to use it.
    - session bean? adds features such as distributed, clustering, etc. but also adds complexity
    - MDB? We'll have some processes that are asynchron
    - JMS listener?

    This part isn't clear. Up until now (previous projects) I've avoided EJB including session beans.

    Thanks,
    Michael
  2. I'd strongly recommend you create your services as Java POJOs for now.

    The to get going you could use Lingo to distribute your services across JMS queues to provide load balancing, failover, recovery and location transparency as well as XA if you need it.

    http://lingo.codehaus.org/

    If you need an inexpensive JMS provider then try Apache ActiveMQ
    http://activemq.org/

    Once you've got your business logic wrapped in POJOs and the SOA middleware hidden; you can change it at a later date - e.g. you could try SCA later on (when its ready & complete) if you like.

    For now though I'd just focus on getting things working with Java POJOs and JMS; you can move on to the JAX-WS/JSR-181/SCA stuff and all the XML/XSD/WSDL stuff when you really need it.

    (BTW JMS will also be the best performing alternative, so you might as well start of with the simple & high performance option first :)

    James
    LogicBlaze
  3. I'd strongly recommend you create your services as Java POJOs for now.

    +1
    ... you can move on to the JAX-WS/JSR-181/SCA stuff and all the XML/XSD/WSDL stuff when you really need it

    ... at which point ServiceMix will be just what he needs? ;)

    Kit
  4. I'd strongly recommend you create your services as Java POJOs for now.

    Thanks for the suggestions, I will check out the Lingo framework. So far we're deploying with WebSphere so we'll get JMS with that. I think. Have to confirm that we have the right version, if not I was planning on using JBossMessaging.

    One thing that still isn't clear is the granularity.. I've been advancing on the design and have identified business services. But these business services will have helper classes. For now I'm distinguishing between the two, but it seems that it'd be possible that a helper service could itself be a business service to someone else. So I'm curious if there are any design patterns or guidelines here about how to structure the services. My coworker suggested taking each task in each process and making it a class. I think that's a little too extreme because we'll end up with 300 classes which will be hard to manage. But we're trying to find the optimal solution.

    Thanks,
    Michael