Me, myself and WebSphere

DataPower as a REST Gateway (or "OMG, all those rules...")

Offline Marcações: rest ibm-champion api datapower ibmchampion crud 2.071 Visualizações

When you start out creating a Multi-Protocol Gateway (MPGW) or a XML Firewall (XMLFW) to handle REST based API calls you soon realize that you will end up with a ton of Rules and quite complex Matching Actions and you also probably will have a hard time sorting them correctly (not to mention trying to match Response rules and Error rules to the mess).

Well, DataPower was never really intended for REST/CRUD operations but relied on SOAP/XML as POST or GET only so there is bound to be some "mess" in there implementing CRUD operations...

You will also probably note that you are reusing a lot of Actions/Code between all the rules. You have the option of "Reusable Rules" using the Call Processing Rule to alleviate this but IMHO this becomes quite messy, especially if you have many rules and it can also become difficult to update as you don't know what Rule is called where.

Instead, I normally take one of two options which I call, "Reusable Service" or "Switch Action" (and, yes, I've made up those names myself so you won't find it in the DataPower documentation)...

The "Reusable Service" is something I have implemented for many customers and I normally use a XML Firewall in Loopback for it (but a MPGW will work too). You can have many different functions in there, e.g. logging, transformation, validation, etc. and then you have a "simpler" URL-Open() call to this service in each rule. You can lock down the XMLFW to only listen to 127.0.0.1 and thus make it isolated. This will still force you to add the call to each and every Rule but maybe you can add the URL-Open() to an existing GWS or shared script to make it a little bit less arduous...

The other (better?) approach which I have used for "REST" based gateways is to code a "Switch Action". You then set fewer rules (or maybe even just one) but I try to have one rule per HTTP Method and then in the first Action I add a GWS which (can log via "Reusable Service") looks at the URI (normally) and/or Header and run a Switch() to load a specific GWS module. Each GWS Module is named according to the Switch() so it is easy to keep track and the "Switch modules" can call other shared modules in turn making your code cleaner (and smaller). The advantage of this is of course fewer rules and more efficient code but you loses some oversight (graphically) but as you have the modules separated matching your previous Rules you can get a grasp just by looking at the GWS files included. If you add one GWS directory per Service/Method/Rule you'll have an even easier task over viewing (or adding) code.

local:///GWS/MyMPGWRestGW/index.js  <-- This is your main script
local:///GWS/MyMPGWRestGW/POST/createSomething.js
local:///GWS/MyMPGWRestGW/POST/createSomethingElse.js
local:///GWS/MyMPGWRestGW/PUT/updateSomething.js
local:///GWS/MyMPGWRestGW/GET/fetchMeSomething.js
local:///GWS/MyMPGWRestGW/DELETE/deleteSomething.js
local:///GWS/MyMPGWRestGW/HEAD/echoSomething.js

In a DataPower firmware released sometime soon I hope (there is an open demo already) we will get a new service called "API Gateway" which might be usable in these kinds of scenarios. I don't have much information that I can share but if you grab the demo (a Docker setup) you can access the DataPower running it and see the new API Gateway service in action: https://github.com/ibm-apiconnect/apigateway-experimental

With that in mind there might be better tools for us soon to create these kinds of scenarios... NB! Note the MIGHT as we can't know what will actually be released or if we can use it as a Service or if it will be dedicated for API Connect only!

Modificado por Offline

DataPower 7.6 throws a GatewayScript Prototype.js error?

Offline 2.274 Visualizações

As I have received a few calls/questions about a breaking change in DataPower Firmware version 7.6 I figured to send this out as a “helper” in case you encounter issues after upgrading/installing 7.6.

The change has to do with objects called “prototypes” in GatewayScript and a requirement to add security to not allow alteration of prototypes in the runtime of GatewayScript.

As alteration of prototypes are quite common in many Node.js packages there is a high risk that you will see these kinds of errors after an upgrade. Affected Node.js packages I have run into this far are for example, OpenPGP.js, XML-XPath, XML-Dom, s-mime-parser-js. If you are using any of these in your solutions, or have prototype objects you alter in runtime you will receive an error similar to:

Error code: x85800007, GatewayScript processing Error 'TypeError: Cannot assign to read only property 'constructor' of #<Object> In file 'local:///xpath.js' line:107, stack:TypeError: Cannot assign to read only property 'constructor' of #<Object> at Object.

The important part to note is “Cannot assign to read only property” which means you most likely have run into the changed behavior for prototypes on FW 7.6.

Luckily there is an easy fix!

There is a new setting for “freezing prototype” which you will find from the default domain under [Objects]->[System Settings]->[GatewayScript Settings]

Set “Freeze prototype” to “off” and then restart/reboot your image/container/appliance. NB! A restart is required for the change to take effect!

DataPower PGP Encryption, Decryption, Signing and Verify

Offline 1 Comentário 2.409 Visualizações

Author: Anders Wasén, Enfo Sweden, anders.wasen@enfo.se

If you need PGP support in DataPower it can be accomplished with a little Open-Source and patience... I have already put in the patience in it so if would be a smoother ride for you...

Setup:

1) Import the ZIP archive into your domain. It will import to directories into the local:/// file system.

GWS will contain a file named pgp_encryption.js which is the main file for the GatewayScript (GWS) Action for your Processing Policy
openpgpjs directory contains the openPGPjs modules required (see Dependencies)

2) Upload the PGP Private Key (for decryption) along with the Public key and any other Public keys that are going to be used for encrypting messages. Default location is local:///pgpkeys/

Private key must be named with .key, e.g. myPGPkey.key
Public key must be named with .pub, e.g. myPGPkey.pub
Both keys MUST share the same name!

3) You need to add the Passphrase for the private key as a GWS Action parameter named pgp_passphrase.

4) [Optional] Change the key store location by modifying the keyStoreDirectory constant in the GWS script (line 38 of pgp_encryption.js)

Usage:

HTTP Header x-pgpkeyfilename must contain the file name of the key located in the given (or default) key directory. File name of the key must be given without file extension (no .key or .pub)!

Dependencies:

