If you ask 100 people what they mean by SOA applications you'll probably get 100 different answers. However, there are some common requirements:
i) they should scale from several to hundreds and thousands of participants/services.
ii) they should be loosely coupled, so that changes of service implementation at either end of an interaction can occur in relative isolation without breaking the system.
iii) they need to be highly available.
iv) they need to be able to cope with interactions that span the globe and have connectivity characteristics like the traditional Web (i.e., poor).
v) asynchronous (request-request) invocations should be as natural as synchronous request-response.
Scalability and availability are possible with other technologies, such as CORBA. Although (ii) and (iv) can certainly be catered for in those technologies as well, the default paradigm is one based on an implementation choice: objects. Objects have well defined interfaces and although they can change, the languages used to implement them typically place restrictions on the type of changes that can occur. Now although it is true that certain OO architectures, such as CORBA, allow for a loosely coupled, weakly types interaction pattern (e.g., DII/DSI in the case of CORBA), that is not typically the way in which applications are constructed and hence tool support in this area is poor.
There is no objective way in which to approach the question of whether SOAs can be catered for in traditional environments. The answer is obviously yes, because no new language has been invented for SOAs and current tools are used to develop them. However, the real question is what is the best paradigm in which to consider an SOA that allows it to address all 5 points above.
Concentrating on the message and making it the central tenant of the architecture is the key to addressing the 5 points. How this is mapped onto a logical architecture (objects, procedures, etc.) and ultimately onto a physical implementation (objects, methods, state, etc.) is not important. The fact is that many different implementations and sub-architectures could be used. So what is the fundamental concept or mind-set in which to work when considering SOA?
The answer is that this is not about request-response, request-request, asynchrony etc. but it's about events. The fundamental SOA is a unitary event bus which is triggered by receipt of a message: a service registers with this bus to be informed when messages arrive. Next up the chain is a demultiplexing event handler (dispatcher), that allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture.
JBossESB does not impose restrictions on what constitutes a service. The ideal SOA infrastructure encourages a loosely coupled interaction pattern between clients and services, where the message is of critical importance and implementation specific details are hidden behind an abstract interface. This allows for the implementations to change without requiring clients/users to change. Only changes to the message definitions necessitate updates to the clients.
As such, JBossESB uses a message driven pattern for service definitions and structures: clients send Messages to services and the basic service interface is essentially a single doWork method that operates on the Message received. Internally a service is structured from one or more Actions, that can be chained together to process incoming the incoming Message. What an Action does is implementation dependent, e.g., update a database table entry, or call an EJB.
When developing your services, you first need to determine the conceptual interface/contract that it exposes to users/consumers. This contract should be defined in terms of Messages, e.g., what the payload looks like, what type of response Message will be generated (if any) etc.
Clients can then use the service as long as they do so according to the published contract. How your service processes the Message and performs the work necessary, is an implementation choice. It could be done within a single Action, or within multiple Actions. There will be the usual trade-offs to make, e.g., manageability versus re-useability.
Monday, July 30, 2007
Saturday, July 28, 2007
Hello World
How do you get going with JBossESB? If you need a place to start take a look at the Hello World demo. It is a five minute introduction in which you learn
--Kurt
- how to start and stop JBossESB in debug mode from within the JBossIDE,
- how to deploy your first service: Hello World!
--Kurt
Wednesday, July 4, 2007
"Introducing" JAXB Annotations on Unannotated Java Typesets
Over the past few weeks we worked on migrating the SOAPProcessor (formerly known as "JBossWSAdapter") up to the JBossWS 2.0.x codebase. This was important for us because we wanted to get away from our dependency on a non-public JBossWS 1.x API. JBossWS has introduced a new SPI into the 2.x codebase. Changing the JBossESB SOAPProcessor action component to depend on this public SPI was a no-brainer.
However, the native SOAP stack in JBossWS 2.x depends on JAXB for SOAP<->Java binding. This raised an issue for us because JAXB is 100% driven by annotations on the Java binding classes. If your Webservice Java bindings are not JAXB annotated, JAXB will not marshal/unmarshal SOAP<->Java properly (see JAXB forum post).
A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. In this situation, you can use the ESB to define a "wrapper webservice" that maps calls to the target Service (we'll be automating this in a future release). In this situation you'll also want to use the Java types that define the target Service, when defining the "wrapper webservice" e.g. use an EJB's remote interface, without modification, to define a JSR 181 wrapper service.
So, in the usecase outlined above, the Java types that define the target Service are obviously not going to be JAXB annotated (or at least they typically will not be). At this point, using JAXB (and therefore JBossWS 2.x) is no longer an option, since JAXB will not work against an unannotated interface.
The JAXB RI API supports setting a RuntimeInlineAnnotationReader during JAXBContext creation. We've used this feature to support "Introduction" of the JAXB annotations, from an XML configuration, for interfaces that are not JAXB annotated. It works by creating dynamic proxies for the annotations as they are requested by JAXB RI, with the dynamic proxies being fed via an XML configuration. See "JAXB Annotation Introductions" for more details.
Having done this, and having talked with the JBossWS guys, it would appear as though users of JAXB are not the only ones that run into trouble as a result of not having an alternative to a purely annotation driven configuration model (JSR 181 being another example that Thomas Diesler and Hieko Braun have pointed out). Is there room for a general purpose mechanism that can be used to manually "Introduce" annotations in situations like this? Obviously you could suggest that implementations should just support 2 configuration models - internal (annotations) and external (something else - fed by XML, or whatever). But surely a single underlying configuration/metadata "access" mechanism (the Annotations API) is preferable.
The Annotation Reader approach (ala JAXB Introductions) seems to offer something along these lines, but it would be nice if it could be done without requiring the annotation reader i.e. it would be nice if we could introduce annotations directly on the Annotations API (AOP style).
However, the native SOAP stack in JBossWS 2.x depends on JAXB for SOAP<->Java binding. This raised an issue for us because JAXB is 100% driven by annotations on the Java binding classes. If your Webservice Java bindings are not JAXB annotated, JAXB will not marshal/unmarshal SOAP<->Java properly (see JAXB forum post).
A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. In this situation, you can use the ESB to define a "wrapper webservice" that maps calls to the target Service (we'll be automating this in a future release). In this situation you'll also want to use the Java types that define the target Service, when defining the "wrapper webservice" e.g. use an EJB's remote interface, without modification, to define a JSR 181 wrapper service.
So, in the usecase outlined above, the Java types that define the target Service are obviously not going to be JAXB annotated (or at least they typically will not be). At this point, using JAXB (and therefore JBossWS 2.x) is no longer an option, since JAXB will not work against an unannotated interface.
The JAXB RI API supports setting a RuntimeInlineAnnotationReader during JAXBContext creation. We've used this feature to support "Introduction" of the JAXB annotations, from an XML configuration, for interfaces that are not JAXB annotated. It works by creating dynamic proxies for the annotations as they are requested by JAXB RI, with the dynamic proxies being fed via an XML configuration. See "JAXB Annotation Introductions" for more details.
Having done this, and having talked with the JBossWS guys, it would appear as though users of JAXB are not the only ones that run into trouble as a result of not having an alternative to a purely annotation driven configuration model (JSR 181 being another example that Thomas Diesler and Hieko Braun have pointed out). Is there room for a general purpose mechanism that can be used to manually "Introduce" annotations in situations like this? Obviously you could suggest that implementations should just support 2 configuration models - internal (annotations) and external (something else - fed by XML, or whatever). But surely a single underlying configuration/metadata "access" mechanism (the Annotations API) is preferable.
The Annotation Reader approach (ala JAXB Introductions) seems to offer something along these lines, but it would be nice if it could be done without requiring the annotation reader i.e. it would be nice if we could introduce annotations directly on the Annotations API (AOP style).
Webservices and WS-BPEL Process Orchestration - A Follow Up
We've done quite a bit of work in the Webservice/SOAP area since I posted Webservices and WS-BPEL Process Orchestration.
Since then we've added the SOAPProcessor (SOAP onto the bus) action to complement the SOAPClient action (SOAP off the bus). Check out the Webservices/SOAP components and let us know what you think.
We had some fun upgrading to JBossWS 2.0 after we ran into issues with JAXB and how it doesn't allow us to use Java bindings that are not JAXB annotated. More on that in another blog.
Since then we've added the SOAPProcessor (SOAP onto the bus) action to complement the SOAPClient action (SOAP off the bus). Check out the Webservices/SOAP components and let us know what you think.
We had some fun upgrading to JBossWS 2.0 after we ran into issues with JAXB and how it doesn't allow us to use Java bindings that are not JAXB annotated. More on that in another blog.
Subscribe to:
Posts (Atom)