Service versioning is a subject that should
be considered carefully in enterprise SOA approaches. Let's take for instance
the case of releasing a new version of a service in the context of a shared
service in an organization. In this case you might need to have more than one
release of a Web Service accessible at the same time. Some consumers may
continue using the old version of a service until migration of all the consumers
code occurs to take into consideration the new functionalities and/or a new
interface...
In this blog I will try to address some of
the aspects that should be dealt with for versioning organization wide used
services. I will first try to identify the types of changes that may occur, then
I will introduce different patterns that can be considered and finally I will propose
a mapping of those patterns to real-world solutions. I will also consider the SOA
layer the service belongs to when applying those patterns and some practical
considerations related deployment of services in different versions.
A change in a web services implementation
may affect the consumers of this web service depending on a number of factors:
Therefore a typology of change in a web
service can be identified in relation with the impact of this change on the
current consumers and actions depending on that typology could be proposed. A
common way is to qualify as a minor release
a change that will not affect the current consumers and a major release a
change that will affect the current consumers.
A minor release can be of two types. The
first type being a correction of a bug or an enhancement in the Web Service
performances, this type will not affect the WSDL of the web service. The second
type consists of adding new methods to a web service; the WDSL is changed without an impact on the existing consumers.
A distinction can be done between those two types when labeling those versions,
for example you may choose to change the second decimal for the first type and
the first decimal for the second type (1.0X or 1.Y0).
A major release is a change that will break
backward compatibility. The consumers must be modified. In some case there
could be releases that affect only the functionalities of the Web Service without
affecting the WSDL. This may also be considered as a major release since the current
consumers cannot invoke the new web service without considering the modified
functionalities of the Web Service.
Now that types of changes ant their impact
on current consumer are identified let's us take a look at different patterns
for Web Services versioning.
When a new version of a web service is
released, a major or minor release, the consumers are notified about the change
and they will have the responsibility of changing the code to access the new
version of a service. The new WDSL is published, in a UDDI registry for example
and a notification is send to the consumers so they find the new service and
establish binding with the new service provider. Using a UDDI registry a practice
consists of associating a given version of a PortType to a unique tModel, one
WDSL is associated to one tModel, this tModel should contain a reference to the
version for major version since two major versions will imply two different
WSDLs, and may contain a reference to the minor version if two minor version
needs to be accessed at one time. Consumer of that portType/version could do green
pages search of UDDI for services that advertise compliance by associating
themselves with the tModel of the corresponding version.
This method may impose changes on the
consumers, at least in the search done to the registry for accessing a version
(minor or major) of a service, even for minor releases. And what if you need to
have two minor versions running at the same time? For instance you might want
to deploy a new minor release on a pilot site to be used by some consumers and
keep the old one for the majority of existing consumers. The consumers of the service
deployed on the pilot side will need to change the endpoint of the service even
if the WSDL is not modified (since it's a minor version). In this specific case
it may be practical to have a layer of indirection between the consumers
and the providers to drive the migration of different consumers in a graceful way.
Note: Consumer binding pattern does dot
imply the use of UDDI, it refers to the fact that the binding decision is done
on the consumers side. We will see later were it can be interesting to use this
pattern.
When a new minor version is released the consumer
could transparently migrate to a new minor release of a service: This being
provided by the layer of indirection thru a routing mechanism that ensure
content-based routing or user-based routing (based on the IP of the requester
for instance, or on the principal of the requester when propagating security
roles) to call the different versions of a Web Service.
When using a layer of indirection two minor
releases can coexist without changing the consumers' code, and a graceful migration
can be ensured to a new release.
But in the case of a major release the
consumers will need to change there code. And what if, for some organizational
reasons, we need to migrate to a new major release without changing the all
current consumers' code, calling the new service with the old client? This
might happen for example if some regulatory reason implies a change accessible
only thru the use of the new major release of a service, even for the consumers
still using the old client interface. This leads us to doing some adapting to
enable the use of a new major release for current consumers until all the
consumers' code is modified.
The adapter pattern consists of adapting
the client's request and response to be able to consume a new major release of
a service. Using this pattern offers a smother migration in case the use of a
new major version of a service is mandatory for some business, regulatory or
organizational reasons.
Applying the different patterns can be done
in different ways. In can be done in consumer's code, this implying considering
those patterns in the client's code: that is rarely the case, this
will also imply maintenance of the client code and can become quite complex.
Another way is to use a mediator for decoupling the consumer from the provider
and to apply those patterns in a service bus used as a mediator. Using
AquaLogic Service Bus as a mediation layer can provide the layer of indirection
pattern associated with the adapter pattern relieving the clients from those
concerns. This is shown to this figure:
In this case the use of the UDDI registry
is not mandatory.
AquaLogic Service bus offers a mediation
layer thru proxies to business services. Organizing the configuration of the
proxies and the business services with a reference to the version may be
practical. The proxies in AquaLogic Service Bus including a reference to the
major release and the business service including the minor release in there
path for example for a major v1.XX:
Note: The proxies and the WDSL being the
same for minor releases the path containing those does not include a reference
to the minor version.
But what about the deployment of two
different versions of a service on Weblogic using the same coding
environment? Those services might have the same J2EE web module context path
since they may be developed using the same Workshop project. Therefore, unless
you provide a build (using ant) adding a version reference in the context of
the J2EE web module you might want to consider deploying different versions of the same service
on different targets; a target being a cluster or a managed server. This is
shown in the figure below.
Presentation services and orchestration services
(business processes services) will benefit from the transparency of this
approach when consuming other services belonging to the business services
layer, data access services layer or orchestration services layer. But what
about consumers of presentation services, a composite portal using WSRP to
consume remote portlets. This approach can also be applied in this case but we
may use a simpler more adapted approach based on Weblogic Portal entitlements:
using visitor roles based rules and entitlements to display some part of the
composite portal depending on the user's properties. In some case the using
entitlements may be more pertinent for the presentation services layer, since
presentation services may rely on the end user profile and entitlements rules
will be more of the concern of the composite portal engine rather than the bus.
Therefore presentation services layer
versioning is better accommodated using the consumer binding pattern. In
this context applying this pattern is not done relying on UDDI to choose the
service but on entitlement offered by Weblogic Portal in a composite portal. An
important aspect that is respected with in this usage of the consumer binding
pattern is that the choice of the version is done thru configuration, in
the portal administration tool, thus it will not be implying any code
modification.
The figure below shows how a composite
portal may consume portlets thru WSRP in different versions for the same
application. The choice of exposing a version of a portlet is done in the
composite portal based on entitlements.
Doing this gives the ability of running two
versions of the same application at the same time exposing new functionalities
only to pilot end-users based on user profiles based restrictions. In this
context you may need one domain (containing eventually a cluster) per version of a
portal application if using the same context path for J2EE modules of the
portal application.
Service versioning can be done in different
ways depending on the needs and the constraints. It may be handled differently
depending on the layer the service belongs to and on the business constraints
that occurs. We covered in this blog some possibilities for:
Added to this some other considerations
should be taken such as XML schemas versioning and managing dependency between
services and the XML schemas used by those services. At the organization level this
will surely become very difficult to handle without the proper tools for
managing dependencies and for
driving the changes properly and holistically.
Context management in different scopes
Services exposed on the business services
layer can be of different types, simple services or composed services. Services
exposed on a data access layer can be also be CRUD operations on coarse-grained entities or composite services offering composed actions on different entities
spanning on multiple datasources.
Composition of services based on other
services may have a stateless context of composition that consists of having a
context during the composition of different services. For example using
AquaLogic Service Bus for composing different services gives the possibility of
having a context, when invocating the different services as source of
composition, valid in a stateless fashion: meaning that the context is there
during the stateless invocation of the services and will not pertain any
longer. Another example is using Aqualogic Data Service Platform for composing
services coming from disparate data sources offering a context valid during the
composition of data.
On the orchestration layer, known also as
the business processes layer, we need to go further in our composition. For
this a context containing the state of an orchestration is needed. Compared to
simple composition, orchestration has a context that needs to persist longer
than a call to a service. The context of composition in the orchestration layer
may be related to system-to-system processes or human centric processes. BPEL
offer a standard for dealing with this type of composition. BPEL-based
processes provide automation of complex interactions between web services, this
including long-running transactions with compensation and parallel execution.
Let us not speak of choreography, known as
WS-CDL, this might be interesting when defining a way to coordinate an
interaction between different organisations. Orchestration is used inside one
organisation, choreography between organisations. WS-CDL describes peer-to-peer
collaborations by defining their common and complementary observable behaviour;
where ordered message exchanges result in accomplishing a common business goal.
Let's go back inside an organisation's
scope and the different types of composition and their contexts that may occur
between applications and in composite applications.
MVC revisited
One simple and basic approach using Weblogic
Portal exposing screens in a human centric process may consist of relying on
the page flow mechanism to maintain the navigation context. Designing human
interfaces we are used to screen flows, STRUTS or beehive page flows or instance. Those
screen flow managers contains some logic and a context, this context being
stored in the Web Session. The page flow may be calling the corresponding
service depending on a mapping provided by some code, using IoC for associating and action to a service to call
or thru a service delegate built using a Web Service Control. This mapping could also be
used to call the correct version of a service (Service versioning is a subject
by itself and needs careful attention). But how does this relates to
business processes spanning across an organisation thru different business
units? On the SOA presentation layer and in the context of a composite application
should the screen flow logic rely on a BPEL orchestration engine or should it
continue being controlled by a screen flow manager that relies on logic
contained in page flows and variables held in the Web session? There cannot be
a universal answer for this. There could be different approaches that may be
applied, here is one approach.
The diagram below shows how composition
logic can be done in AquaLogic Service Bus, business services are managed on
the business services layer. In this diagram separation of concerns is
respected in terms of separation of screens from composition logic and business
services...
Loose coupling is respected since we are
addressing the services thru a mediation layer that makes the client
independent of the services implementation or the service transport. For example a service may be
exposed thru AquaLogic Service Bus using a SOAP proxy,
the business service itself being natively provided thru RMI, in later stages
a new version of the business service could then provided natively using SOAP. This will happen frequently
nowadays, since existing services are moving to SOAP. Using a services mediator transport switching can be
done without changing the client's code.
A question may also rise:
Should human interaction services be managed by a simple action to service
mapper and response to page service in a way similar to struts? Is this enough?
What about separating the business process
logic from the screen management? What should be done with in a page flow
and what should be done outside a page flow? My answer is:
A page flow is a succession of steps with
in one activity of a process. So a process engine should be used to
manage the process as a hole with all the implications the process has with in
an organisation. This process as a hole will have activities managed by a page
flow. In other terms when a succession of screen is done with-in one activity of
a business process this can be managed in a page flow, otherwise this should be
done using a process engine.
This leads to a question, what is an
activity? A definition of an activity is given in this article BPM for the Masses: An Introduction to BPM written by Mariano Benitez.
On the other hand orchestration can become
very complex and different patterns are applied for system-to-system
orchestration compared to human centric processes. For example in systems to systems processes
JTA transactions should be considered carefully, proper compensation for non JTA resources
should also be provided and this may become very complex...
Conclusion
All those questions and possible solutions
raised in this blog suggest there are no one-fit-to-all solution. But there
should be some patterns defined and enforced in an organisation. Different
cases can be identified and work can be done to demonstrate the best practices
that should be enforced within an organisation. Best practices, design
principles should be written and maintained with an organisation to avoid
contradictory approaches that will certainly occur if no governance is provided
with in this concern.
Top-down and bottom-up approaches compared
Posted by BECHARAG on January 29, 2007 at 10:55 AM | Permalink
| Comments (0)
Top-down and bottom-up approaches compared
Top-down and bottom-up approaches compared
In part 1 of my blog Application architecture using Weblogic Integration on dev2dev
I have introduced 3 approaches those being the bottom-up, top-down and
meet-in-the-middle. The rest of the 3 parts blog focused on application
architecture using Weblogic Integration.
As you may have noticed in Application architecture
using Weblogic Integration - Part 2 I did not mention the approach used in the choices that were made.
The choices could have been done using a top-down or a bottom-up approach. In
the blog From application architecture to enterprise architecture - First
steps I have tried to
take the application a step further to expose some of it's services to be used
thru the enterprise. But in a real context this will depend on the choices done when defining the services interfaces and the business functions they implement: Can and will those
services be reusable holistically
in the organization? How to identify services that can be reused holistically,
how to share them? What is the appropriate approach?
The bottom-up approach may be faster and easier to apply but may
result in services that are not easily reusable holistically in an organization. The top-down approach is harder to apply
and needs more governance and guidance but will result in better reuse thru the
organization. I have submitted an article for review introducing a simplified
top-down approach and the advantages related to it. Hoping it will give some
guidance in this concern.
Achieving an efficient SOA: Is it only about products?
Posted by BECHARAG on November 26, 2006 at 3:47 AM | Permalink
| Comments (0)
Achieving an efficient SOA: Is it only about products?
Achieving an efficient SOA: Is it only about products?
Understanding and choosing the right
products should help when implementing SOA. This may not be obvious but
could be easily achieved. An architect having the correct knowledge of the
products and the concepts behind them should help identify the products
that are adequate for implementing each of the SOA building blocks; what can be done out of the box and what should be written...
But this is not enough. Some effort, a lot
in some cases, depending on the SOA maturity of the enterprise, should be made on all levels to implement an efficient SOA.
SOA is about Products and People and
Process. Trying to achieve it with one of the
ingredients missing will surely lead to a poor implementation that may not meet
the objectives of SOA.
And people should come from all services of
an enterprise involving Lines of Business and IT. Failing to have the
correct representatives may lead to an incomplete solution. This was the case
of all development projects even before SOA was ever here. A development
project will not meet the business needs if the proper work has not been done
with the business specialists/users when writing the uses cases or prototyping
the screens that will be used by the end user.
In the context of SOA this task becomes
even more important. It's not about having one application used by one business
section of an enterprise, it's about having services identified and exposed in
such a way that they can be re-used by more than one business section, and those services should be chosen in such a way so they can be re-orchestrated or
re-composed rapidly to meet business processes changes. SOA is about agility,
one aspect of agility is the capacity of adapting the business processes to continuously
meet the changing demands of the LOB and the business strategy.
That's why implementing an efficient SOA may not be obvious.
You should take a look at a series of great
articles providing some hints on how to achieve SOA: Starting from Successfully Planning for SOA to Defining
an Effective SOA roadmap
ending with Long-term SOA Planning.
BEA has offerings and education helping
achieve an efficient SOA. More information can be found at SOA Resource Center.
From application architecture to enterprise architecture - First steps
Posted by BECHARAG on November 11, 2006 at 11:07 AM | Permalink
| Comments (0)
We have proposed different approaches for
application architecture using Weblogic Integration in a previous blog Application
architecture using Weblogic Integration.
The intent was application
architecture of one Workshop/Weblogic Integration
application, meaning one unit of deployment (one
ear).
In this blog we will be taking the
application some steps further, splitting it into multiple applications then
exposing some parts using Web Services. Each application exposed as Web Service
becoming an SOA building block.
We will be starting from the simple case
exposed in Application
architecture using Weblogic Integration - Part 2 and moving toward an enterprise
architecture thus promoting re-use at the service level.
Let's take go back to the typical case described
in Application
architecture using Weblogic Integration - Part 2, the case was about
having:
-
Two back-end systems one for CRM and one for
billing
-
Two groups of reusable processes dealing with
business logic
-
A group of long living processes representing business processes
-
A group of processes for handling errors, this
group being one of the technical aspects we want to handle
We ended up with this diagram:
Diagram 1
The graphical representations being:
In diagram 1 we had one application
containing different projects, the communication between different projects
being done using process controls or the message broker.
When adding applications, for example a
self services portal and some processes involving human interactions for
decision making, we may want to split the previous application in reusable
parts, sharing backend accesses with the new applications.
This will lead to diagram 2:
Diagram 2
In diagram 2, if all applications (ears)
were on the same Weblogic domain, the communication between them can continue
to work using Process Controls or the Weblogic Integration Message Broker.
But in the context of enterprise
applications the objective is to be able to communicate between services being
deployed on different domains, being eventually in different networks, and
exposed as services to be reused from other applications in the enterprise.
Weblogic Integration Processes are
naturally callable as Web Services without any other development efforts. On
the other hand, Common Workshop controls needs to have a Web Services as a
façade; this can be easily generated using Weblogic Workshop.
The case of diagram 2 may seem rather simple;
nonetheless in a real context the communication between the different
applications becomes quite complicated:
-
The communication is done point to point,
therefore the configuration of each application will become very difficult and
prone to errors: all the applications must know where to find each others
-
It may become rather difficult to control
versioning of the services: all the interactions are dependent on the versions
of each service so if the interface of one service get modified we need to
change all the clients that access to it
-
There is no easy way to guarantee some SLA when using Web Services
-
There is no easy way to easily monitor the
services in a centralized manner
-
It may become difficult to apply security
policies; this becoming essential when exposing services for reuse inside the
enterprise
-
Etc.
Thereafter, when applications exposing services
becomes numerous, communication between them may become chaotic if not
federated.
The common sense in today enterprise
applications is to federate all communications between applications using an
enterprise service bus. AquaLogic Service Bus can be used in this context as a
mediation layer between applications giving diagram 3.
Diagram 3
The direct benefits, only to mention some, using
a service bus as a mediation layer in our case are:
-
Alleviating point-to-point communications
-
Being able to apply a versioning strategy on
Web-Services
-
Guarantying quality of service and offering
monitoring for services
-
Handling security policies for accessing
Services
And the process of using exposed services in
client applications is not as straightforward. Even if you had an ideal XML
canonical model exposed by each service you will still need to do some
transforms to extract data from a model, representing an entity or a group of
entities to another representing another entity or a group of entities. A
typical pattern that need to be implemented when getting data from a backend
is, applied to an example:
-
extracting data from an account representation,
coming from a billing backend thru the access layer that returned the canonical
account representation
-
enriching it with data coming from the CRM back
end
-
transforming this data so it can be easily used
by the application that will do the order processing
This being done each time you need some
data by an application in the orchestration layer. Each application on the
orchestration layer may have its own requirement since it could be handling a
different group of entities. Thereby, after dissociating the orchestration layer
from the data access layer, you might still need to do some transforms in the
orchestration layer. Depending on the transform it might not be conceptually
clean to do this in the orchestration layer; thereafter you may want implement
this pattern in the Service Bus.
In a more general manner, applications communication
using Web Services is usually done:
-
validating data coming from application 1
-
enriching this data with data coming from
another application
-
transforming this data
-
calling the destination application
This is a common integration pattern that
can also be delegated to the Service Bus. This pattern is also known as the
VETO pattern (Validate, Enrich, Transform and Operate).
On the other hand, the data access layer
should be responsible of providing to the upper layers the enterprise canonical
model, and this can be automated in numerous cases using data services based on
SDO (Service Data Objects).
Implementing the data access layer requires
significant amount of custom code and this code need to be maintained. In the
context of application architectures, access to data uses some very well known
patterns such as DTO (Data Transfer Object), Data Access Object (DAO) for
insulating applications from physical data source. This concept, known as separation
of concerns, is transposed in enterprise architectures using a data access
layer. Conversion of data from a backend to the enterprise canonical model can
also be automated and simplified using adequate tools.
In other terms a universal data access layer
in the context of SOA, known as a Data Service, for enterprise
architectures can be viewed as a backend to canonical XML mapper; the
same as the O/R (Object to Relational) mapping tools widely used when building
applications accessing databases. O/R mappers are the right tooling in the
context of application architecture; a Data Service is the right approach in
the context of enterprise architectures.
Using AquaLogic Data Services Platform as an
automated data access layer can accelerate and simplify the building and
maintenance of an SOA data access layer.
Diagram 4
A larger version of diagram 4 can be viewed
here.
Application architecture using Weblogic Integration - Part 3
Posted by BECHARAG on September 1, 2006 at 9:09 AM | Permalink
| Comments (2)
After focusing on a simple case in the
second part of this blog Application architecture using Weblogic Integration - Part 2 let's see what are some of the
motivations behind the choices that were made.
Part 3: Impact on performance tuning and deployment
Performance tuning
Having multiple projects chosen depending
on the layer, the business module or the backend, as shown in part 2 of this blog,
will give more possibilities for tuning the application. This will be very
useful, when events coming from a backend are numerous, for preventing thread
starvation that may occur if all threads from the default queue are used for
processing those events. For Files Event Generators we surely could do some
tuning using the read limit for polling files in the file event generator itself,
but this may not be enough. Thereafter assigning a dedicated thread queue for all
processes belonging to a project may be a better approach.
For the processes called asynchronously, or
for controls having buffered method calls, the AsyncDispatcher queue will be
used calling a Message Driven Bean that will use the execute queue specified in
WEB-INF/wlw-config.xml of the Workshop project. This setting will generate the
appropriate dispatch element in the DD for the underlying EJB.
<wlw-config
xmlns="http://www.bea.com/2003/03/wlw/config/">
...
...
<async-dispatch-policy>application.project.ExecuteQueueName</async-dispatch-policy>
</wlw-config>
For the synchronous call, being started by
an external http Web Service call for example, you need to specify the thread
queue in WEB-INF/web.xml.
The associated execute queues should be
created using Weblogic Server administration console. If those queues do not
exist on the server the default queue will be used.
More information can be found at wlw-config.xml Configuration File.
For the internals of Workshop you
may want to look at this article http://dev2dev.bea.com/pub/a/2004/06/wlw_internals.html.
Project and application naming
A Workshop project name must be unique in a
Weblogic domain. A Weblogic domain may be hosting many Workshop applications
that are composed of Workshop projects. To avoid collision of contexts it can
be a good choice to prefix all projects by the application name giving:
[WorkshopProjectName] =
[ApplicationName][ModuleName]
Access to the context of the project or
to a process using a Web Service Control or a Service Broker Control is done
using an URL that contains (by default) the project name. We will have for
example:
http://server:port/[WorkshopProjectName]/com/mycompany/mymodule/.../ClientOrder.jpd
JMS queues used internally by a Workshop project
are also deduced form the Workshop project name. A project named WorkshopProjectName
will need those two queues:
[WorkshopProjectName]Processes.queue.AsyncDispatcher
[WorkshopProjectName]Processes.queue.AsyncDispatcher_error
Consider versioning stateful processes
from the beginning
An interesting support pattern on this
matter should be examined on Versioning JPD On Running Instances.
Calling processes and related
considerations
When calling a process from another on the
same domain you may choose to use a Process Control or use the Message Broker
depending design choices. This will work for processes being in different
projects or different applications provided they are on the same Weblogic
Integration domain. Calling a process form another Weblogic domain can be done using
a Service Broker Control, a Web Service Control or a JpdProxy. The latter can
be used in any java client.
The Process Controls can be copied to a Controls
Project to be shared between processes being in different projects or different
applications.
When using a Process Control if the child
process is synchronous it will be executed in the same thread as the caller. Using
a Service Broker Control instead of a Process Control in the same Weblogic Integration
domain will use another thread on the side of the called process since it will
be called thru the SOAP protocol on HTTP; this is not optimal for performances.
Special considerations are needed when making
synchronous calls using a Process Control across application boundaries with
complex Java types. The java classes should be added to the application server system
classpath to avoid classcast exceptions as documented in http://e-docs.bea.com/wli/docs81/relnotes/relnotesLimit.html#1268647.
Note: The XmlBeans documents created in a
jpd are handled in a special manner. This is being done by the Factory of the XmlBean
that will create the bean depending on the context of its execution. When the Factory
of the XmlBean is called in the context of a process it will create a proxy object
of type com.bea.wli.variables.ProcessXML allowing synchronous calls using a
Process Control across application boundaries with XmlObjects without having
the XmlObjects classes in the application server system classpath.
Application architecture using Weblogic Integration - Part 2
Posted by BECHARAG on May 1, 2006 at 4:57 AM | Permalink
| Comments (2)
We have proposed different approaches for
application architecture in the previous blog, Application architecture using Weblogic Integration. In this blog we will be focusing on a
simple case.
Part 2: Applying those approaches in a simple case
Let's take a typical case with:
-
Two back-end systems one for CRM and one for
billing
-
Two groups of reusable processes dealing with
business logic
-
A group of long living processes representing
the business process, or a part of it
-
A group of processes for handling errors, this
group being one of the technical aspects we want to handle
We will, as we said in part 1, use a single Workshop application as a starting point,
consisting of one deployment unit, having in mind that access to back-end systems
can be reused later from different applications. Re-using access to the
back-end systems in different applications should be easy provided they expose
the canonical XML model used internally in all applications. Argument passing between processes should be considered carefully
from a design standpoint and from a technical standpoint, the latter will be
discussed in part 3 of this blog.
Access to the back-end systems may have
different life-cycles depending on the versions of the back-end systems and can,
in later stages of the development process, be maintained and deployed
individually. Thereafter those parts of the applications can be re-organised in
different Workshop applications and exposed as services. Those services can be
accessed thru web-services controls or process-controls/service-broker controls
if they consist of processes. The access to those services should be considered
depending on the need of re-use and the source of re-use. Considering
performance impacts you may use the process control rather than the service
broker control between applications being deployed on the same Weblogic domain. We
will be covering performance issues in part 3 of this blog.
Now let's go back to defining the projects
of our application. Starting with the back-end systems, we will consider having
for the first back-end two Workshop projects named:
[MyApplication][CRMServices]Processes and
[MyApplication][CRMServices]Controls
and, for the second back-end one project
named:
[MyApplication][BillingServices]Controls
Notes:
-
Names included in brackets [] are variables
-
Naming of the projects, a Workshop application being
a group of projects, should be considered carefully. All project names should
be prefixed by the application name ([MyApplication]). We will get back on this
aspect in part 3 of this blog.
-
When defining the projects we assumed that the
CRM back-end may need to call our application. This is usually done thru
Weblogic Integration event generators. A process project must be considered for
this case. You may also want to apply XQuery transformations for converting the
canonical XML model used in the orchestration layer to the back-end XML format,
or the back-end XML model to the canonical model. A process project may be
needed for this case, considering that data transformation control (dtf) can
only be used in process projects.
-
A Weblogic Integration Event Generator needs
to use a message broker channel to post the message being received from the
back-end.
-
The access to the different back-ends is done in different
Workshop projects. This is intentional and will have a direct impact on
performance tuning as we sill see in part 3. We wouldn't want events coming
from a back end to cause thread starvation or potential dead-locks.
In the orchestration layer we can consider
having four projects named:
[MyApplication][MyModule1]Processes
[MyApplication][MyModule2]Processes
[MyApplication][MyModule3]Processes
[MyApplication]ErrorManagerProcesses
In the presentation layer we can consider
having two web applications. One of them being used for administration tasks
related to the application.
[MyApplication][MyModule1]Web
[MyApplication][MyModule2]Web
Added to those projects we may have one project
for reusable control and the other for java classes:
[MyApplication][MyCommonModule]Controls
[MyApplication][MyCommonModule]Java
All can be represented in this diagram:
A larger version can be viewed here
A best practice is drawing a diagram of
the application and its different modules, or Workshop projects, before starting
the development. This should be done and maintained
by the software architect taking into consideration organisation needs related
to development, reuse and performance tuning.
Graphic representations used in the diagram:
Note: We may
have, as depicted in the diagram, controls and custom controls in process
projects. This may be practical if those controls are only used by one project
with in an application. Only common controls, being used in different Workshop
projects in the same application or between different applications, need to be in
"control" projects. Process controls may for example be used for calling processes
from another project or another application than the project/application
containing the process, within the same Weblogic domain. Therefore these
controls should reside in a control project to be reused across different
Workshop projects. If you need to use those controls in different Workshop
applications consider putting them in a common directory and importing the
control project by reference or as library into your different applications, a
control project generates a jar residing in the APP-INF/lib directory of your
application.
Application architecture using Weblogic Integration
Posted by BECHARAG on March 13, 2006 at 11:59 AM | Permalink
| Comments (1)
In a context of having multiple
applications developed using Weblogic Integration and Workshop you might want
to consider an approach that will enable:
-
Re-use of components
-
Co-deployment of multiple applications on the
same Weblogic Domain
This blog focuses on application
architecture of one Workshop/Weblogic
Integration application, meaning one unit of deployment (one ear), having in mind that many
applications can be deployed on a single Weblogic Integration domain. The
proposed application architecture permits:
-
Re-use, maintainability and extensibility of
code
-
Team work
-
Reorganisation of projects with-in an
application from one to multiple applications depending on variability of
sub-elements
Organisation of Workshop projects within
an application can have direct impact on performance tuning as we will see
later in this blog.
I will be presenting this in 3 parts:
-
Application layers and approaches for organising
code into each layer
-
Applying those approaches in a simple example
-
Impact on performance tuning and deployment
Part 1: Application layers and approaches for organising
code into each layer
A good approach when defining application
building blocks is to use logical layers that may later be extended to become
SOA layers.
For complex applications we usually define
three layers as depicted in the picture below. A mediator may be included
between layers consisting of a message-bus like AquaLogic Service Bus. In this
blog we will not be talking about mediation since our primary focus is the
architecture within one application, a single ear, having in mind that this application may be split
lately in the process of development to become multiple applications, each
application exposed as web service becoming an SOA building block. Thereafter a
mediation layer could be used for service-to-service integration, system-to-system
integration being essentially done using Weblogic Integration.
Those layers are related to SOA, they also have
sense in one ear. Thinking like-wise in an application will surely give an
easiest path for providing the building blocks when applying SOA at enterprise
level.
Composite layer: Offers to business partners and external clients access to
services providing necessary transforms, filtering etc. This layer can
aggregate business services coming from the orchestration layer to provide
external access to services adding restrictions, filtering and security. This
layer transforms the canonical XML model, used in the orchestration layer, to
an external simplified business partner adapted model. This layer exposes Web
Services to the external client. This layer may contain page-flows, page flows being
a composition of information. Page flows can be provided as a Web Interface to
business partners or exposed as Web Services using Weblogic Portal and WSRP.
Orchestration layer: This layer contains the Weblogic Integration business processes. The business
processes use a canonical XML data format. This layer is used to orchestrate
many back end systems. Using a canonical model in this layer provide
independence of this layer regarding the layers above and below. This provides
more flexibility and independence whether some decision is made to change a
back end system of to offer adapted services for different business partners.
Connectivity layer: This layer provides access to back-end systems. It provides
transformations from the back-end representation of the data to the canonical
XML data format used in the orchestration layer and vice-versa.
Using a canonical data model in the
orchestration layer is a good approach. It gives independence between the code
of the application and the other systems it connects to. The canonical model
may consist of the UML domain model expressed in XML schemas. Transferring this
XML data between processes should be done via coarse-grained messages. A message consisting of a
composition of objects defined in the UML domain model. The same ideas related
to the DTO pattern (data transfer object) expressed in XML may be a good
starting point.
Using layers does not mean having to go
thru every layer each time. Going for example from the presentation layer to
the connectivity layer, without any components on the orchestration layer, may
be useful. This should be considered depending on the need of reusing the
services exposed on each layer.
Within each layer logical organisation of
code and Workshop projects should be carefully done in order to offer more
flexibility.
Having said that, how would we define
projects in a Workshop application?
A Workshop application consists of many
projects of different types. The type of project can be "Process"
projects containing mainly Weblogic Integration processes, "Web" projects
containing mainly java page-flows, "Controls" projects for controls that
need to be shared between the different projects etc.
So should we have one project per logical
layer? Or should we have more than one project in a logical layer?
My answer is more than one project on each
layer depending on the constraints. And I propose those approaches to help in
the decision making regarding the Workshop projects:
Bottom-up
One approach consist of starting form the
back end systems. For each
back end you should define one or more Workshop projects. We will see later (Part 3: Impact on performance
tuning and deployment) the advantages of having multiple projects. Those projects being of type
"controls" or "process" depending on the needs. If the
back-end will be calling your application using a Weblogic Integration Event Generator
you might want to consider having a process project for this back-end. You may
also want to have processes to apply XQueries transforms in this layer. A good
practice is not to use stateful processes in the Workshop projects of the
connectivity layer.
Then going up you will add processes on the
orchestration layer to orchestrate the different back-ends.
Top-down
Starting form the business needs define the
processes that will represent your business and the canonical XML model that
will be used in the orchestration layer. You might want to consider UML for a
start, converting entities of the domain model to XML "types" and
composition of entities to XML elements (documents). Take care when defining
the documents that will be used as arguments of the processes on this layer.
Decompose your processes in sub-processes
leaving in the main process, representing the business, only the nodes having a
business meaning. All the details should be extracted to sub-processes,
stateless if possible. The only stateful processes should be the one on the
top if possible. Consider versioning those stateful processes from the
beginning.
Assemble the processes related, from a business
analysis point of view, into different Workshop projects. Put all the technical
reusable processes into specific Workshop projects one project per technical
reusable aspect.
Then going down you will add controls or
process projects on the connectivity layer to provide transformation of the
canonical model to the related back-end model.
Meet-in-the-middle
It's a combination of both approaches. It
could be difficult to apply depending on the knowledge of the systems you may
have. It needs a business knowledge coupled with a technical one. In my opinion
it's the best if you can afford having an architect, or a group of architects,
combining the business vision of the application and the technical one. You may
want to focus on a chosen part of the application, covering one significant use
case, and define the first iteration in the development process.
