On Sep 13, 2006, at 10:41 AM, Liu, Jervis wrote:
Not sure if I have got the idea. Can we take a more concrete
example? Lets say my interface type is wsdl, a corresponding method
in my java component is as below:
public String getGreetings(String name);
in order to access HTTP query info (this can be useful for a rest
service), do you mean I need to define my method like below?
public String getGreetings(String name, @Autowire String query);
or
@Autowire
public void setQuery(String query) {
this.query= query;
}
As what available from context can be anything, I am not sure what
strategy should be used to extract specific attribute from context
then wire it into component. According to the Autowire attribute
name? For example, if I specify an Autowire attribute named query,
I shall expect there is an attribute named query in the context and
its type is String?
I'm not really thinking @Autowire - that is more for declaring a
reference to another service.
I think the most important thing here is to clearly identify what the
service is doing. In application terms I could say, it generates a
greeting for someone based on their name. I have one dependency here
- the name - that is part of the service contract so I write this as:
String getGreeting(String name)
As part of the binding we need to map the incoming data into a String
containing the name e.g. by extracting it from a HTTP query param, or
from XML or JSON data in a POST, or from a XML or binary JMS message.
That mapping though is *not* part of the application-level
specification (nor should it be).
Now we can chef it up a bit and say let's make the service return a
greeting in the user's language. Now we have an extra dependency in
the implementation - the language. We can express this in the
operation as:
String getGreeting(String name, String language)
[[ as an aside, the implementation may another service that returns
greetings for a given language which would be expressed as Reference;
however, that is really implementation detail and not part of this
service contract ]]
Again, our business logic is still independent of the physical form.
The value for the language parameter could be passed as business data
in XML, extracted from an Accept-Language HTTP header, whatever.
What's important to the application logic is that it is told the
language to use.
What's also important here is the separation of concerns - that of
extracting language from an inbound request from using that
information to render the message. The latter really is application
function, the former is a little more vague. It could be pure
infrastructure ("get the value of an HTTP header field") or it could
be that middle ground application infrastructure ("get the language
for the requesting user"). It is in that middle ground that I think
the notion of reusable business aspects can play. Make the component
available to the runtime (along with metadata that says what it does)
and have the runtime engage the appropriate set of aspect components
to make the application work.
Pushing this information into application logic is easy; for example,
adding a parameter, ThreadLocal, setter on a "stateless" component or
something that passes in the raw headers. We need to do that to
support existing apps and the last resort case where the
infrastructure can't handle the mapping. We don't want that to be the
norm though otherwise we're just reinventing the wheel :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