Customized openpgpjs (https://openpgpjs.org) is already included

Known limitations:

You can only use this with one Private Key!
- If you have multiple Private Keys for decryption you either need to have multiple Rules with this GWS script or modify it to be able to add multiple Passphrases for different keys.
Passphrases are in plain-text in GWS Action!
- We should adopt Password Maps for GWS.
Some DataPower firmwares (e.g. 7.2.0.x) has a known bug/limitation in loading modules which causes this package to fail!
In DataPower 7.6 (and above I guess) you must allow Prototype alteration!
- From default domain, search "GatewayScript settings" and set "Freeze prototype" to "off":

DataPower implementation:

I suggest to add this into a XML Firewall in Loopback mode.<br/>
You can then use an url_open() from either XSLT or GWS as needed and call the encrypt/decrypt synchronously.

NB! This is provided as an unsupported Open Source solution!

Neither the author nor IBM will provide any support or can be held liable for any errors, damage, or other unexpected events resulting from the use of the code provided here.

Modificado por Offline

IBM DataPower and GatewayScript

Offline 3.668 Visualizações

GatewayScript is a great addition to DataPower’s already extensive tool-box and it gives a wide variety of things we can do!

For anyone not fully familiar with what GatewayScript is it a new scripting language in DataPower based upon Node.js, or rather ECMA Script which is basically a server side implementation of JavaScript.

GatewayScript can be seen as a ”replacement” for XSLT and is used the same in Processing Policy actions. There is a new transform action on the tool bar of a Processing Policy in DataPower:

The GatewayScript Action can be used in the same way as any other Action in a Processing Policy and can be used in any combination with XSLT transform as well.

GatewayScript can also now be used as a B2B pre-processor instead of XSLT which is great as many B2B messages are not XML based.

Writing GWS code is the same as writing Node.js code (more or less) and your first GWS script can be as easy as the following line:

console.log(”Hello GatewayScript”);

If you save that into a file called ”hello.js” and upload into your GWS Action you will end up with a line in the debug log saying ”Hello GatewayScript” obviously.

There are several sample scripts supplied with the newer firmwares in store:///gatewayscirpt/ all named ”example” something, e.g. ”example-fs.js” which will show you have to read and write to/from the file system of DataPower (Yes! That’s right GWS can actually read and write files directly to the internal disk!).

As two samples of what I’ve helped our customers doing using the power of GWS is to build PGP encryption/decryption into DataPower and also create a RosettaNet RNIF gateway implementation enveloping and de-enveloping the rather complex RosettaNet messages.

Looking at what IBM set out to achieve with GWS they mention the goals as:

A superior development experience – servicing, debugging, monitoring mission critical apps with flexible error handling and logging
Familiar and friendly programming language – leverage common programming skills
Highly secure environment – transaction isolation, prevention of dynamic code execution
Ability to consume, produce, and transform JSON and binary data using transport agnostic API
Efficient processing and propagation of information between existing Policy Actions
Wire-speed processing of scripts – leverage DataPower's techniques and technologies

Especially the point of the “ability to consume, produce, and transform JSON and binary data” is what have been lacking in DataPower previously (or it has been an arduous task to get it done).

The Do’s and Don’t’s of GWS is debated somewhat but the general principle is this:

Do:

Use GatewayScript for JSON Processing.
Use GatewayScript for Mobile and RESTful applications.
Use GatewayScript on differing content-types in the same service (XML, JSON, Binary, Text).
Consider using GatewayScript for Binary transformations.
Consider using GatewayScript to implement business logic.

Don't:

Rewrite all your stylesheets. Instead, bring in GatewayScript where appropriate using the dp:gatewayscript() extension function/element or adding a GatewayScript action to process and output contexts.

I have encountered a few customers who actually want to do the “don’t” and transform all of their XSLT’s into GWS. The reason in their case is that they have Node.js developers in-house but no resources for XSLT and they have a very few services using XML processing. SOAP, sure, but not really any Processing Policies handling XML, just standard WebService Proxy functions.

For them it kind of makes sense to jump the gun and make all GWS but for must simply live with the fact that you can (and should!) mix and match between GWS and XSLT!

With the option to run DataPower as a developer locally (on your own laptop/computer) the Debugger for GWS is also available. You can debug your JavaScript just as in a “normal” programming environment!

This works on all form factors of DataPower so if you sit on a VMWare image or a Docker container you are ready to go!

If you like, leave a comment to this post and I can bring up debugging in a new post maybe…

So, if you haven’t already, take a close look at GWS and see what it can do for you!

Take care!

Written by Anders Wasén, Enfo Zystems

DataPower on Docker Toolbox

Offline 1 Comentário 6.075 Visualizações

IBM is working hard to make some of its products available to the public as “non-production” releases, or as Datapower is referred to “DataPower for Developers”.

“Non-production” would mean that you can use it for development, test, demo, or whatever as long as you don’t use it in a “production” environment. Please make sure to read through the license agreement and follow it as applied for your use-case/company.

You can freely download and play around with the Docker version of DataPower.

DataPower looks and works exactly the same regardless if it is run on Docker, VMware or as a hardware Appliance. You can even build your stuff on Docker and export/import to/from any other form-factor.

API Connect (f. API Management) has been released as “public” for some time already (https://developer.ibm.com/apiconnect/getting-started/).

To get your copy of DataPower to play around with look no further than below:

The DataPower developer center is a collection of DataPower related things, https://developer.ibm.com/datapower/

You’ll find a lot of information in regards to DataPower and also a Forum (dwAnswers) where you can ask questions. Don’t forget the original DataPower Forum in DeveloperWorks at: https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000001198&ps=25

In my opinion that is more “active” and I think you’ll have a greater chance of getting answers there. I hope that IBM will merge these two in the future…

There is also a link to DataPower Playground: https://developer.ibm.com/datapower/datapower-playground/

In there you can test and run GatewayScript (~Node.js JavaScript) to see how it works. Unfortunately XSLT is not (yet) supported and you can’t load any Modules.

DataPower for Developers edition is available for download on DockerHub!

https://hub.docker.com/r/ibmcom/datapower/

You will also get your hands on the latest DataPower V7.5.2 Beta and I really hope they will continue to release newer version!

Although this steals some thunder for us in the Early Adopters Program when we can’t play cool and tell others “we know something you don’t” anymore as everybody now has access to the latest Beta builds…

There’s more information on what’s new in the Beta here: https://developer.ibm.com/datapower/2016/08/19/7-5-2-beta/

To get started you obviously first need to install Docker. If you are on Linux or MAC you can run Docker “native”, meaning you run the Docker containers directly on your host computer.

This is also true if you are lucky enough to have Windows 10 version 10586 or above (a.k.a. “the November release or 1511). To find out, hit [Win]+R and give the command “winver” in the Run… box.

If you, like me, sit on an older install and Windows Update don’t give you the option to upgrade (which it normally doesn’t for corporate Enterprise installs), fear not, you can run Docker Toolbox!

Docker Toolbox is essentially a Docker container that runs in Oracle VM VirtualBox and your DataPower container in turn runs in that. That maybe sounds very complex and complicated but it all installs seamlessly and you don’t have to worry!

Just install the Docker software first and at the end of the installation, regardless of Toolbox or “native”, you’ll see a command window:

This will run some scripts and setup a new local subnet for the Docker network. You’ll be asked several times for permissions to allow operations, just answer Yes to all…

Once completed you’ll see the Docker Whale and take note of the IP address (in my case 192.168.99.100):

Now everything you need is installed! Run the command “docker version” to see that all is OK:

Next just pull the DataPower image from Github by executing “docker pull ibmcom/datapower” (but do NOT start it yet!):

This will give you the latest stable version!

If you instead want the Beta use: docker pull ibmcom/datapower:beta

You can also specify the exact version if you like, see https://hub.docker.com/r/ibmcom/datapower/

If you tried starting it already and got errors about memory and CPU see next page and last page for some help, section ”Some pointers along the way”!

As the DataPower image has some requirements for memory and CPU’s we’ll have to up the defaults in VirtualBox.

Stop the default image with “docker-machine stop”

Then find and launch Oracle VM Virtual box from your Start menu or Desktop.

Make sure the default machine is “Powered off” and the right-click it and chose “Settings” from the menu and go to System:

Up the memory to 4096 MB.

Next chose “Processor” and set it to 2:

If you see an “Invalid settings”:

Click the exclamation point and see what it is. Normally it is the display size or memory so adjust that at the same time, e.g.:

Exit out with OK and go back to the Docker CMD window and start the default machine again:

docker-machine start

If you see a prompt like this:

Just run “docker-machine env”, it will print out the new details for the changed container.

Now you are ready to start your DataPower container:

docker run -it \

-v $PWD/config:/drouter/config \

-v $PWD/local:/drouter/local \

-e DATAPOWER_ACCEPT_LICENSE=true \

-e DATAPOWER_INTERACTIVE=true \

-p 9090:9090 \

-p 9022:22 \

-p 5554:5554 \

-p 8000-8010:8000-8010 \

--name idg \

ibmcom/datapower

Once you have started it you’ll see some blue lines and some garbled text. Once the blue lines has stopped moving, hit the Enter key (at the red line) to bring up the login prompt:

If you don’t hit enter you won’t see the login!

The default login is admin/admin

Now you need to start the Web management interface:

Type “co” and hit Enter to enter configuration mode and then “web-mgmt 0 9090”

Now you need your Docker IP which was visible by the Whale initially. If you have forgotten or didn’t see it, just start another Docker CMD window and hit command “docker-machine ip”:

Now fire up your browser and go to https://[your-docker-machine-IP]:9090/

As always with DataPower Web GUI you’ll have to add the certificate exception in your browser and after that the DataPower login will show. Use admin/admin again to login!

Some pointers along the way…

Did you run into problems?

Just start over by removing the container and try again!

Use “docker ps -a” to list all existing containers.

Take note of the identifier, e.g. “6e62e2f3c1be” and the remove the container by “docker rm 6e62e2f3c1be”

How to stop IDG:

First head in to the Docker CMD windows and save your config (or use “Save configuration” in the Web GUI). Make sure you are in (Config) mode and give the command “write mem”:

Next hit Enter to get the prompt back and then type “exit” to leave (Config) and give “shutdown halt”:

This will give you back the Docker Prompt.

To start it again just give “docker start idg”. You’ll now have to use a SSH terminal to access CLI though:

Good Luck!

Written by:

Anders Wasén, Enfo Zystems, anders.wasen@enfo.se

IBM InterConnect 2016 coming up...

Offline 3.493 Visualizações

Soon time to go the IBM InterConnect 2016 in Las Vegas!

I've been attending IBM IMPACT from 2011 up until 2014 and then InterConnect 2015 (as IMPACT was merged into InterConnect last year) and I have been a Speaker every year!

My session this year (HAM-1529) will be more technical than before but I hope I can provide good feedback and input to anyone who tries to extend the boundaries of DataPower and especially for GatewayScript.

I hope to get a good discussion at the end of the presentation and help raise the "buzz" about GatewayScript (~Node.js) in DataPower so more developers can see how incredibly useful and powerful it is!

If you want to check it out, here's the details:

HAM-1529 : IBM DataPower Gateway 7.2: The Completed Picture!

Session Type : Breakout Session
Date/Time : Tue, 23-Feb, 08:30 AM-09:30 AM
Venue : Mandalay Bay NORTH
Room : South Pacific Ballroom G

You're most Welcome! :)

DataPower and network/NIC setup

Offline 1 Comentário 6.262 Visualizações

Ok, whether or not you have run into problems or are simply planning your DataPower network setup you should take two steps back and review your options and needs!

This post is for anyone who intends to use more than one IP address on their DataPower box!

DataPower works in mysterious ways when it comes to handling the Network Interface Cards (NIC) and network routing. Most often this is to an advantage but it can sometimes put you in a rough spot and this blog article is intended to clear out a few of the questions you might have…

The first thing to be aware of is that DataPower has a ”random” behavior when it comes to sending network traffic outbound if it can’t determine a specific route. What this means in the real world is that DataPower will send your traffic to any of the available NIC’s randomly and this can lead to much confusion and anger. This is also true for a response to a inbound (ingress) synchronous request to DataPower. There is no guarantee that DataPower will send the outbound (egress) response back out on the same NIC. This is a behavior that most firewalls that happen to sit between your client and DataPower does not like at all and therefore the response (which the firewall sees as an uninitiated request) is blocked. Furthermore if the egress NIC happens to be on a different subnet with no route back to your subnet the response will be lost and you’ll get that dreaded network time-out error.

Any request originating from the DataPower box itself behaves in the expected manner though and pulls the returning response back on the same NIC as the request exited.

Sometimes you might run into intermittent problems where it fails a few times but then work fine. This is because DataPower caches the “best known route” so if it found its way through once it will keep using that NIC for any following requests. That is, until you restart the box or make any changes to the network setup, then it might start failing again. In these circumstances it is easy to blame the network or the receiving servers to be unstable, even though it is DataPower routing your traffic out on the wrong NIC. This means that even if everything seems to be working fine, you might benefit from taking a look and make sure you at least follow the below stated rules…

I will not go through all various versions of routing here but hopefully enough to get you started and avoid the most common pitfalls…

There are a few ”rules” you should always follow:

There should be a Default Gateway (“default route”) on ONLY one NIC!
You should have a distinct subnets for each NIC!
You must carefully consider each route for each NIC!

Following point number one above is quite easy but it is important to distinguish between a default route and a static route.

The default route and static routes on the DataPower appliance have different functionality and behavior. A static route forces the DataPower box to use a specific interface and a specific set of network hops to access a given destination. The "default route" is created by setting the Default Gateway of a NIC in the DataPower box.

A default route will be used if a known route doesn’t exist for the destination address. If multiple default routes are configured, the appliance will randomly pick which interface to use (but there might be a cached “best known route”).

So, only for one NIC, and one NIC only, you should set a Default Gateway. This would normally be the NIC facing the Internet in a DMZ deployment or the Intranet for an internal network deployment.

The rest of the NIC’s should rely on static routes!

The most common scenario would be that you (think you) want your management network and “traffic” network separated where you’d place management on MGT10 and traffic on ETH10 (where 10 really means zero, i.e. MGT0 and ETH0).

In this case the first question to ask is if you really need/want a separate management interface?

There is something of a misconception that you should always run a separate management NIC, why else is there a MGT0 and MGT1 marking on the box?

It is important to firstly understand that MGT0 and MGT1 is exactly the same as ETH10 or ETH11 apart from them being separate hardware cards. DataPower does not separate MGT0 traffic from ETH10 traffic, that is up to you to do!

The only real reason to run a separate management NIC is if you in fact have a real management network. In some cases you might have a management network for monitoring appliances and then that network is normally only accessible for the network team. They might require SSH access to the box and for that you SHOULD run a management NIC!

For the Web GUI you should only run a management NIC if you have a separate subnet for “management” but in this case it would really mean “Development” and “Monitoring”.

How to you know if you have a separate subnet, well, that’s up to the IP mask or range.

I’ll put aside network masks and CIDR rules here and only discuss IP ranges in numbers for clarity. When you do the actual setup in DataPower you’ll need to use CIDR notification and understand subnet masks to get all the rules in!

So, say for example that you are on the 10.0.0.0 network, meaning your computer (or laptop) have an IP address that would be 10.0.0.125 for example.

Further your DataPower box is in the DMZ and have a “front facing” (=Internet) address in the 172.0.0.0 range. This would now include two separate subnets so if we add a third for management on 192.168.0.0 we have three networks to deal with.

In this example we would have two NIC’s configured in DataPower, one for MGT0 (management) on 192.168.0.0 and another on ETH0 (“traffic”) for 172.0.0.0. The ETH0-interface (172) would have a default gateway set while the MGT0 (192) would have a static route set to the 10.0.0.0 network (=your computers subnet).

This way any traffic going back to the 10.0.0.0 network would go out on the MGT0 NIC and all other (unknown) traffic will go out on the ETH0 NIC (towards 1720.0.0).

After the data has left DataPower it is up to the network (next hop) to decide where the traffic is going to end up.

Now you might be thinking, but wait a minute, my infrastructure and other backend/internal servers are also on the 10.0.0.0 network but they can’t run their traffic over the MGT0 NIC!

Yes, that is absolutely true and they should absolutely NOT do that and your network team will most likely be very upset to see you running all sorts of data on the management network.

This leads us back to the original question, do you really need/want a separate management interface?

In the above setup the answer is probably no, you shouldn’t run a separate MGT0 NIC. You only need that if you have a separate subnet to which your computer belongs and you want/need to route traffic out to that network only for management. There are normally two scenarios where that is true, either the network team has their own management network wired in the data-center or you have a separate VPN connection for the management network. In those cases a separate management network is valid, but then only if the computer connecting is on that separate network!

So, in my opinion most companies don’t need (or should have) a MGT0 setup!

With that out of the way you might want to consider having a ”front” and a ”back” to your DMZ; let’s assume that we skip the management idea and instead put 10.0.0.0 as the backside network on ETH1 (=ETH11) and 172.0.0.0 as the front (towards Internet) on ETH0.

Now the previous setup we had discussed will work just fine, a default route (Default Gateway) on the 172-network and a static route for 10.0.0.0 to the 10-network will accomplish what we want.

Any “unknown” traffic will be routed to the front-side (=Internet) while any 10.0.0.0 traffic will go out on the 10-network to your back-end servers and your laptop.

Another very common scenario is that you run Development, Test and QA/Staging environments on the same box (in different domains) and you need separate IP addresses for these or you have different traffic types, e.g. “secure” and “normal” that requires separate NIC’s.

Same thing applies here, first question, are the different environments/types in separate subnets?

In most cases the answer would be “No”, they are not and thus we should route the traffic to the different environments out on the same NIC using a static route. If the answer is “No” you might also consider using secondary IP’s instead of separate NIC’s since the routing will be the same for all three IP addresses. Another option is of course VLAN interfaces but that would all be up to your network team if they want one cable per IP or allow for Secondary or VLAN interfaces instead.

For a multi-environment box I would always recommend NIC’s or VLAN’s though so you can set Alias on the IP addresses and use them in the Front-side-handlers in the various domains more easily.

If however your answer is “Yes”, then you’d need to setup static routes to the various subnets for each NIC/VLAN and you need to setup any firewalls for the appropriate source/target IP.

In regards to this, I also often get the question about a “multi-homed” box, meaning a DataPower box that simultaneously exists in different network zones. This would normally be the DMZ and the Intranet. If you are using a virtual DataPower instance you shouldn’t even consider it!

If you however own a hardware appliance you could consider it, I won’t recommend it and you need to be very, very careful with your routing setup!

You should in that case also make sure that you have a firewall for the DMZ in front of the DataPower box. DataPower is a “hardened” hardware appliance and thus it is very capable of handling network traffic, if you know what you are doing!

Why you would do this is of course to save money, especially if you run API Management and want/need your API’s accessible both to external customers and internal systems. You should be very strict in the setup of domains and under no circumstances route traffic directly from “internal” domain to the “external” domain without passing the firewall!

And at all times, remember I did not recommend to do this, I only told you it is possible!

Best of luck and remember, when things look bleak, there’s always WireShark! :)

Modificado por Offline

Fault finding for WTX errors on DataPower…

Offline 4.130 Visualizações

This post will assume you have sufficient skills in both IBM DataPower Gateways (DataPower) and IBM WebSphere Transformation Extender (WTX) to preform advanced tasks…

Getting that “Input valid but unknown data found” or a “One or more inputs was invalid” from a WTX map in DataPower can be oh-so frustrating as the WTX trace file can’t be used.

Quite often when this happens you will find that your map runs just fine in your local Design Studio but fails on DataPower with one of the above dreaded faults.

The first thing to do is of course to double-, and triple-check that you are in fact using the SAME data when testing on DataPower as you have loaded in Design Studio!

Remember to include ALL input cards and use the same data for all. After you have triple-checked this run the map again in Design Studio to make sure it runs through there with a “Map completed successfully”.

One common mistake is also that you in fact get a “One or more outputs was invalid” and in that case your map settings are messed up so go and check your output card.

To get the data that is actually received by the map in DataPower you can create a “base64 output”.

Just build a really simple “just-text” map with a Type Tree that has a Text item and add that as both input and output to the map. Then add the rule as:

=TEXTTOBASE64(TextBlob_In)

This will get the whole input and base64 encode it for you as the output.

Build the map for DataPower (.dpa), upload it to the DataPower instance and just replace the map reference in your processing policy (or routing file) with the base64 map instead of the non-working one. Then run the message flow again through DataPower…

Grab the output from wherever you get it, MQ queue, HTTP Response, sFTP or wherever…

Your output will look like garbage but just bear with me…

Base64 output can look something like this:

SGVsbG8gV29ybGQhDQoNCldlIGFyZSB0ZXN0aW5nIGJhc2U2NCBlbmNvZGVkIGRhdGENCmFuZCBuZWVkIHRvIHVuZGVyc3RhbmQgaG93IGl0IGxvb2tzIQ0KDQpTcGVjIWFsIGNowqRyYWN0ZXJzIHdvcmsgdG9vJQ0KQW5kIG5vbi1VUyBsaWtlIMOFLCDDhCBvciDDliENCg==

Now fire up an advanced text editor like the awesome Notepad++ and paste your data into a new document.

After you have pasted the data in there, highlight the whole text ([Ctrl] + A) and chose the menu, [Plugins]->[MIME tools]->[Base64 Decode]:

The text sample on the previous page will give you:

Now make sure you save the data in the appropriate encoding and for DataPower this would normally be “UTF-8 without BOM”:

If the blue dot indicates something other than “Encode in UTF-8 without BOM” make sure you select “Convert to UTF-8 without BOM” before you are saving the document!

With this newly saved file, run the original map in Design Studio as you now have the exact data fed through the failing map in DataPower.

In normal circumstances the map should now also fail locally and you can turn on Map Trace to locate the error, fix it and build a new DPA and deploy to DataPower which should then run fine.

If the map still runs fine locally with the base64 grabbed data then it is most likely some encoding problem in the DataPower flow or the DPA on DataPower does not match the map in your Design Studio.

Make sure to rebuild the DPA and upload it to the DataPower instance again. If you are running a cluster of DataPower instances, make sure the same DPA exists on all instances!

If it is still not working after that it might be some Design Studio flaw. If possible try and re-build the DPA in another Design Studio instance.

You can also try and clean the WTX project in Design Studio (from the Project menu) and rebuild the map.

In worst case, create a whole new Workspace for WTX, copy over the Type Trees (but not the MMS file) and then go and Export the MMS from your original Workspace by right-clicking the MMS and chose [Export]->[Map]. That will give you a XML file on your disk. Now go into your new Workspace again and right-click in “Map Files” chose to [Import]->[Map from XML].

Once you have the map, build it for DataPower again and upload the DPA and try it out.

If it is still not working then, open a PMR with IBM…

Written by Anders Wasén

Enfo Zystems, September 2015

Modificado por Offline

IBM MQ Appliance

Offline 4.304 Visualizações

IBM MQ Appliance

The scalability and security of IBM MQ V8
- Integrates seamlessly into MQ networks and clusters
- Familiar administration model for administrators with MQ skills
The convenience, fast time-to-value and low total cost of ownership of an appliance
Ideal for use as a messaging hub running queue managers accessed by clients, or to extend MQ connectivity to a remote location
Fixed hardware specification allows IBM to simplify and tune the firmware
Simplified ownership
- Self-contained: avoids dependencies on other resources/teams
- Licensing: Simpler than calculating licensing costs (e.g. by PVU)
- Security: Easier to assess for security compliance audit
Built using the latest DataPower appliance hardware and OS
Firmware includes the MQ V8 product and capabilities
- Participates in MQ networks or clusters
- Existing MQ applications connect as clients, with no code changes
Built-in High Availability
- Per queue manager monitoring and automatic restart/failover
- Without external dependencies (shared file systems or shared disks)

http://www-03.ibm.com/software/products/en/mq-appliance-m2000

IBM DataPower Gateways and B2B…

Offline 3.446 Visualizações

IBM DataPower Gateways and B2B…

Business-to-business concepts

With more and more companies expanding their business and dividing enterprises into different domains and locations, along with a growing need for up-to-date processes and information flows, the complexity of exchanging business-to-business (B2B) information is increasing.

In the pre-internet and early internet era B2B often consisted of exchanging EDI messages with very few business partners. Looking at today’s business needs, regardless of the label, small-, midsize- or large-company, it often includes a variety of external partners, communication types and messages. Many companies do not realize the width of their traffic that would classify as B2B from a “modern” standpoint.

With many established partners, subsidiaries or offices in other geographical regions B2B is often viewed as something like an internal process with an added protocol to be able to exchange the messages between different networks.

The above sentence summarizes the most commonly known definition for a B2B scenario; the exchange of data between isolated networks by two identifiable parties!

Not said that the “parties” must be different companies, it might be different departments, separate geographical areas, etc. “Identifiable” is another rather wide term as the identification of a party could be either a standardized addressing like, EDI identifier, DUNS or similar or a more technical term such as IP address or a dedicated directory in a FTP exchange scenario.

Regardless of which identifier is used (most commonly a combination of many) a B2B gateway must be able to identify the sending and receiving party.

Another key concept of a B2B gateway is to offer a routing capability for back-end systems like an ESB, ERP, or any other receiving system. The routing capability normally takes the information about the sender and receiver along with information about the message and/or protocol used to make the routing decision.

More external end-points to come – API

Looking at the expanding need for externalizing data today companies must also consider how to be able to meet these demands.

With mobile devices and “bring-your-own-device” policies a whole new era of communications are evolving, the API-era…

Mobile API’s are but one of three common types, Web-API’s and Business-API’s are the two other types. Web-API’s typically serves various web-portals or application servers while Business API’s is about publishing “business information”, e.g. master data.

A sample of the three working together might be if there is a customer repository in the internal systems and we want to serve our business with one common set of master-data. We would then build a business-API that would publish the customer address for example, then we would build a Mobil-API that the customers Mobile App can utilize and another Web-API so the customer also can see the address if logging in through a web browser.

The benefit of using API Management to handle this is that we only need to handle one set of data but then we can publish that same data in three separate ways, without having to write different code for them. We will also be able to handle security and user management in API Management as well as look at statistics and utilization of the API’s.

In this white paper we will not focus on API’s but an important note is that DataPower is capable of handling API’s as well and there is an available add-on called API Management for DataPower that will handle of your API requirements.

DataPower

To be a bit crude, one could say that DataPower is “B2B in a box”…

DataPower with the B2B module is more than that though; it is a complete solution that will cover most of the B2B needs even for the most demanding of companies.

The DataPower simplifies, helps secure and accelerates your B2B trading partner connectivity.

As DataPower is based upon the IBM’s Gateways series hardware it is delivered as a “box”, or to use IBM’s terminology an “appliance”. DataPower can also be purchased as a “virtual appliance”, it will provide the exact same functions and even looks identical from a user perspective but then runs in a hypervisor environment, e.g. VMware ESX.

The base model for DataPower is called “IBM DataPower Gateways” which adds security and gateway capabilities to your network. Adding the module “Integration” it will add integration and an ESB capabilities. The B2B module in turn is based on the “Integration module” which means that all the functionality included in “Integration” is also found in the “B2B” version.

With the B2B module added you will get trading partner profile management, B2B transaction viewing capabilities and industry standards-based B2B messaging protocols to the already robust integration capabilities of the core appliance. These three added key capabilities are at the heart of the B2B module.

The only connections needed for any DataPower appliance is power (through a regular power cord) and a network cable. The initial setup for the network interface is done through a local USB connection and after that all configuration is normally done through the web interface. There is a Command Line Interface (CLI) and also scripting capabilities if needed.

To learn more of the basics on DataPower, please view the Red Book “DataPower Architectural Design Patterns” (http://www.redbooks.ibm.com/redbooks/pdfs/sg247620.pdf).

In depth…

IBM DataPower Gateways with the B2B module is a purpose-built hardware B2B-enabled ESB.

It is designed for simplified deployment and hardened security with the ability to quickly transform data between a wide variety of formats, including XML, industry standards and custom formats. DataPower offers a built-in IBM WebSphere Transformation Extender (WTX) runtime as well as XSLT for flexible and high-performing transformations.

The device provides core B2B functions, including AS2 and AS3 messaging, partner profile administration, routing of electronic data interchange (EDI), XML and binary payloads, auto archiving and purging of B2B transactions and B2B transaction viewing capabilities.

A few core features for the B2B functionality is:

Easily manage and connect to trading partners using industry standards
Extend integration beyond the enterprise with a securely deployed B2B Gateway in the demilitarized zone (DMZ)
Improve the performance and scalability of B2B interfaces
Govern B2B integration points through consolidated trading partner management

The ESB functions include routing, bridging, transformation and event handling. It provides a reliable, performance-oriented solution to many integration challenges. Because it is not limited to handling just XML the DataPower fits perfectly with IT organizations that need to benefit from the connectivity of SOA deployments but must also deal with managing a combination of multiple proprietary, industry, company-specific and existing data formats.

The device is a true drop-in B2B integration point for such environments, reducing the time and cost of integrations and speeding the time to market for services.

For accelerated, security-rich integration capabilities, DataPower provides transport mediation, routing and transformations among binary, text and XML message formats.

Visual tools can be used to describe data formats, create mappings between different formats and define message flows. With native connectivity to IBM DB2 and IBM System z technology, the device offers a solution for a secure XML enablement of existing systems and mainframe connectivity.

The WebSphere DataPower SOA appliance portfolio has a long-standing history of support for key and advanced standards, including WS-Security, WS-Policy, WS-Reliable Messaging, SOAP, Web Services Distributed Management (WSDM), WS-I Profiles, WS-Addressing, eXtensible Access Control Markup Language (XACML), Security Assertion Markup Language (SAML), Secure Socket Layer (SSL) and proprietary Single Sign-on (SSO) tokens.

DataPower integrates with a variety of registry and repository, security, identity and service management software. Coupled with access-control software, such as IBM Tivoli Access Manager, the device enforces fine-grained access controls.

Security

In many cases, when security is first discussed with the customer, they think of securing their data and possibly their connection. When it comes to deploying a B2B solution, we also need to take into consideration how to deploy the software in a manner that does not violate any existing network security policies that the customer has in place.

The four areas of security and their definitions that apply to B2B are:

Deployment Security means the placement of hardware within an existing network with access to the Internet. This type includes database servers, file shares, message queue servers and integration servers.
Connection Security means establishing a secure connection between trading participants over a Secure Socket Layer (SSL/TLS) connection (NB! Only TLS is enabled by default in DataPower but legacy SSL support exists).
Document Security encompasses signing and encrypting the message prior to sending it to the trading partner.
Access Control means providing access to data and configuration information inside the B2B application.

To protect B2B applications from unauthorized access, networking and firewall protection must be established. Firewalls work in conjunction with proxy servers, providing the ability to filter protocols, addresses, communication ports and IP packets. The security model that can be used is the establishment of a demilitarized zone (DMZ). The DMZ must be configured to restrict only a minimum set of communication ports for it to process requests.

DataPower is a DMZ-deployable appliance and requires a minimum amount of access through the inner firewall. Any sensitive payload data persisted to the Appliance is not accessible by partners and is encrypted on the hard drive.

Document security is normally accomplished through digital certificates, which provide an online identification credential for specific document exchanges, for example, AS1, AS2, AS3 or custom document-level encryption requirements. As part of document exchange, digital signatures can be calculated on the electronic document using public key cryptography. Through this process the digital signature is tied to the document being signed, as well as to the signer, and cannot be reproduced.

DataPower uses a role-based approach for access control. Users log in by providing their partner name, user id and password. The login determines individual access privileges. DataPower browser interface, which is used for administering functions, operates over a TLS connection (https).

To learn more and to see what DataPower can do for you and your company contact Enfo Zystems today!

Enfo Zystems

http://www.enfo.se/

Phone: +46 77 440 44 00

IBM DataPower Gateways and B2B…

Offline 7.339 Visualizações

IBM DataPower Gateways and B2B…

Business-to-business concepts

The above sentence summarizes the most commonly known definition for a B2B scenario; the exchange of data between isolated networks by two identifiable parties!

Regardless of which identifier is used (most commonly a combination of many) a B2B gateway must be able to identify the sending and receiving party.

More external end-points to come – API

Looking at the expanding need for externalizing data today companies must also consider how to be able to meet these demands.

With mobile devices and “bring-your-own-device” policies a whole new era of communications are evolving, the API-era…

DataPower

To be a bit crude, one could say that DataPower is “B2B in a box”…

DataPower with the B2B module is more than that though; it is a complete solution that will cover most of the B2B needs even for the most demanding of companies.

The DataPower simplifies, helps secure and accelerates your B2B trading partner connectivity.

To learn more of the basics on DataPower, please view the Red Book “DataPower Architectural Design Patterns” (http://www.redbooks.ibm.com/redbooks/pdfs/sg247620.pdf).

In depth…

IBM DataPower Gateways with the B2B module is a purpose-built hardware B2B-enabled ESB.

A few core features for the B2B functionality is:

Easily manage and connect to trading partners using industry standards
Extend integration beyond the enterprise with a securely deployed B2B Gateway in the demilitarized zone (DMZ)
Improve the performance and scalability of B2B interfaces
Govern B2B integration points through consolidated trading partner management

The device is a true drop-in B2B integration point for such environments, reducing the time and cost of integrations and speeding the time to market for services.

For accelerated, security-rich integration capabilities, DataPower provides transport mediation, routing and transformations among binary, text and XML message formats.

Security

The four areas of security and their definitions that apply to B2B are:

Deployment Security means the placement of hardware within an existing network with access to the Internet. This type includes database servers, file shares, message queue servers and integration servers.
Connection Security means establishing a secure connection between trading participants over a Secure Socket Layer (SSL/TLS) connection (NB! Only TLS is enabled by default in DataPower but legacy SSL support exists).
Document Security encompasses signing and encrypting the message prior to sending it to the trading partner.
Access Control means providing access to data and configuration information inside the B2B application.

To learn more and to see what DataPower can do for you and your company contact Enfo Zystems today!

Enfo Zystems

http://www.enfo.se/

Phone: +46 77 440 44 00

Pure, I'd guess so...

Offline Marcações: systems pure 4.970 Visualizações

Ok, so I should probably say something about the Pure System as well... During the Opening session at IMPACT they rolled this cabinet onto the stage in a puff of smoke and techno music booming... Well, kind of corny I felt and not knowing much about the Pure Systems prior to seeing it up on stage I got a flash-back to some 80's movie or something...

It would have been way cooler if they'd had implemented a HAL-9000 eye on the box!

While listening on the presentation though it got me wondering if they shouldn't have gone even further with the smoke and flashing lights... The box is way cool!

Imagine scaling down that arduous implementation project whit not half, not 60, nor 70%, but I'd say up to 95% of the time it would take you to install and set it up in a normal "server" environment, such as blade servers and regular network equipment.

First of all you'll get pre-packaged deal to bring home, e.g. DB2+WAS, etc. I guess they stole that idea from Cast-Iron... ;)

Honestly I am not that impressed by the whole "packaging" deal, that is something that should have happened years ago and for me personally being spoiled with DataPower and firmware based appliances it's "every day business". I do understand the benefits though as I spent a 2 month (!) project installing WebSphere Partner Gateway with SAN file-share running on DB2 and WAS messing around with load-balancing, fail-over scripts and IP addresses flying here and there... but now I am getting ahead of my self here because the PureSystems will do all that for you!

Yes, that is load-balancing, fail-over, disk arrays, and all those flying IP addresses while you sit back relax and just monitor the whole shaboom in a cozy Web GUI. Now that is the deal-breaker there!

Then looking at the sad part, who would buy it... Well, without a doubt there are many, many companies that would benefit greatly from having it but that would mean tossing out a lot of already installed and running software... I think that will be the main problem pushing these beasts onto the market, unfortunately as I think ROI would be quite good, even though it would mean you have to toss a few pieces out. You would also get a much lesser foot-print on the network equipment and much shorter time-to-market on pretty much anything you put on the box.

If IBM can show these numbers and the benefits of using the PureSystems in one "package" I think they will have a much easier task of getting these boxes out. The tricky part will be to actually get these numbers as they vary greatly between different companies and depending on if you have your network stuff outsource or not.

If you are lucky enough to find a company that needs a new set of hardware and new installs, well, these boxes are for them!

They couldn't do any better!

But then again, how many of those are you going to find...?

Take care!

Regards,

Anders

@IBM IMPACT 2012, WTX, DataPower and bagels...

Offline Marcações: las impact vegas wtx datapower 5.772 Visualizações

Ok, back in Las Vegas for another week of IBM technology... IMPACT is really great but this year it is rather hot outside so it is a good thing IBM keeps me busy inside...

It is three days into the the conference and I have now had my own speaker session about the implementation of DataPower XB60 and WTX for ESAB (http://www.esab.com/) and also finalized my IBM Champion interview so now I can relax and really enjoy the rest of the week without freaking out about my public appearances... ;)

What's new and exciting then?

Well, for starters those breakfast egg-cheddar cheese-bagels are quite alright... ;)

But there are a lot more goodies coming our way. Unfortunately IBM has forced me to sign a few NDA's (that's None Disclosure Agreement) so I can not share those releases with you only the public ones (for now at least...).

The most exciting for me (and my clients) would be the release of WebSphere Appliance Management Center (WAMC) as part of the support-pack for DataPower rather than a licensed (read: costly) product. The new version 5 of WAMC also have a lot of improvements and a much smaller foot-print on the running server. If you are running a multi-box environment you should really look into WAMC 5; the "multi" part don't have to be "multi" in the sense of production-production to gain benefits from WAMC but can also be a production-test setup. WAMC 5 will be GA (Generally Available) by the end of June...

Further good news is the announcement of the WTX EDI-pack support on DataPower firmware 5 (coming end June as well along with WTX 8.4.0.2 where this is included). This means that we can finally use the EDI type-trees and the compliance maps on DataPower. This comes from IBM allowing us to use the RUN() function.

For all you old Mercator people (like me) and Launcher users this means that we can start using those router-maps again. This also shows that if you nag the right people long enough things will change for the better... ;)

With this release we will also see the need for the WTX test domain go away and instead be supported out-of-the-box in DataPower, so you only need to open a port, give the IP address in Design Studio and start test running maps on the DataPower box directly. I assume this will also be the case for deploying (=uploading) the compiled maps from Design Studio, even though that was not mentioned during the session...

There has also been some talk during open sessions about new ideas when it comes to the appliance form-factor. My belief is that we will probably see much smarter solutions for connectivity for cloud and/or gateway services coming along in the form of a "connectivity" DataPower. This would be awesome for any gateway solution where you would run the server side in the trusted (intranet) zone while having a "receiver" as proxy in the DMZ, e.g. Sterling Integrator for B2B traffic. This would also mean that we would have a secure and flexible route to our trusted domain from any Cloud solution out there.

This can of course be done today using a regular DataPower, e.g. XG45, but I see that the "connectivity" model would be more limited and therefore (hopefully) less expensive.

Talking about the XG45; that's a new improved XS40 still in a 1U shape but with added protocol handling and now being able to run WTX maps as well. This clearly indicates the focus IBM has on DataPower and the willingness to listen to the demands from the market. Previously the XS40 was quite limited and you had to go that extra mile (read: show the money) to get the protocol support needed for every day use in the XI50.

Now with the new supported protocols and functions in the XG45 while considering the added hardware in XI52 you get a distinct separation in use cases even though many of the XI50 functions have been ported to XG45. The choice for a smaller customer with need only for a secure (and smart) gateway for the DMZ the XG45 is now the clear choice!

Continuing with more of the cool stuff is the IBM Workload Deployer, the snippet below explains it in more detail (stolen from IBM.com):

"IBM Workload Deployer is a hardware appliance that provides access to IBM middleware virtual images and patterns to easily, quickly and repeatedly create application environments that can be securely deployed and managed in a private cloud."

This is essentially the only thing needed for your perfect "transformation-as-a-service" solution as you can throw WTX Launcher on there and have it scale up and down dependent on your needs. I would really like to get my hands on one of these...

For anyone wondering about the DataPower GUI I can only tell you things are lightening up for us... more than that I can not reveal, sorry... (remember those NDA's?)

Take care!

Regards,

Anders

SOA, what?

Offline Marcações: overview executive soa 4.931 Visualizações

Ok, so the follow-up question to my post "Why SOA?" seems to be "SOA, an Executive Overview?"...

I really have a hard time explaining SOA and the benefits of it to the executive layer in the company. They don't really grasp the technology, nor do they care about technology, so how do you explain the benefits of SOA so they'd understand it without getting into technology?

Metaphors has done the trick for me, and here let me tell you a story that won't be technical at all, so all tech-nerds can jump off this train right now.

Imagine some time ago, as far back as the beginning of the last century (that is the 1900's if you lost track) where people lived spread out and managed their own farms and villages. There where not much need for integration as most of the work was done on the farm and you only occasionally had to visit the village to pick up some supplies and maybe trade for other goods. (Metaphor: Systems/Application ran isolated and where thinly spread out).

Then people started to gather together in villages which in some occasions became towns... This presented a whole new type of problems, first they realized that we need someone in charge (Metaphor: SOA Governance). Once they had someone that could make decisions (hopefully through a democratic process) for the greater mass they could start putting some structure to things. The "goverment" (read: governance) created rules for how to build your house, where and how roads would connect these houses. The also built centers, like a town-hall, which would be easily accessible to the public and that could spread information to all citizens. (Metaphor: Point-to-point integration and a broadcast model).

This was working out great until the town grew too big and the planning didn't take into account the widespread need for building houses (i.e. adding systems and applications). The planning committee needed to address this and make up for shortcomings such as deliveries not finding the right address and that the fire-wagon (yes, they used wagons in that time) couldn't get through crowded streets or would be turning into a street too narrow to get through. (Metaphor: delivery failures, performance issues and too narrow channels/bandwidth to handle the traffic).

This was maybe not too much of a concern to the "government" and their closest allies (read ERP and/or financial systems) who had a great time in the city center and the fire-wagon parked in a shed close by.

What they came to realize though was that the more houses that burnt to the ground and the more deliveries being lost the less business the town made which of course hit the town economy quite hard after some time. We can only hope that the "government" got wind of this in time before things got really bad...

Anyhow, as soon as they realized that this was not good for the town (or its economy) they started to think of how to overcome these issues. As they had gotten into a mess of roads leading in all different directions and had delivery routes going criss-cross between shops and customers as well as letting foreign customers in from different routes they had a hard time trying to figure out where to start. Someone (who probably had read SOA for dummies) came up with the idea to build a main-street, leading from one end of the town to the other. This of course improved things and even though it lead to tearing down and rebuilding a few house it came out a good investment in the end (Metaphor: Hub-and-spoke integration).

There where, however, still many houses in the outskirts that didn't benefit at all from this new main-street and some started complaining that they where left out while some other of these outskirt houses where very happy because they did not benefit from the main-street and only saw all that buzz and commotion as something negative and stressful.

These happy outskirt houses knew where they had to go for their business and had no intention of letting the "government" know what they where doing. This was especially true for the houses dealing with those foreigners roaming through town as they could conceal their traffic and benefit from not having to follow the rules and build whatever solutions they liked to accommodate the foreigners. The foreigners had no way of letting the "government" know they where unhappy or had to wait outside for several hours to find a vacant room. Eventually some got tired of waiting and gave up while others just threw in their load and carried on their journey without caring if someone ever picked it up. (Metaphor: Indifferent B2B handling and bad monitoring).

It took quite some time for the "government" to realize this "outskirts" business as they only saw what was closest, their brand new and shiny main-street and how happy their closest acquaintances where (remember those ERP and financial systems?). The "outskirt-ers" weren't too happy about being up for a closer inspection and reported back that all is well and good and that business is thriving. This is where the story normally ends (unfortunately) but some business keeps their wits and takes a closer look at their complete business area. If they do this, which is one of my main work assignments; the B2B Workshop by Enfo Zystems, we get into a new set of architecture and design of the town...

So, now they stand in front of a huge undertaking... How are they going to clear this out and manage to get control and a working governance again?

Clearly something has gone wrong since the renegades in the outskirts area has been able to roam free and create a mess. Thinking about it, their initial idea with the main-street was not bad, not bad at all actually, but they would have needed to extend it and made sure that all could have accessed it directly. That's a very clever idea they might think but it's very difficult getting every one on board and having them turn onto the main-street all the time, plus it makes a very long street, right?

Well, if it's long doesn't really matter since we travel as fast as an electron through a copper wire (normally a CAT5 Ethernet cable) so we really don't need to take the length into account, just stretch it and bend it as much as you like (yes, electrons can bend too...).

We know have decided to build a long stretch of road with entrances and exits for each and every house, reminds me a bit of a free-way, doesn't it? ;)

Now imagine this free-way with those entrances and exits extending out into the suburbs and also covering the outskirts. This means that all those foreigners also have to start their trip into town on the free-way. That, in turn, means that we could place a toll-booth over the free-way and monitor all that passes through!

Now let's extend that to toll-booths on all exits and entrances on and off the free-way, now that's a great idea because now we can keep track of who is on the freeway and where they came from.

This, along with some great and up-to-date maps, which are now easy to maintain, gives us a full overview of our town (read: integration platform).

This is really exiting to the "government" as they realized they can also add labels to each vehicle (read: message) traveling on the free-way. They soon also realize that these labels could include the worth of each traveler helping them to know exactly how much of their belongings is going up and down that road. That way they will be able to tell which travelers on the road that is bringing home the money!

Let's also add some emergency-phones if some of those vehicles get lost or breaks down for some reason, that way we know where they are and where they came from and how to help them (Metaphor: help-desk and real-time monitoring).

And just imagine how easy it would be to add a house or remove a house or rebuild a house... Just tell the free-way planning committee about your plans and how they should redirect traffic during that time and handle your ramp when you are back in business.

They still see a few issues though as some of those foreigners don't speak the language... The "government" comes up with the idea that someone who understands both languages can translate so have the foreigner drive off the freeway into a "translation center" (read transformation service) to explain their business to one of the natives and then have that native drive over to the receiver with it instead...

Now, that is a better town layout, isn't it, and doesn't it also remind you a bit about the SOA idea...?

Regards,

Anders

Why SOA?

Offline Marcações: soa service oriented architecture routing esb 6.715 Visualizações

Why SOA you might ask?

Well, it's really to reap the benefits from re-usability. Although I find that it becomes more and more common that the whole SOA "idea" is questioned, especially by "higher-upp'ers" who mostly see the added cost for their particular project.

I have realized that I, instead of explaining the benefits of SOA, more and more often am trying to persuade project managers or executives in the business area to at least talk to their Enterprise Architects on the SOA matter instead of just go with the "easy way out".

Why has it come to this...?

I would think that SOA is nowadays counted as "old-news" or the hype that never happened, and since it was only a hype, why should We spend any more money on it?

I would definitely agree that not all projects, or even companies, do benefit from a full blown SOA implementation but I think most could at least benefit partly. The main issue is really that most companies aren't looking at the big picture because most changes are driven by projects that only affects part of the business and/or integration platform.

If a company has already invested in modern "integration tools" such as WebSphere Message Broker (WMB), WebSphere MQ and MQFTE they are not very willing to continue investing in some "real" ESB tooling. Sure you can use WMB as a very effective ESB but that would mean that you have to build a lot of the technology in-house and what it really becomes is a hub-and-spoke integration platform with great routing logic...

To really benefit from SOA you need to look into the whole "Service" concept, and by that I don't mean Services from a technical point of view but from a conceptual. So, then, what is a conceptual point of view?

The first and most important thing would be to map out your IT environment, and not only the projects but the whole company's environment, and categorize the different areas. Look at what will have to remain as the old "spaghetti" or point-to-point and what can be "moved" into the "Services" view. And before you start complaining; every, yes, every, mid- to large-sized company have their share of "old school" integrations that can't be moved for one or another reason. The important thing here is not to "service:fy" them but to know that they exist and what they do!

Next start putting your integrations into a service pattern, or function reference if you will. You don't need actual "services", such as a WSDL or similar for each function, just to describe them as a service with what they do, where they are, what's the input and what's the output.

You will soon see that many of the "services" that you map are very similar and that you will have an easier task while moving forward. Once all services (on the conceptual level) are documented you can start looking at how they do interact with one another.
Regardless of the technology used to "interact" you should put it down as a "service call" and link consumers and providers of the service along with the point-of-delivery (POD). With this new documentation I can promise you that you will start making smarter choices when it comes to integration and that you can benefit from a lot of your already existing solutions, and by that I don't mean the services themselves, but the technology, code or structure of the existing integrations. Simply put; you will be able to see how you (or that other project) have created things previously and benefit from using that same pattern, and who knows, maybe even share a service! ;)

Now that is real SOA to me...

Take care!

Regards,
Anders

Feed para Entradas de Blog Feed para Comentários de Blog

Blogs