Hi,
As I've mentioned in my previous posts, my team at Clalit Health
Services is in charge of all interfaces in Clalit's hospitals and community
clinics.
These days we work on a migrate process from BizTalk 2010 to
TIBCO BW 6.
That actually means developing all organization interfaces from
scratch.
PROBLEM BACKGROUND
TIBCO BW 6 is a brand new product, so we have spent a lot of hours figuring
how exactly we should work with it. Of course we ran into some product bugs
(TIBCO were really helpful and even fixed some in later versions), but the big
question was how to build a SOA environment (services has to be loosely-coupled).
For instance, let's say "Service A" needs to use "Service
B".
"Service A" should have the option to invoke "Service
B" by consuming its wsdl (using "Binding Reference"), but do NOT
invoke "Service B" process directly (using "Process
Binding").
"Binding Reference" advantages:
1.
"Service A" and "Service
B" are loosely-coupled, and there is more control over the messages
being passed (because the use of SOAP - via JMS or HTTP). All of our
TIBCO services are exposed with JMS, and SOA allows full control on the
messages going in and out from queues.
2.
An easy deploy after a change in service functionality. A change in service functionality will only affect the
deployment package of the service itself. After deploying a changed service again, all other
applications invoking it with "Binding Reference" would use the new service functionality.
"Process Binding"
(tightly-coupled services) disadvantages:
- There is no control over messages being sent from one to another (because they are sent using TIBCO internal engine and not with SOAP).
- When a service process gets changed – you would have to redeploy all applications that refer to it with "Process Binding" (because the service functionality is included in each application deployment package).
TIBCO Project types
TIBCO 6 project types:
Shared Module
A unit of shared resources.
In a short brief, whenever you want to share some resources across application modules – use should put them inside a "shared module" project.
(TIBCO doc: https://docs.tibco.com/pub/activematrix_businessworks/6.2.0/doc/html/GUID-FF60A1AA-4859-4E5F-A353-71DB4704FB5A.html)
Application
Module
Application module is actually a shared module, but without the
"sharing" part.
In contrast to shared modules, application modules cannot
export its functionality.
Each application module can use (include) several shared modules.
(TIBCO doc: https://docs.tibco.com/pub/activematrix_businessworks/6.2.0/doc/html/GUID-AC119968-4F28-4ECA-878B-4EB251B70444.html)
Application
Contains the deployment package.
(TIBCO doc: https://docs.tibco.com/pub/activematrix_businessworks/6.2.0/doc/html/GUID-B09ABEE9-C6AD-4053-AB00-D6677F7DC2C9.html)
WSDL Types
Abstract wsdl
A contract of each TIBCO process (service). Create an
abstract wsdl when you develop a TIBCO process (service). It contains input,
output and fault operations (each defined by an external or inline schema) for
the process.
Concrete wsdl
Used for consume of a TIBCO process
(service), because it contains a definition of "PortType". Create a
concrete wsdl after you finish developing a TIBCO process that needs to be
exposed (service).
You can set several types of concrete wsdl:
1.
Concrete wsdl which embed
its abstract wsdl
A concrete wsdl has to know its abstract
wsdl. You can actually embed a service abstract wsdl inside its concrete wsdl.
Why not? Whenever the service abstract wsdl
would change during development, then you will have to regenerate (or change)
the concrete wsdl as well.
Instead, hold inside the service concrete
wsdl a reference to the service abstract wsdl using "wsdl:import" tag.
For instance:
<wsdl:import namespace="http://myns.com/WSDL/TibSrv_Cache.wsdl"
location="TibSrv_Cache.wsdl"/>
("TibSrv_Cache.wsdl"
is the abstract wsdl)
2.
Concrete wsdl which embed
schemas
A concrete wsdl can contain all required
schemas definitions in it.
Why not? If schema is defined more than once
(For instance: inside a .xsd file and inside a service wsdl) in the same
project, it will cause namespace collisions.
Instead, hold inside the service abstract
wsdl a reference to the required schemas by adding "wsdl:types" and
"xsd:import" tags.
For instance:
<wsdl:types>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import
namespace="http://myns.com/Schemas/Fault" schemaLocation="../Infrastructure/tibco.infrastructure.shared/Schemas/Fault.xsd">
</xsd:import>
</xsd:schema>
</wsdl:types>
3.
A light-weight service
concrete wsdl which holds a reference to its abstract wsdl.
As you probably realized from 1 & 2
paragraphs – use option 3.
NOTES:
1. Writing reference links (locations) in an
abstract or a concrete wsdl isn't enough.
All resources required for a
concrete wsdl (abstract wsdl resource) and an abstract wsdl (schemas resources),
should be placed in the same project.
2. Generate a concrete wsdl with embedded abstract wsdl and schemas for other clients (like .NET, JAVA etc.) that needs to invoke a TIBCO BW service.
Implementation
Use shared modules to create a small "expose" unit for each
service.
For instance: Creating an "expose" shared module for Service
A.
"Service A shared module" would contain a concrete wsdl, an
abstract wsdl and schemas.
As mentioned before, the concrete wsdl reference to the abstract wsdl, which reference to the
schemas.
If "Service B" wants to invoke "Service A" - it
would add "Service A" shared module to its service appliaction module.
Environment architecture diagram:
Application C, Application D – represents typical TIBCO applications with processes that doesn't exposed as a web-service.
ESB Service A, ESB Service B – represents typical TIBCO applications
with processes that exposed as a web-service.
ESB Service A shared module – Contains shared resources of ESB Service A
(its abstract wsdl, concrete wsdl and schemas). Basically, it's all resources
that Service A concrete wsdl needs.
ESB Service B shared module – Contains shared resources of ESB Service B
(its abstract wsdl, concrete wsdl and schemas). Basically, it's all resources
that Service B concrete wsdl needs.
Infrastructure shared module – Contains shared resources across ALL
modules (for instance: fault schemas, trace schemas, infrastructure
sub-processes etc.).
Diagram explanation:
1 - "ESB Service A"
includes "ESB Service A shared module" –
The service process inside "ESB Service A" application module
needs its abstract wsdl and schemas resources from "ESB Service A shared
module".
3 - "ESB Service A"
includes "ESB Service B shared module" –
"ESB Service A" wants to invoke "ESB Service B", so
it needs "ESB Service B" concrete wsdl (placed in "ESB Service B
shared module").
2 - "ESB Service A"
includes "Infrastructure shared module" –
"ESB Service A" needs to use global resources.
For instance: process which uses a shared trace schema.
4 - "ESB Service A shared
module" includes "Infrastructure shared module" –
"ESB Service A shared module" needs to use global resources.
For instance: if the abstract wsdl points to a shared fault schema.
Application "Includes" example:
How to consume service in the process ?
After including a service shared module project, just use
"Invoke" shape in the process.
Choose "Binding Reference",
then the service abstract wsdl and at last add a SOAP binding.
Under "WSDL Port:" choose the service port type (which is defined in the concrete wsdl).
