16/03/2009
ESB.NET's cool loggers now ship with async logging functionality.
A separate IIS AppPool is used for the asynchronous logging capability, so no Windows Service installation is necessary.
Further, each instance gets it's own async logger by default (you can change this to use a centralized logger if you like), so you get complete control of which instances do logging, uninterrupted logging capability as instances are added/removed etc.
Using the existing MSMQ Logging queues (per instance), the simple async logger leverages the existing SQL Log Provider to provide a seamless logging experience between sync. & async logging.
Advantages therefore include running detailed production logging loads [with a suitably scaled SQL Server infrastructure], with a minimal resultant loss of performance.
Also, logging has been officially certified to be compatible with SQL Server 2008.
- Slated features in the next few releases are to include:
*Conditional logging options to allow a detailed logging trace for error scenarios, whilst allowing for a lower [user configurable via standard settings] logging level for non Error conditions
*Another Point & Click WSDL generation XSLT template
config driven Client loading of service handlers for ease of certain development scenarios
*Expansion of Request Re-Mapping filter
*Native DataSet object support in ESBEnvelope for a friendlier support when using ESB.NET as an App Server 5/10/2007
|
Unless SOA, ESB’s and CIM are viewed in light of Business Process Management, Customer Relationship Management and other Business Oriented Benefits.
i.e. How they are to be used to implement/compliment BPM, CRM and add value to the Business, we don’t know what problem we’re addressing, and hence whether we’ve successfully done anything with the ESB and our SOA.
Until an ESB built using SOA principles is used by specific Business Processes and benefits relating to the Business Process are delivered, in areas such as say,
· Business Process implementation
· Agile Business Process Re-Engineering, change of rules etc.
· Insight via real-time Business Activity Monitoring historical data analysis to arrive at meaningful information that can be used to improve Business Process performance
· Customer Relationship Management
· Improved proactive and reactive responses to important Business issues
then whether the SOA and ESB implementation was at all successful cannot even be seriously be contemplated. It just ends up being another part of the generally dizzying array of IT legacy.
The CIM argument is equally useless unless the CIM is understood by the Business users, and used by many Business Processes in order to gain from re-use of the CIM entities & schemas.
SOA should therefore, not be judged by
· whether a particular web service or operation is re-used.
· whether the service is using UDDI or other mechanism to look up the service endpoint.
· how fast it runs a data transformation, or by how it has some pretty drag and drop functionality for doing data mappings.
· how quickly a client can point to an endpoint and invoke the service.
Nor should it be directly judged by compliance to specific standards or how it uses those standards. Standards are a means to an end – they are not the end.
These are technology specific measures. They do not have any direct Business meaning or benefit.
Of course, the more of the above technology specific measures that the SOA implementation adheres to, the more amenable it is to re-use, robustness, productisation etc., so they are obviously all very important technical aspects of an SOA, ESB and CIM implementation.
They do not, however, directly make the SOA/ESB/CIM a success.
It’s whether the Business Perspective’s measures have been met that determines success, not the Technical Perspective’s measures.
At ground zero, here are a number of reasons ESB’s go wrong:
· Do NOT pick a particular Product and bet your ESB on it
· Do NOT pick a Vendor and leave it to them
· Do NOT put a Centralized Physical Layer in the middle of Clients/Services (aka EAI) and expect it to solve all your problems
· Do NOT confuse Logical Models with Physical ESB Models
· Do NOT deliver it as a single project
· Do NOT have a central group responsible for long term delivery, maintenance of the deliverables (Software, Hardware, Network etc. of the ESB).
In essence, there are only a handful of relatively simple things you should do, however, they are instrumental to the success of an ESB initiative, and hence must be done well:
· Specify what services/capabilities you want an ESB to have
o Make up a general list of capabilities that sound right
§ (see OpenStandards Presentation - BPM IMPLEMENTATIONS USING SOA, CIM's AND ESB's for examples)
o Use this list as inspiration to try and identify the capabilities are especially important, useful or “nice to have” in your organization
o Have an ongoing process – this needs to live as long as the ESB lives. The Organization must never lose sight of this list of capabilities. It is the key driver of everything an ESB means to your Organization. Forget about everything else that you’ve ever heard or read about what an ESB is & what it should do etc. For your Organization, this list is ALL that matters.
o Classify the items in terms of priority, and review them periodically as you deliver them, and as the Organization’s requirements evolve over time. Review industry best practices and add the applicable ones to the “one big day” list. This will give you an idea of what you’ve got up your sleeve if something comes out of left field. Move them up/down the priority stack as required. On the “Next To Build” list, aim to have one or two capabilities at a time.
o Only build what you’re going to use. This ensures they are well tested. Ensure they are VERY stable. If not stable, re-visit, re-build and proceed. Unlike any other software in the Organization, the ESB implementation cannot afford to be loose. It must be the leanest, most stable, most understood part of the Organization’s Software assets. For this reason, try to keep it as simple as possible, with each capability having REAL requirements and benefits.
· Have a Committee to manage the common capabilities list. Other features can be added by minority groups and used within their realm (or Service Domain etc.).
· Have implementations of the above capabilities in whatever platforms are strategic for your Organization.
For example
o .NET if you’re a .NET shop
o Java if you’re a java shop
o Both if you’re a both a Java and .NET shop
Anything else viable on whatever platforms you have
o Mobile
o Mainframe
o …
· Use the Internet as inspiration. Leverage as much of Internet related concepts, protocols, software etc. as possible. Don’t come up with your own implementation until you’re sure there’s no equivalent of it in the internet space. This approach helps guarantee your ESB will scale in many ways:
o Multiple stakeholder Buy-In
o Development, Delivery, Operations & Maintenance
o Performance
o Availability
o Sustainability
o Knowledgeable persons, useful & reusable knowledge transfer, easily available (commodity) skill sets
o …
· Treat the ESB as a logical (and very rich & wide) Layer 8 to the ISO’s OSI Network Model. Make it a layer by which any ESB competent node can deliver what functionality is required by the IT department of an Organization.
o That’s what the BUS in the Enterprise Service BUS is intended for. It’s a protocol which when implemented, allows for any node to interoperate with other BUS aware nodes. This may be in a centralized or hierarchical manner, or in a peer to peer manner depending upon the capabilities required & mechanisms chosen.
o A common mistake is to treat an ESB as a central point for applications to connect to. That model quickly encounters scalability & logistics problems. Logically, an ESB layer is one that sits between service providers and consumers. Physically, it should be a layer that allows ESB aware applications to converse. Unfortunately, the OSI model has not been extended to layer 8 as this area of IT has been dominated by application frameworks and vendor technologies. The industry has ripened and the time has come for Organizations to build their own OSI layer 8. Over time, a standard set of OSI Layer 8 specifications and implementations will prevail. The WS-* is a step in this direction, however it is too all-encompassing (focusing more again on delivering existing application level constructs into a Standards-Based set of technologies), and does not deliver on simple, free & pluggable, transparent ESB qualities that Businesses require. We still have disparate messaging, integration and data transformation technologies – because vendors can still make money here. What Businesses would like, however, is to be able to have all their systems have basic capabilities to effectively communicate. Business (especially big Organizations) would be happy to buy (usually at whatever premium) systems that have a standard basic communication capability with other systems. i.e. ESB like qualities baked into applications. Unfortunately, we are nowhere near that. One of the purposes of ESB.NET deployments is to have it sit in front of specific applications and provide this capability.
· In each platform, start with a framework that’s very flexible. Have people that are passionate about each platform working on the ESB framework for that platform.
· Build a platform that can be refined over time, is well understood and is easily changed over time. Try to keep it as simple as possible.
· Have a low barrier to entry (within reason). This obviously ties in with the required capabilities
· To start with, build a single capability in each platform at a time. Obviously, things like connectivity are the most basic and important of all. To lower the barrier to entry, pick standards based protocols as much as possible.
· Avoid niche products, standards, protocols etc. as much as possible. Conversely, you may have to taint some standards or protocols to make them easy or useful to your requirements. Better that than to come up with something completely new.
· Base everything on evolution. Revolution is not required. We’ve pretty much got most of the technologies we need. We just need to apply them sensibly. Undoubtedly, this will be the most difficult task.
· Whenever using a product, search for the capabilities in the above list. Ensure the product is extensible enough to enable you to deliver on the above capabilities.
o Aim high
o Deliver low
o Deliver wide
o Get everyone involved
§ All of IT System Aspects
· Business Stakeholders (the Business needs to know what they’re spending their money on, and what features & capabilities they’re investing in)
· Service Producers
· Service Consumers
· Business Applications/Systems representatives
o Measure/Understand the benefits & progress
o Repeat the above till you have the basics in place. The process should then take care of itself.
· Encourage multiple implementations of the capabilities. Have a reference implementation for one platform and a set of conformance tests that any ESB capability producer should pass.
o An ESB Nirvana would be that ALL systems in your Organization can natively support your ESB capabilities. To that end, aim for lightweight (or possibly even embeddable), distributed & federation capable implementations so that they can be deployed as close as possible to each system in the organization.
· Have STRONG Governance of the ESB capabilities and teams claiming to be delivering the ESB capabilities. Although measurable conformance tests need to be passed, the principles behind the ESB should also be evaluated. Never let a single application or group bully the ESB effort by pushing a particular technology or product. Conversely, the Governance board should be open minded & platform neutral. |
| Copyright ©2006 Minas Casiou, Keystroke IT | 2/09/2005
XSD Schema for defining Business Services at the Business Level, rather than the technical level WSDL.
The ESB.NET Business Service Definition Language (BSDL) is an XSD Schema for defining Business Services at a higher level than WSDL.
Why
Business Services need to be expressed in a manner that is expressly relevant to the service being described and does not include anything that will clutter the service definition.
Business Services aimed at being implemented with a Service Oriented Architecture approach work at this higher level of abstraction. Whether it’s explicit or not, the service definition is at this level.
WSDL is a programming & interoperability level language that does not meet the criteria mentioned. It is too low level and contains a plethora of information irrelevant at this level. In the same way that models can be used to generate source code, BSDL can be used to generate WSDL if required.
What
BSDL is basically an XSD schema that describes the ESB.NET message contents for a particular service. At runtime, it’s definition is expressed as an ESBEnvelope (or other valid ESB.NET Envelope) with the relevant documents and attachments included in the envelope. On the ESB.NET server, the Service Definition can be referenced to enforce any service level rules pertinent to the service.
The image below shows the XSD structure and an example ESB.NET Service Definition for a service.
Basically, it contains a set of nodes that describe the service name, version & description information.
It then specifies the request and response documents relevant to this service, and any related attachments.
Finally there’s service characteristics such as sync/async, priority, transaction, aggregation, availability, acceptable response time and so forth.
There’s also opportunity for further service elaboration, and the ability to specify any important attributes as far as the business is concerned in terms of nodes that should be populated. For example, if you’re using an industry standard XSD that contains many nodes (eg. Acord OLife) and this particular service requires only some of the nodes in that schema, you can choose to highlight any nodes that are say, optional in the Acord OLife XSD, but that you actually need for your service. As such, this service definition acts as a form of formal documentation or a place where you can reference any detailed documentation. Note that the fields such as SpecialRequirementsConstraintsAndComments can be used to reference an external document etc. as required.
The idea is that this definition is to be the primary source of information for services.
As you can see, information such as this is not at all addressed by WSDL, however, using some of the info in this XSD, namely using some of the mandatory nodes in the “Service” node.
Example
Benefits
The benefits of BSDL over straight WSDL are now immediately obvious. There are no deployment level descriptions and method level parameter clutter to confuse the issue & scare away business users.
This information is of course needed at some point, but not at this level, as some of it it changes from environment to environment (eg. Dev/staging/prod etc.). Also, with ESB.NET, there is a single WSDL that takes all these parameters as an ESBEnvelope XML node, so creating a WSDL for each service is not necessary. There’s already a generic one available, although you may wish to create a more specific one for each service if you like, and this would be a straight forward exercise as the parameters are always similar. You may have namespace issues for your proxy classes though but more on that in another article…
Being a pure message based architecture, the information in BSDL focuses on the name and business data for a particular service. All other nodes are optional (with some implied defaults – eg. Synchronous behavior is assumed if not specified).
With this setup, everything you need to describe a service is stored in one place, and if used with ESB.NET, you don’t need to look at WSDL ever again. BPM tools can also build in this abstraction so that invoking services is as simple as pointing to a BSDL and passing in the necessary data (in much the same way as is done with WSDL), except that all services are then alike and changing service invocations is a matter of data manipulation rather than mucking around with WSDL & proxies etc.
23/06/2005
The XQuery below returns the list of records in which the BuildCmdString is zero and duration to execute is greater than 1 second.
When coupled with the up and coming BAM Services Adaptor for ESB.NET, this will provide the functionality to raise alerts on such queries.
eg. Send an alert when you get say 10 or more of these entries appearing etc.
WITH XMLNAMESPACES (
'urn:keystroke-com-au:ESB:Envelope:ESBEnvelope:Version:1-0-3' AS e,
'urn:schemas-biztalk-org:biztalk:BuildCmd2:BuildCmd2' as d
)
SELECT
ResolveName,
Context,
Duration,
RequestXml.query('
data(/e:ESBEnvelope/e:body/e:documentBody/d:BuildCmd2/d:BuildCmdString)') as Result
FROM
ESBLogSummary
WHERE
ResolveName ='BuildCmd2'
and
duration > 1000
and
RequestXml.value
('contains
(string
(
(/e:ESBEnvelope/e:body/e:documentBody/d:BuildCmd2/d:BuildCmdString
)[1]
), "0"
)','bit'
)=1
SELECT count(*)
FROM
ESBLogSummary
WHERE
ResolveName ='BuildCmd2'
and
duration > 1000
and
RequestXml.value
('contains
(string
(
(/e:ESBEnvelope/e:body/e:documentBody/d:BuildCmd2/d:BuildCmdString
)[1]
), "0"
)','bit'
)=1
10/04/2005Serializing and Deserializing XML into Object hierarchies...One of those questions that's been asked a few times on the AusDotNet Mailing list...
Well, here goes...
In order to serialize your object hierarchy into XML, or conversely, if you want to have a nice & easy way to work with XML, convert it into an object hierarchy...you need to do a couple of things...
1)Best way is to start with an XSD Schema (like everything, Contract-First is the best way to go....) for your data. From this, you can use a number of tools to generate correctly annotated classes for you (with .NET, that just means class and property attributes). You can also start with your existing classes, although you'll need to annotate them appropriately (a bit of a pain). For an example of how to do it, generate some classes from an XSD, run them through XSD.exe or XSDObjectGenerator etc. & see what they spit out. If you couldn't be bothered, here's a couple of examples...
System.Xml.Serialization.XmlRootAttribute("ESBEnvelope", [Namespace]:="urn:keystroke-com-au:ESB:Envelope:ESBEnvelope:Version:1-0-3", IsNullable:=False)> _
_
Public Class ESBEnvelopeProvider : Inherits ESBEnvelope.EnvelopeBase
_
'Do not serialize this class...
_
Public Overrides ReadOnly Property XMLSchemaName() As String
'The XMLSchema name of the default document - this is one of the parameters used on the
'ESB server to construct the pipeline for the request
Get
If m_lNumDocs <= 0 Then
Return ""
Else
Return GetDocument(0).GetAsXMLDocument.DocumentElement.Name.Trim
End If
End Get
End Property
...
System.Xml.Serialization.XmlRootAttribute([Namespace]:="urn:keystroke-com-au:ESB:Envelope:ESBEnvelope:Version:1-0-3", IsNullable:=False)> _
_
Public Class attachment : Implements IAttachment
Protected sIndex As String
Protected sFilename As String
Protected sDescription As String
Protected sType As String
'
Public Property index() As String Implements IAttachment.index
Get
Return Trim(sIndex)
End Get
Set(ByVal Value As String)
sIndex = Trim(Value)
End Set
End Property
'
Public Property filename() As String Implements IAttachment.filename
Get
Return Trim(sFilename)
End Get
Set(ByVal Value As String)
sFilename = Trim(Value)
End Set
End Property
'
Public Property description() As String Implements IAttachment.description
Get
Return Trim(sDescription)
End Get
Set(ByVal Value As String)
sDescription = Trim(Value)
End Set
End Property
'
Public Property type() As String Implements IAttachment.type
Get
Return Trim(sType)
End Get
Set(ByVal Value As String)
sType = Trim(Value)
End Set
End Property
End Class
A couple of the tools you can use are:
- XSD.exe - comes with .NET. Disadvantage is that it generates arrays rather than collections.
- XSDObjectGenerator - developed by some of the Microsoft guys that were part of the original BizTalk JumpStart Kit. This is a good compromise between generated class attributes & methods. Some other tools will generate reams of code for each class, & whilst that may be useful for some scenarios, with large XSD's such as the ACORD OLife schema (~500k XSD), that means a lot of code.
Once you've got your classes, you can start populating them. When you want to turn them into XML, use something like the methods below.
Public Function Serialize(byval oObjectToSerialize As System.Object) As String
Dim oSer As System.Xml.Serialization.XmlSerializer
oSer = New XmlSerializer(oObjectToSerialize.GetType())
Dim oMemStream As New MemoryStream
Dim sw As New StreamWriter(oMemStream, New System.Text.UTF8Encoding)
Dim sXML As String
oSer.Serialize(sw, oObjectToSerialize)
sXML = Encoding.UTF8.GetString(oMemStream.ToArray())
oMemStream.Flush()
oMemStream.Close()
Return sXML
End Function
When you want to DeSserialize the XML back into classes, you need to supply the XML string as well as the type of the parent object in the hierarchy.
Public Function DeSerialize(byval sXMLStringToDeSerialize As String, byval tType As Type) As Object
'Deserialize to the original objects
Dim sr As New StringReader(sXMLStringToDeSerialize)
Dim x1 As Object
Dim oSer As System.Xml.Serialization.XmlSerializer
oSer = New XmlSerializer(tType)
x1 = oSer.Deserialize(sr)
Return x1
End Function
The above two methods are pretty much all you need (& you can pretty much halve the number of lines of code if you wish to reduce line count if you're one of those types...). I purposely leave it verbose as it aids in debugging & I'm not too fussed about how many lines of code are there...(Got over that when I stopped using C++ :( ).
Here's a few neat little things you might want to know before you start though...
-
With the XML Serializer, only public properties are serialized. WIth WCF, there's another serializer that can do private properties as well, but it's not the most Contract-First compliant serializer. For maximum portability, stick with the XML Serializer.
-
The XMLIgnore attribute - specifies to not serialize that object (property, class etc.)
-
If you want to write out a node based on a true/false condition...then there's a bit of taxonomy that the XML Serializer looks at to help you ger there. Basically, the naming convention MyPropertySpecified will write out a property called MyProperty if the Boolean property called MyPropertySpecified is set to true. If this value is set to false, then MyProperty will not be serialized.
-
Deserializing Date nodes...If you have a Date node, then it can't be an empty string value in the XML. It must either have a valid date, or the node must not be present in the XML.
Other than that, the attribute details are in the examples above & in the online help etc.
With those few tips, happy Serializing/Deserializing your XML... :) 7/04/2004This is a short summary on how to use ESB.NET to expose your business services as SOA compliant XML Web Services.
In order to create your services to be hosted by ESB.NET, you need to perform the following high level steps.
Definition
Handler (Message/Request Handler)
Adaptor - Project(s) for related set of Handlers
- Create a Service Definition - this is not currently directly used by ESB.NET, however it will be a validation option in future releases.
- Define the name of your service. Feel free to use namespaces etc. This should match the name of the business service required, eg. similar to a Use Case name etc.
- Define the data required for the service, request & response, using an XSD schema. This will be the sole definition of the data. You should aim to do this at the conceptual design phase or even the envisioning phase - i.e. as soon as a Business Analyst starts typing fields into a word document, pull them up & get them to use an XSD tool to define the data. You need only one copy of the data - from requirements to coding & implementation.
- Data Model - If building a standard VB.NET or C# Adaptor and handlers, use a XSD ==> class generator to generate code files from your XSD - such as XSDObjectGenerator. It's advisable to add these files into a separate project. If you're building your adaptor using a tool that does not require code generation from the XSD in order to process the data (eg. BizTalk, Linq), then you can ignore this step.
- Create a request & response message using XSD/XML tools such as Turbo XML, XML Spy or BizTalk etc.and wrap the result in an ESB Envelope, setting Service Parameters as per the Service Definition. Place the request file in the Management Console's Requests directory, creating a directory for your Adaptor. This will then be made available in the Management Console for submitting to the ESB Transport adaptors using the chosen transport adaptor.
- Adaptor - Create a new VS.NET project based on the ESB.NET project template. This is your adaptor (or part of the adaptor if you choose to spread the adaptor over multiple assemblies etc.)
- Service/Controller - Request Handler. Add a Request Handler using the ESB.NET class template. This is the class that will service the request coming in to the system. You will mamipulate/process the data model here as required to imiplement the business service requirements.
- Configure your handler(s) in the ESB.NET Pipeline. Use the Service Definition for the relevant details. You can specify more than one handler here, specify simple handler chaining, request/response in/out etc. here as well as which handler(s) get executed synchronously or asynchronously, and any handlers that need to be executed for each & every request - eg. An auditing handler or a security check (Authorization handler - which will set a flag on the ESB.NET Context telling the ESB.NET Pipeline Manager to abort further Pipeline Processing).
- Using the Management Console, submit the request to the ESB.NET Service bus. At this point, you can use the "view logs" functionality in the management console to view any log messages etc. You can also choose to debug the handler.
- You can also add your request to the list of test requests. This will allow you to do simple regression testing of your services at the press of a button. You may also decide to write test handlers to do more detailed testing of your other handlers, and add the test handlers into this list instead of or as well as your service handlers.
- When happy with the base functionality of your new handler, use the Microsoft ACT script to fire the request off to ESB.NET to stress test ESB.NET & your new handler. You can extend the scripts & use them for regression testing under load.
17/03/2004An example of an adaptor and relevant configuration...
To help you get started with ESB.NET, both from the point of view of verifying the deployment as well as to help you get started adding your own services, there's a test adaptor that ships with ESB.NET.
Steps required to implement a service
After defining our service, there are 3 main items we need to do to setup our service with ESB.NET
- Prepare a Request to send to the service. This is done using any text editor or XSD tool such as Turbo XML, XMLSpy, BizTalk XML Editor etc.
- Create an adaptor and handler - or just add a new handler to an existing adaptor. This is done by creating an assembly implementing a specific interface (IProcessMsg). This can be done by either:
- writing code - where you code up the logic in VB.NET or C# etc.
- configuring in one of the WWF Adaptor handlers and implementing the functionality using WWF assemblies - by using WWF to build the functionality and deploy the
- Configure the handler to handle a particular request (map request to handler). This is done using the InteropPipelineCfg.xml config file.
The ESB.NET Test Adaptor
The test adaptor is a basic one, and is written directly in code using VB.NET. It's purpose is to do nothing much other than get any old message to the service bus, have it routed to a handler and get a response back. It is configured in a few ways to test various basic functions of the ESB.NET service bus. As such, the message is minimalist in nature.
1. Request Message
Navigate to:
...\5.0\5.0.1.0\Source\ESB\Base\Solutions\Main\Management\ESB.Management.Portal\Testing\XMLRequests\ESBCore
and view the file called:
ESBTest1_Sync.xml
It looks somethng like this:
- <<?xml version="1.0" encoding="utf-8" ?>
-
<ESBEnvelope xmlns="urn:keystroke-com-au:ESB:Envelope:ESBEnvelope:Version:1-0-3">
-
<header> <delivery><senderMessageID /><receiverMessageID /><sent /> <callSynchronizationType>0<</< SPAN>callSynchronizationType> <delivery>
-
<manifest>
<document>
<name>BuildCmd2<</< SPAN>name>
<description>Test Document<</< SPAN>description>
<documentNamespace>urn:schemas-biztalk-org:biztalk:BuildCmd2:BuildCmd2<</< SPAN>documentNamespace>
<</< SPAN>document>
<</< SPAN>manifest>
-
<systems> <system><adminID /><systemID>Some System ID<</< SPAN>systemID> <service><name /> <version /> <context /> <description>Test Service</< SPAN></< SPAN>description> </</< SPAN>service>
-
-
-
<BuildCmd2 xmlns="urn:schemas-biztalk-org:biztalk:BuildCmd2:BuildCmd2">
<BuildCmdString>0<</< SPAN>BuildCmdString>
<</< SPAN>BuildCmd2>
<</< SPAN>documentBody>
<</< SPAN>body>
< </< SPAN>ESBEnvelope>
Not all fields are mandatory. In the XML Fragment above, you can see the ESBEnvelope and various header fields.
The most interesting parts are the manifest and the body. The manifest lists the contents of the message, inline XML documents, and any attachments that are transported outside of the ESB Envelope - such as DIME or MTOM etc. or may just be URL's.
The body section contains the core service request data. A similar ESBEnvelope will be used for the response.
In the above case, the document is called: BuildCmd2 (remnants from an remotely operated & automated build process... :) ). It has only one parameter, being the BuildCmdString. This example does not contain much service data as it's for testing core functionality. In general, the body will contain XML data conforming to an XSD, and may be a few hundred lines long. Bigger amounts of XML data, eg, MBytes or hundreds of KBytes, are best included as attachments, so as to minimise handling of large data. For example, handling employee contributions for a superannuation fund, which may contain say, 10MBytes of XML data, is best treated as an attachment, with an inline document specifying any general information about the attachment, as pertaining to the business function. This improves system performance, and also makes it clear as to the business service that is being executed.
2. Adaptor and Handler
Navigate to the following directory in the ESB build.
...\5.0\5.0.1.0\Source\ESB\Base\Solutions\Main\Testing\ESB.Testing.TestTxn
Here you'll find a Service Adaptor (ESB.Testing.TestTxn) containing 2 handlers (TestTxn1.vb and ReturnSpecifiedFileHandler.vb).
These 2 handlers show how to manipulate the ESBEnvelope header properties and how to return an ErrorXML document in the response. They also show how to invoke XSLT functionality. XSLT, much like the Service Handlers, is configured in a config file that contains the path to the XSLT files. An XSLT operation is performed in the Service Handling code by invoking a defined XSLT Service for the particular XSLT operation. This Service is defined in another configuration file - InteropDocumentTransformCfg.xml. Note that in the XSLT configuration, you can chain XSLT operations together. Once the service is setup, the XSLT calling code does not need to change if you change file names or if you need to do multiple XSLT operations etc.. Lines 1-10 show how to call the XSLT Service in code.
If oEnv.GetCustomParam("ESBCore", "XsltTest") = "1" Then
Try
'do some xslt testing...
'Dim oContext As ESB.Core.Interfaces.ServerContext.IServerContext
Dim sResolveName As String = "TestResolveName"
Dim sContext As String = "TestContext"
Dim sXmlToTransform As String = oEnv.GetDocument(0).GetAsString()
Dim sTransformResult As String
'CType(ESB.Core.Services.ContextManager.getContextManager(True).GetExistingContext, IServerContext).Transform(sResolveName, sContext, sXmlToTransform, sTransformResult)
GetContext.Transform(sResolveName, sContext, sXmlToTransform, sTransformResult)
If ShouldLog(LogDefs.eLogLevel.eLOG_DATAXFER) Then : LogMsg(eLogLevel.eLOG_DATAXFER, "sTransformResult=" & sTransformResult) : End If
oEnvRs.AddDocument(New InlineDocument(sTransformResult))
Catch ex As Exception
ExceptionManager.Publish(ex)
LogError(eLogLevel.eLOG_ERROR, ex.tostring)
End Try
End If
If oEnv.GetCustomParam("ESBCore", "ConfigTest") = "1" Then
Try
'do some Config Application Block testing...
'Dim oContext As ESB.Core.Interfaces.ServerContext.IServerContext
Dim sTmp As String
GetConfigData()
sTmp = m_oCfgData.ContextManager.ClientContextManagerObjectImplementation.AssemblyPath()
Dim oWarningEntry As New ErrorXML.WarningEntry
With oWarningEntry
.Code = "testcode"
.Description = "if you get this message then the test txn worked."
.Description = .Description & "ConfigTest Value=" & sTmp
.Source = System.Reflection.Assembly.GetExecutingAssembly.ToString
End With
oErr.WarningEntry.Add(oWarningEntry)
If ShouldLog(LogDefs.eLogLevel.eLOG_DATAXFER) Then : LogMsg(eLogLevel.eLOG_DATAXFER, "sTmp=" & sTmp) : End If
Catch ex As Exception
ExceptionManager.Publish(ex)
LogError(eLogLevel.eLOG_ERROR, ex.tostring)
End Try
End If
If oEnv.Context = "TestAddToPipelineTransitionData" Then
Dim sPTD As String = oEnv.GetCustomParam("ESBCore", "TestAddToPipelineTransitionData")
Try
Dim oWarningEntry As New ErrorXML.WarningEntry
With oWarningEntry
.Code = sPTD
.Description = "PipelineTransitionData instance " & sPTD
.Source = System.Reflection.Assembly.GetExecutingAssembly.ToString
End With
oErr.WarningEntry.Add(oWarningEntry)
Catch ex As Exception
ExceptionManager.Publish(ex)
LogError(eLogLevel.eLOG_ERROR, ex.tostring)
End Try
The code below is an excerpt from the SAP Adaptor. It shows how you would get a business document out of the ESBEnvelope (Line 2).
Excerpt from SAP Adaptor - EnqPOSummaryDetails service handler
- m_oPlgRs =
New PurchaseOrderSummaryRs.PurchaseOrderSummaryRs
m_oPlgRq = oEnv.GetDocumentAsObject(GetType(PurchaseOrderSummaryRq.PurchaseOrderSummaryRq))
m_oPlgRs.PONumber = m_oPlgRq.PONumber
GetPOItemsFromSAP()
'Create a response envelope using the request envelope as a starting point. This preserves routing information etc.
'but strips out the original documents, attachments & relevant manifest entries.
oEnvRs = oEnv.CreateResponse()
'Add the response document to the response envelope
oEnvRs.AddDocument(New InlineDocument(m_oPlgRs))
Return oEnvRs
3. Configuration
As you can see above, the services request and the service handler are defined separately. This step is where we tie in steps 1 & 2. i.e. marry the Service Request to the Service Handler(s) that implement the service. The Request and Handlers are decoupled in this way. Because of ths decoupling, a service can change implementation without the client having to change. The client will only need to change if the Request or Response require changes in the data being transferred.
You can swap out adaptors/handlers implementing a particular service without restarting the service bus.
The generic interface of the service bus makes it a simple task for a BPM tool to call into any ESB.NET based service, and then re-map the service calls within the tool, as only the business data for a particular request needs to be considered on the BPM tool side.
To view the configuration entries, navigate to the following directory in the ESB build.
..\5.0\5.0.1.0\Source\ESB\Base\Solutions\Main\Configuration\XMLConfigFiles
Open up InteropPipelineCfg.xml
This file contains the mappings between service request and implementation.
A mapping entry consists of the addition of a PipelineEntry into this file. An example of a simple PipelineEntry is shown below.
The Context and ResolveName are the keys into the service handler.
The Context is a concatenation of the ESBEnvelope Service fields. In our example, it's left blank.
The Context is derived as follows for the ESBEnvelope:
[SystemType][SystemVersion].[Context].[ServiceType][ServiceVersion]
Note the periods between some of the fields.
The reason for this is that ESB.NET can support custom envelopes. Out of the box comes support for the BizTalk Jumpstart Kit envelope - the JSKEnvelope. It has a different mapping to the ESBEnvelope as it has a different set of fields in the envelope header.
This scheme can be fulfilled by custom envelope implementations and the one PipelineEntry configuration can then be used to handle all envelopes. This is addressed by the Envelope's IEnvelopeProvider implementation. Each envelope has it's own scheme for this mapping. Fortunately, there is seldom need to implement your own EnvelopeProvider, so this is less of a problem in real life Note that an EnvelopeProvider model is the preferred method of supporting multiple envelopes as opposed to XSLT, as it encapsulates all the issues related to different envelopes.
The ResolveName is the name of the primary document in the ESBEnvelope.
The MultiLevelOverrides node is used to define a handler for this PipelineEntry. In the example below, the ESB.Testing.TestTxns.TestTxn1 class is the handler specified to handle the request for this entry. You can have multiple PipelineEntry nodes with the same key fields. This is how you specify multpile handlers being executed for a particular request. There are also some parameters to specify whether you want to chain the handlers together using the original request or the outpur of the previous handler etc., whether to execute a particular handler asynchronously, and which queue(s) you want responses to go to.
There are also properties to keep a list of handler inputs/outputs in case you want to create more cohesive handlers.
- <
PipelineEntry>
<ResolveNameEntry>
<ContextEntry>
<Context></< FONT>Context>
<ResolveName>BuildCmd2</< FONT>ResolveName>
<PipelineID>1</< FONT>PipelineID>
<ProcessInParallel>0</< FONT>ProcessInParallel>
<ResponseIsRequestForNextPipelineItem>1</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<RequestQ />
<TransactionComponent>ESB.Testing.TestTxns.TestTxn1</< FONT>TransactionComponent>
<UseObjectBroker>0</< FONT>UseObjectBroker>
<ObjectBroker></< FONT>ObjectBroker>
<ObjectBrokerServer />
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
</< FONT>ResolveNameEntry>
</< FONT>PipelineEntry>
Below is a more complex example. It consists of 4 Handlers executed sequentially to implement a service.
The first writes some data to a database, the second does a generic XSLT operation, the third kicks off a BPM process and the fourth updates a database.
-
- <
PipelineMapSection>
<PipelineEntry>
<ResolveNameEntry>
<ContextEntry>
<Context>Staffware10i..StartCreateClaimCase</< FONT>Context>
<ResolveName>WfMessage</< FONT>ResolveName>
<PipelineID>1</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>0</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<ComponentServer suffix="yes">LobSystems\Staffware\Source\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims\bin\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims.dll</< FONT>ComponentServer>
<TransactionComponent suffix="yes">CopyRequestToDatabase</< FONT>TransactionComponent>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Staffware10i..StartCreateClaimCase</< FONT>Context>
<ResolveName>WfMessage</< FONT>ResolveName>
<PipelineID>2</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>1</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<ComponentServer suffix="yes">LobSystems\Staffware\Source\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims\bin\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims.dll</< FONT>ComponentServer>
<TransactionComponent suffix="yes">TranslateAcordToWfXml</< FONT>TransactionComponent>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Staffware10i..StartCreateClaimCase</< FONT>Context>
<ResolveName>WfMessage</< FONT>ResolveName>
<PipelineID>3</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>1</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<TransactionComponent>ESB.Adaptors.Application.Workflow.Staffware.CreateProcessInstanceRequestTxn</< FONT>TransactionComponent>
<ComponentServer suffix="yes">LobSystems\Staffware\Source\ESB.Adaptors.Application.Workflow.Staffware\bin\ESB.Adaptors.Application.Workflow.Staffware.dll</< FONT>ComponentServer>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Staffware10i..StartCreateClaimCase</< FONT>Context>
<ResolveName>WfMessage</< FONT>ResolveName>
<PipelineID>4</< FONT>PipelineID>
<MultiLevelOverrides>
<ComponentServer suffix="yes">LobSystems\Staffware\Source\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims\bin\ESB.Adaptors.Application.Workflow.Staffware.AcordClaims.dll</< FONT>ComponentServer>
<TransactionComponent suffix="yes">UpdateDatabaseWithCaseID</< FONT>TransactionComponent>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
</< FONT>ResolveNameEntry>
</< FONT>PipelineEntry>
The following example is still more complex, and shows off many of the ESB.NET features.
It consists of 4 handlers implementing the unrelated tasks required to process claims forms scanned in and have been OCR'd etc. to extract some key information.
The first handler invokes a claims processing system to inform it of a new claim having been lodged. This is a generic handler, and has been built to further invoke a series of XSLT operations via some custom parameters passed to the handler on a per request basis. The XSLT services are defined in the InteropDocumentTransformCfg.xml file. The XSLT services are defined in the section below.
- <Custom>
- <
ParamName>XSLTResolveNameAddressIN</< FONT>ParamName>
- <
ParamValue>XSLTResolveNameAddressINValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTContextAddressIN</< FONT>ParamName>
- <
ParamValue>XSLTContextAddressINValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTResolveNameAddressOUT</< FONT>ParamName>
- <
ParamValue>XSLTResolveNameAddressOUTValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTContextAddressOUT</< FONT>ParamName>
- <
ParamValue>XSLTContextAddressOUTValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTResolveNameAddClaimIN</< FONT>ParamName>
- <
ParamValue>XSLTResolveNameAddClaimINValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTContextAddClaimIN</< FONT>ParamName>
- <
ParamValue>XSLTContextAddClaimINValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTResolveNameAddClaimOUT</< FONT>ParamName>
- <
ParamValue>XSLTResolveNameAddClaimOUTValue</< FONT>ParamValue>
- </< FONT>Custom>
- <
Custom>
- <
ParamName>XSLTContextAddClaimOUT</< FONT>ParamName>
- <
ParamValue>XSLTContextAddClaimOUTValue</< FONT>ParamValue>
- </< FONT>Custom>
The second handler is a message router. It asynchronuosly <ProcessInParallel>1</< FONT>ProcessInParallel> forwards the request (in this case containing attachments) to a dedicated ESB.NET instance on another server, which has an image processing handler configured. This ESB.NET instance queues the request and processes it in due time. This is a CPU intensive and low priority task.
Note that the async processing here is async amongst handlers. The client request dictates whether the client<=>server interaction is synchronous or asynchronous, and where responses are to go if it's asynchronous. This is done via the <callSynchronizationType>0</< FONT>callSynchronizationType> node in the request envelope. Responses are usually sent to the URL specified in the <from><address></< FONT>address> node in the request, however can be further controlled in the server side service definition.
The third handler, creates a standards based Workflow request, based upon the original business process oriented request, with the intent to forward it off to the next handler which will invoke the Workflow Server. The <ResponseIsRequestForNextPipelineItem>1</< FONT>ResponseIsRequestForNextPipelineItem> tag will ensure that the output of this handler is used as the input for the next handler.
The fourth handler merely invokes the workflow server via a standards based (WfXml) workflow message.
-
- <
PipelineEntry>
<ResolveNameEntry>
<ContextEntry>
<Context>Claims1.0..CreateClaim</< FONT>Context>
<ResolveName>OLifE</< FONT>ResolveName>
<PipelineID>1</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>0</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<ResponseIsOverallPipelineResponse>1</< FONT>ResponseIsOverallPipelineResponse>
<ComponentServer suffix="yes">LobSystems\Figtree\Source\ESB.Adaptors.Application.Figtree\bin\ESB.Adaptors.Application.Figtree.dll</< FONT>ComponentServer>
<TransactionComponent>ESB.Adaptors.Application.Figtree.CreateClaim</< FONT>TransactionComponent>
<Custom>
<ParamName>XSLTResolveNameAddressIN</< FONT>ParamName>
<ParamValue>XSLTResolveNameAddressINValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTContextAddressIN</< FONT>ParamName>
<ParamValue>XSLTContextAddressINValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTResolveNameAddressOUT</< FONT>ParamName>
<ParamValue>XSLTResolveNameAddressOUTValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTContextAddressOUT</< FONT>ParamName>
<ParamValue>XSLTContextAddressOUTValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTResolveNameAddClaimIN</< FONT>ParamName>
<ParamValue>XSLTResolveNameAddClaimINValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTContextAddClaimIN</< FONT>ParamName>
<ParamValue>XSLTContextAddClaimINValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTResolveNameAddClaimOUT</< FONT>ParamName>
<ParamValue>XSLTResolveNameAddClaimOUTValue</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>XSLTContextAddClaimOUT</< FONT>ParamName>
<ParamValue>XSLTContextAddClaimOUTValue</< FONT>ParamValue>
</< FONT>Custom>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Claims1.0..CreateClaim</< FONT>Context>
<ResolveName>OLifE</< FONT>ResolveName>
<PipelineID>2</< FONT>PipelineID>
<ProcessInParallel>1</< FONT>ProcessInParallel>
<ResponseIsRequestForNextPipelineItem>0</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<RequestQ>MSMQ:.\private$\ESBRequestQ</< FONT>RequestQ>
<TransactionComponent>ESB.Core.Adaptors.Transport.RequestHandlerProxy.Sender</< FONT>TransactionComponent>
<ComponentServer suffix="yes">Base\Solutions\Main\TransportAdaptors\ESB.Core.Adaptors.Transport.RequestHandlerProxy\bin\ESB.Core.Adaptors.Transport.RequestHandlerProxy.dll</< FONT>ComponentServer>
<Custom>
<ParamName>OverrideDestinationServerURL</< FONT>ParamName>
<ParamValue>http://asp02s01c11a01vm.aunz.Keystroke.com/ESB/ClaimsPh2/CoreInternetTransportAdaptors/ESBSoapRpcTransport.asmx</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>OverrideTransportType</< FONT>ParamName>
<ParamValue>SOAP</< FONT>ParamValue>
</< FONT>Custom>
<Custom>
<ParamName>EnvelopeType</< FONT>ParamName>
<ParamValue>E3</< FONT>ParamValue>
</< FONT>Custom>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Claims1.0..CreateClaim</< FONT>Context>
<ResolveName>OLifE</< FONT>ResolveName>
<PipelineID>3</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>1</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<ComponentServer suffix="yes">LobSystems\Facade\Source\ESB.Adaptors.Application.Facade.Claims\bin\ESB.Adaptors.Application.Facade.Claims.dll</< FONT>ComponentServer>
<TransactionComponent>ESB.Adaptors.Application.Facade.Claims.CreateWfXmlDocumentFromOLifEDocument</< FONT>TransactionComponent>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
<ContextEntry>
<Context>Claims1.0..CreateClaim</< FONT>Context>
<ResolveName>OLifE</< FONT>ResolveName>
<PipelineID>4</< FONT>PipelineID>
<ResponseIsRequestForNextPipelineItem>0</< FONT>ResponseIsRequestForNextPipelineItem>
<MultiLevelOverrides>
<TransactionComponent>ESB.Adaptors.Application.Workflow.Staffware.CreateProcessInstanceRequestTxn</< FONT>TransactionComponent>
<ComponentServer suffix="yes">LobSystems\Staffware\Source\ESB.Adaptors.Application.Workflow.Staffware\bin\ESB.Adaptors.Application.Workflow.Staffware.dll</< FONT>ComponentServer>
</< FONT>MultiLevelOverrides>
</< FONT>ContextEntry>
</< FONT>ResolveNameEntry>
<MultiLevelOverrides>
<ResponseIsOverallPipelineResponse>0</< FONT>ResponseIsOverallPipelineResponse>
</< FONT>MultiLevelOverrides>
</< FONT>PipelineEntry>
9/02/2004Why use ESB.NET to expose SOA compliant services?
This is a summary on how ESB.NET exposes your business services as SOA compliant XML Web Services, and the advantages over exposing your services as standard Web Services.
Pure Internet Standards based Lightweight Enterprise Service Bus
ESB.NET is a lightweight Enterprise Service Bus, capable of several enterprise architecture roles such as exposing business services, rudimentary publish/subscribe, EAI, providing layering & partitioning of complex systems and exposing workflows to aid BPM. This article discusses only how ESB.NET exposes SOA compliant services for your developed business services. ESB.NET uses only Internet Standards based Transports and Data representations (i.e. HTTP, SOAP, XSD etc.). This guarantees interoperabililty across all platforms.
It does this by hosting Adaptors, and providing several key aspects of server based enterprise application such as
- exposing internet standard endpoints - eg. XML Web Services
- defining a generic and extensible messaging envelope
- providing extensible instrumentation & logging, hot-configuration & caching (using MS application blocks)
- a simple Web based Management Console to manage system parameters, view logs etc.
There is nothing revolutionary about ESB.NET. It just puts a bunch of technologies & patterns together, sets some simple interfaces that need to be adhered to by clients and adaptors, and then does the rest.
ESB.NET Pipeline
ESB.NET uses a configurable pipeline to allow you to plug in your functionality using custom Adaptors (including hosting Windows Workflows to implement more complex logic). Once you configure your adaptor's message handlers to listen for a specific request, ESB will match up the request with the appropriate handlers that need to be executed. As such, you avoid the necessity for creating and managing a myriad of WSDL's.
ESB messages are XSD document centric. There is a request message and a response message (containing a special document in the case of async requests which are accomplished in 2 ways). You can also have attachments, and they are transferred according to the Transport chosen (eg. Raw HTTP, SOAP - WSE 2, SOAP - WSE 3, SOAP - WCF). All Transports are available simultaneously.
Security is left to the Transport chosen Adaptor. This ensures ESB.NET does not provide any redundant functionality that Transport Adaptors provide. As such, if you have differing security requirements per service, you will need to have multiple instances of ESB.NET configured and configure the transports accordingly.
Further, ESB.NET mandates a few simple and common restrictions:
- Adaptors and Handlers must be stateless
- Must contain XSD compliant documents for the requests & responses (non XML data can be passed around as attachments)
- All Incoming Requests should be the Front Door only - i.e. through the Internet Standards based Transports provided. You can add your own, so long as they're Internet Standards based. Adaptors should be used to communicate to non Internet Standards based systems (eg. COM+, RMI, CORBA etc.)
- Course grained messages
This simple architecture, seemingly restrictive (single WSDL etc.), provides a basic seperation of concerns between service (Business data and logic implemented by service), and how the service is deployed, exposed and invoked.
Service Definition
ESB.NET exposes a higher level Service Definition than does WSDL, as WSDL is a low level description language. Once a standard message and set of parameters has been set, WSDL is no longer required for defining the service (it can probably be automatically generated using the information in the ESB.NET Service Definition if required). The ESB.NET Service Definition exposes some high level information such as:
- Service Name
- Request & Response XSD's that the data must conform to.
- Any attachments
- Synchronous/Asynchronous behaviour to clients
- Priority of message
- Transactional and Gauranteed only once message delivery characteristics of the Client-ESB.NET interaction (WCF only)
With these restrictions in place, it is now possible to integrate any piece of software (EAI - although only at Internet Standards Protocols level. Use adaptors for other protocols etc. or interface to BizTalk, eGate, WebMethods etc. for any more complex EAI type work). With that problem solved, in a lightweight manner, we can now focus on plugging pieces together, exposing everything in a generic manner, as the Business Level, by specifying 3 key things:
- Business Service Name
- Business Service Data
- ESB.NET Server URL
These are the core constituents of the Service Definition, and are pretty much what's required to specify what we want done (Service name & data), and where we want to get it done (URL).
This makes life easy for BPM tools & brings the idea of the Business defining their process in the BPM tools, one step closer. In your BPM tool, you can abstract away many details of outgoing calls as they now all look the same. Pretty much only the data required at the business level changes.between requests. An ESB.NET facade cluster can be setup to be the first port of call for any request, and route it (content based routing implemented through confguration - no coding required unless you really want to) accordingly. Alternatively, you can setup a static Pub-Sub ESB.NET instance (or cluster...) to make the routing more flexible/complicated. Static Pub-Sub is an extension of the simple forwarding facade and involves only additional request configuration to achieve.
The pattern above can be implemented in pretty much any platform. ESB.NET is the .NET implementation. A J2EE or MONO implementation & seemless integration for example are entirely possible & feasible.
Isolated Service Provisioning, Transparent Service Consolidation
As you can see, the possibilities start to become limitless. Multiple ESB.NET instances can be scattered around, and joined at a later point in time, forming central/aggregation points for services. Live message tracing can allow administrators to understand the location of services and thus get a clear picture of what can be consolidated as time goes on/new services are deployed etc.
A typical issue in an enterprise & an extended enterprise, is the proliferation of unrelated, non-interoperable services. Web Services & Basic Profiles alone, cannot provide the flexibility described above. Some rigidity needs to be introduced. This comes at a price, however, that being the abovementioned restrictions. When taken in context, they are a small price to pay for Enterprise Service Flexibility (ESF).
Low priced (or free) ESB's such as ESB.NET help lower the barrier to entry to Enterprise Service Flexibilty. Cross-platform availability of something like ESB.NET is required to make ESF even a dream. 24/05/2003
|
The diagrams below show 2 main architectural diagrams relating to SOA based design of an Organization's internal infrastructure.
1 - The main components/services of an ESB (whether distributed or not - eg. BizTalk, webMethods are monolithic type ESB's). Distibuting these components makes the deployment more flexible. For example, if you have huge amounts of transformation loads, you can setup a load balanced cluster for that specific task, or if you have no need for any transformation (eg. new businesses or business areas starting up with little integration work required intially) work, then you can leave that component out altogether.
Also, the various functions can be tied together as required in a pure distributed architecture. For example, the configuration below depicts a considerably featured ESB consisting of BPM/Workflow, Process Step Services (PSS) to carry out software tasks for the Business Process Steps. Orchestrations that can be developed separately to the PSS if required - eg.PSS may be developed in .NET and orchestrations may be develped in JBPM, Windows Workflow, webMethods Modeler and BizTalk Orchestrations. They may just be other Web Services or lower level components.
Pub-Sub may also get invoked for various PSS, and various XSLT or other services be invoked along the way.
All along, using ESB.NET as the ESB Execution Engine Core, all of the below scenarios are easily and consistently realizable, with a centralized data store for request level tracing across all ESB instances - an otherwise daunting task in the case of a distributed ESB. The lightweight nature of ESB.NET means that multiple instances can easily be configured (via copy & paste deployment and an IIS Virtual Directory using the simple deployment scripts) to run on a single or multiple servers.
Single entry points for all services - via both the facade ESB and the single entry point used by ESB.NET for all requests, means that reconfiguring the ESB is a trivial exercise. Just copy the instance over, and change a single URL.
Even in a federated service router scenario, a simple custom router handler can be built to route requests to the various servers as desired. You can even have this custom router map to DNS if you like to make the service federation & distribution management tied to your corporate or extranet based DNS servers.
2 - How services can be federated for enterprise-wide management yet distributed amongst appropriate Business Domains.
Partner Specific Trading, Common Information Models are out of Scope for this purpose
|
| |
|
|
|
|