Topic
10 replies Latest Post - ‏2011-05-03T11:56:19Z by SystemAdmin
SystemAdmin
SystemAdmin
783 Posts
ACCEPTED ANSWER

Pinned topic Spring in WAS on z/OS

‏2009-02-13T16:45:26Z |
We are creating an application which will be deployed in WAS 6.1 on z/OS. Before we proceed, we are looking for any information on how spring performs on the z/OS platform, any limitations or guidelines that need to be followed using spring for the z/OS platform.
Updated on 2011-05-03T11:56:19Z at 2011-05-03T11:56:19Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    783 Posts
    ACCEPTED ANSWER

    Re: Spring in WAS on z/OS

    ‏2009-02-13T18:53:04Z  in response to SystemAdmin

    It depends on what you do with Spring. Several customers are using the Spring Framework (not, NOT Spring Batch) with Compute Grid on z/OS. If you use Spring's core dependency injection (DI) and aspect-oriented (AOP) features, the overhead is negligible, especially in the context of batch processing. I'm still looking at best practices around having a single application context per job instance, or a single application context per JVM, something I'll write expand on in a forthcoming article. Assuming that the wiring of your application using Spring is done during the initialization of your batch application (or initialization of the job instance), the assembly costs will be minimal compared to the cost of processing 10's of thousands of records; the more data to be processed in the batch job, the more negligible the overhead of Spring assembly.

    Of the many features that the Spring Framework provides, using annotations for transaction management may not be good to use with Compute Grid. Your batch business logic should not do anything with transactions, leave that up to Compute Grid to manage. Compute Grid provides container services for checkpoint/restart; where the container essentially does the following:

    While (input data exists) do {
    __transaction begin() {
    _____for (M records or N seconds in this checkpoint interval) do {
    _______read record, process record, write record
    _____}
    __transaction commit()
    __}
    }


    • SystemAdmin
      SystemAdmin
      783 Posts
      ACCEPTED ANSWER

      Re: Spring in WAS on z/OS

      ‏2009-02-13T19:24:33Z  in response to SystemAdmin
      Thanks for the response Snehal, let me know if you do find some best practices or when you complete your article.
      • SystemAdmin
        SystemAdmin
        783 Posts
        ACCEPTED ANSWER

        Re: Spring in WAS on z/OS

        ‏2009-02-14T21:06:05Z  in response to SystemAdmin

        In the meantime, you can considering the following roles of relevant technologies to get a better idea of how to put your application together:

        1. Compute Grid: the Compute Grid runtime should serve as the batch processing platform, responsible for providing end-to-end resource management, operational control, parallel processing, application scale-out, and container-managed services. In order to provide interesting container-managed services like checkpoint/restart, job throttling/pacing, etc a contract must exist between the container and the batch application. The contract in the case of Compute Grid is a programming model, which you can read more about at Link: http://www.ibm.com/developerworks/websphere/techjournal/0801_vignola/0801_vignola.html.

        2. Batch Data Stream Framework (BDSFW): the BDS Framework provides implementations for common input and output streams (files, MVS datasets, JDBC, JPA, etc). The idea is to implement as much of the Compute Grid programming model as possible, allowing the customer to focus on their business logic. Customers are not required to use the BDSFW; they can implement the Compute Grid classes themselves, using the BDSFW source as an example implementation. The advantage of the BDSFW though is that it imposes some structure on the developer (yes, this can be an advantage for undisciplined development teams :); where problems are forced to be solved by applying the strategy pattern and separating concerns into INPUT (acquire data and create a business record) -> PROCESS (apply business logic to business record) -> OUTPUT (persist result).

        3. Spring Framework (specifically Spring Core): The Spring Framework's dependency injection and aspect-oriented programming (AOP) features are very interesting. These features can be used to wire together the business logic for the "process" component listed in the BDSFW for example. There are a number of configuration options here:
          • 1 Spring container for the entire JVM. The JVM singleton pattern (where the constructor is private and a static getInstance() method is public) can be used to load the configuration for the entire application. The Spring beans would be scoped to "prototype", forcing the Spring container to create new bean instances for each batch application that gets created. What I'm uncertain of is whether the Spring container would limit linear vertical scalability (will the Spring container become a bottleneck because of synchronous codeblocks, because many application server threads will be executing concurrently). I don't know the answer to this yet. The lifecycle of the Spring container would then be tied to the lifecycle of the JVM

          • 1 Spring container per application configuration. The considerations are similar to the ones stated for 1 Spring Container per JVM. The difference is that the lifecycle of the Spring container is tied to the lifecycle of the application.

          • 1 Spring container per batch job instance. The beans within the Spring configuration could be scoped as "singleton" (Spring's default). Each batch job instance creates its own Spring container, wires the application during the initialization of the batch job, and tears the Spring container down when the job is destroyed. There are several considerations here. First, each batch job instance will incur the overhead of initializing the Spring env, which for basic apps at least is negligible; the more data the batch job processes, the less interesting the overhead of Spring initialization becomes. Another consideration is the ability to rollout changes to the application (adding new aspects, changing the wiring, etc) on a per-batch-job instance basis, where the changes go into effect for the next batch job submitted (and a JVM restart wouldn't be required). This provides more fine-grained control of the structure of the batch job, but as the saying goes, "with great power comes great responsibility", ie. what happens if the application is rewired and those changes are applied to a job that is restarted? Part of the job executed as version 1 of the application, and the rest of the job was executed as version 2.


        The article I'm working on will expand on each of the topics I've listed, and also discuss some aspects of security and deployment. I'll also provide some examples and patterns that can be added to the BDSFW. In the meantime, rest assured knowing that Spring Core + BDSFW (optional) + Compute Grid runtime does work, and work well together across z/OS and distributed platforms. Several customers are in production with the configuration. Spring Batch on the other hand is a little bit more difficult, one issue is that there no longer is a clear contract between Compute Grid's batch container and the batch application (since Spring Batch apps can be developed independent of the Compute Grid programming model and BDSFW). The Spring Batch application may not be able to take advantage of the various container-managed services we have (and are working on :). Another issue is that Spring Batch uses CommonJ, which could have workload management ramifications on z/OS. I'm still investigating the Spring Batch integration, and I'll post here if I come up with something.


        Thanks, Snehal
        • SystemAdmin
          SystemAdmin
          783 Posts
          ACCEPTED ANSWER

          Re: Spring in WAS on z/OS

          ‏2009-02-16T06:40:39Z  in response to SystemAdmin


          I've attached the first draft of the article discussing Spring and Compute Grid. I'll continue to post revisions. Please feel free to comment.

          Thanks, Snehal
          • SystemAdmin
            SystemAdmin
            783 Posts
            ACCEPTED ANSWER

            Re: Spring in WAS on z/OS

            ‏2009-02-18T09:36:46Z  in response to SystemAdmin
            btw, I noticed a type in the document - the implementation class for the AccountReconciliationbean shared-service in listing 1 is incorrect. I've attached the correct impl class name.

            Thanks, Snehal.

            • SystemAdmin
              SystemAdmin
              783 Posts
              ACCEPTED ANSWER

              Re: Spring in WAS on z/OS

              ‏2009-03-09T10:46:43Z  in response to SystemAdmin
              Hi Snehal,
              thanks for this interesting paper and it's great that the BDS framework is extended to work seamlessly together with Spring.

              After reading your paper, I have a couple of questions:
              • Which version of the BDS-Framework will include these extensions?
              • Are all parts spring bean aware?
              Meaning: if I want to use DI in the scope of my input stream, can I use spring bean definitions
              with:
              
              bds.inputStream=AccountReader
              

              or with:
              
              bds.inputStream.PATTERN_IMPL_CLASS=AccountReader
              

              or in any of the two locations?
              • Does the root xml configuration file have to sit somewhere in the file-system or will it also be picked up when it's one of the jars in the application path? The latter would certainly be preferrable.
              • Can you make a workspace available for it? :-)

              Thanks and kind regards,
              Ralf
            • SystemAdmin
              SystemAdmin
              783 Posts
              ACCEPTED ANSWER

              Re: Spring in WAS on z/OS

              ‏2009-05-11T17:32:44Z  in response to SystemAdmin
              Hi Snehal,

              All that you mentioned in the pdf, is it all avaliable as part of CG?
              We are running on ND 6.1.0.21 and XD-6.1.0.4.

              Thanks,
              Vipul
              • SystemAdmin
                SystemAdmin
                783 Posts
                ACCEPTED ANSWER

                Re: Spring in WAS on z/OS

                ‏2009-05-11T20:34:36Z  in response to SystemAdmin
                Hi Vipul,

                All that I described in the PDF can be done today with Compute Grid. Your Batch Job Step should load the Spring application context (scoped per your needs). Your batch loop can then pass the input records to the Spring-assembled job step. The BDSFW can be used to initialize and manage your input and output streams. I've written a "SpringifiedXDBatchStep" batch job step implementation, which uses Spring to load a batch record processor, but it hasn't been officially released yet. I will post that sample step implementation here shortly.

                Thanks,
                Snehal
                • SKQB_Jason_Griebeler
                  1 Post
                  ACCEPTED ANSWER

                  Re: Spring in WAS on z/OS

                  ‏2011-04-19T14:40:11Z  in response to SystemAdmin
                  Hi Snehal, sorry to dig up an old thread, but was the Springified class ever released into the BSDFW?
  • SystemAdmin
    SystemAdmin
    783 Posts
    ACCEPTED ANSWER

    Re: Spring in WAS on z/OS

    ‏2011-05-03T11:56:19Z  in response to SystemAdmin
    WCG has not shipped a "Springified" Batch Framework update. Use of Spring remains "supported as is" according to the standing WebSphere Application Server product support statement.

    WCG v8 (available June 2011) supports OSGi Blueprint, which is the standardization of Spring's IOC container.