Basic Deployment Question

[neilac333]

I have a ridiculously basic question: how the heck do you actually deploy and run Spring integration? For all the documentation about integration concepts like messages and channels and endpoints and on and on, it is confounding that there is nothing on how one actually implements Spring Integration in the enterprise. Maybe I just missed it.

Any insight into how you actually implement Spring Integration or where this information can be found is much appreciated.

Thanks.

[JonasPartner]

The best place to start would be with the samples which show how to run Spring Integration from a main method Samples.

In short Spring Integration runs within the Spring application context and starts and stops with the application context. There is no server start up in Spring Integration. Therefore you can easily start SI from a main method or as part of an existing webapp.

[Mark Fisher]

All you need is to include the spring-integration JAR (plus any of the adapter JARs if you are using them) on your classpath. Then, add the necessary bean definitions to your ApplicationContext. The "deployment unit" is just a normal Spring context.

The "samples" appendix also walks through a runnable example that is included with the distribution (Cafe Demo).

I don't know if that answers your question. Please let me know either way.

Regards,
Mark

[neilac333]

Given your responses, I could have a mere Java class with main method (which could be run through a service on Windows, for example) that fires up an ApplicationContext. Then, SI goes and finds all the message endpoints defined in the configuration file and just waits for the message party to begin.

Is this correct?

Thanks very much for the prompt responses.

[JonasPartner]

Yes that will work

[neilac333]

I have been studying the documentation and the samples, and I think I have an idea as to how Spring Integration can help me solve my numerous integration challenges. Let me briefly describe one of the simplest of these challenges and how I think SI can help.

There is an enterprise web service that provides authentication capability. You pass it a username and password and you get a message backing saying yay or nay. Pretty basic. There are three applications in the enterprise that wish to utilize this web service for authentication.

Judging from the samples, I imagine I would have a RAR deployment of SI at the nexus of all these applications. Then I include the SI jars in the classpaths of all the applications so that they can open a channel to SI with a specified name and send the credentials through it. Then the SI deployment waits to receive the credentials from any of the individual applications and passes them on to the web service in a SOAP message. When the web service responds, SI unmarshals the response and sends the response to the original application making the request through the same channel. Finally, the application acts according to the result of the authentication attempt.

I am curious if this makes sense in the following ways:

• Whether this is an appropriate use case for SI
• How I am deploying SI
• The adding of the SI jars to all the other applications
• The way that SI is used to do the marshalling and unmarshalling

Any insight is appreciated.

Thanks.

[mirror303]

I am curious if this makes sense in the following ways:

• Whether this is an appropriate use case for SI
• How I am deploying SI
• The adding of the SI jars to all the other applications
• The way that SI is used to do the marshalling and unmarshalling

Ok, I am going to think out loud here. I felt prompted to respond because I struggled with understanding the same thing at first. Now I get to check if I really got it I'm sure one of the SpringSource guys will correct me if I go wrong.

I think one important aspect is to understand the distinction between logical communication between components (represented by channels, aggregators, splitters etc) on the one side, and the physical transport adapters, which are some kind of channel-adapter (for example: <jms:inbound-channel-adapter />, on the other side.

The Cafe sample-app is a great example of the *logical* config. I think splitting the Cafe app in to multiple JVM's and connecting them again using SI adapters, to form the same logical unit is a good way of getting a feel for this distinction.

So yes, in order for any component to use SI, it will require some SI-specific (channels, endpoints etc) config and at the very least the spring integration jar on board. To be able to connect it to components that live in another JVM, you will also require some kind of physical transport mechanism to allow these components to communicate. That is where the SI adapters come in.

Marshalling and Unmarshalling is dependent on the form of physical transport you use. JMS uses a Java serialization, web-services have to serialize to XML.

In your particular case I would imagine running the authentication service and configuring all the necessary adapters so that requests may reach your service through multiple ways of physical transport (Spring-WS, RMI, JMS etc etc) The clients needn't be aware of SI. They are simply calling a web-service or some http-invoker method. All these requests would follow the same path:

client => [physical transport] => [physical adapter] => logical SI channel => your authentication service (using a <service-activator />)

So what would you have won by Using SI?

• You would have to do only one deployment of your physical service
• You can replace some homegrown-code by SI-config
• You have a clear way forward when another form of transport is required.
• You have used a well-documented tool to achieve this

[neilac333]

Thank you for your input, Hans. While I understand what you are saying conceptually, I think I would benefit more by discussing specifics.

Let's start by simplifying and clarifying my scenario:

• Deployments
  
  • RAR deployment of SI on WebLogic instance
  • WAR deployment of some web application (not written with Spring) that demands authentication (on the same WebLogic instance)
  • Enterprise web service that makes authentication capability available to all comers
• Classes
  
  • EnterpriseAuthenticator POJO in SI RAR using Spring Web Services to hit the enterprise service and perform authentication given a username and password
  • Profile POJO in SI RAR that returns information about the authenticated user if authentication succeeds
  • AuthenticationException Throwable class thrown by EnterpriseAuthenticator if the user cannot be authenticated
  • ApplicationAuthenticator POJO in WAR that passes the username and password to the EnterpriseAuthenticator and receives the Profile or the AuthenticationException back

Note that there is only one messaging strategy: SOAP messaging. There is no need to consider JMS, etc.

It seems to me that ApplicationAuthenticator is a gateway with a default-request-channel which is the input channel through which user credentials are passed to a service-activator bound to EnterpriseAuthenticator. The EnterpriseAuthenticator then sends the Profile through the default-reply-channel to the ApplicationAuthenticator gateway.

Given all this, does it make sense? Also, in the case authentication fails, is the AuthenticationException object sent back along the default-reply-channel the same way the Profile is upon success?

Thanks.

[mirror303]

Reading your scenario, it seems to me you could just call the webservice directly from any of the webapps that require authentication, no need to put SI in between.

[neilac333]

That's certainly true. And that's in fact what I envisioned doing a while back.

But then again, isn't that true of any service? Any application can just directly call upon any service. Why would the notion of integration even come up?

To offer an answer to my own question, the answer is that my scenario was pruned to be as simple as possible. The reality is that there is more than one application that needs to use authentication, and it is unnecessarily redundant to have each application call that service in the same way. It would seem much better to have each application be a gateway and communicate in the manner I described without any additional programming or any knowledge of the integration technology. Bear in mind also that there is more than one service needed by multiple applications, so an integration tool that can manage all those communications in a way that spares the applications the details is desirable.

If I am correct, then the questions I raised earlier still apply. And I have another: Must each application have the SI jars and an application context configuration file just as the RAR deployment of SI does?

Thanks.