Structural Design Pattern Confusion

0
on

The other day my team was having a discussion about some software we were working on.  During the discussion, several of the structural design patterns were mentioned, sometimes interchangeably. This is a brief overview of  three of them for future reference.

The Facade

The Facade defines a single, simplified interface over one or more subsystems.  Common usage of this is simplifying a remote system’s interface.

The Adapter

The Adapter changes (aka adapts) the interface of a class to match what is expected by a caller.  I have used this in the past to provide a common interface for getting/setting the value of web controls.

The Proxy

The Proxy stands in for another class, intercepting the call and then usually passing the call on to the class the proxy is representing.  Common usage of this is a proxy defined for WCF service or an NHibernate proxy for lazy loading.  The end result is additional behavior, like remoting complexities or lazy tracking, are injected into the the call stack without the user of the proxy having to know about it.

An Integration Story

0
on

My current project has me building a system to allow an external partner to integrate with our order application.  Right now, the end users have to go out to the partner’s site, get a list of new orders and manually enter them into our system.  The entire process is inefficient and distracts people away from their normal duties.  When complete, the integration will allow the partner to send orders directly to our system without human intervention (in most cases).

There are several ways to do integration.  Enterprise Integration Patterns outlines 4 at the start of the book: File Transfer, Shared Database, Remote Procedure Invocation (RPC), and Messaging.  We chose a mix of RPC and messaging.  The RPC via web services was selected as the way we communicate with the partner mainly because the partner already has an infrastructure built around web services.  Internally, we use a mix of web services and pub/sub messaging via MassTransit.

The architecture for the solution has four main parts: an external facing web service that the partner calls, a windows service for workflow (MassTransit saga) and integration business logic, a web service into our primary application, and a web service the external partner hosts for us to send updates to. There are many benefits to this architecture.  The external facing web service can be placed in a DMZ which only allows inbound calls to be routed to MSMQ, the windows service can be taken offline for maintenance without affecting the partner’s ability to send orders, loosely coupled components with clear and distinct responsibilities, and each part can be scaled independent of the other parts.

The order process is kicked off by the partner calling our web service and sending over a message for a new order.  In addition, the partner calls the web service once for each line item on the order.  Our web services takes data from these calls, transforms it into an object model, validates the data, and publishes messages via MassTransit.  The windows service has a saga that consumes the messages from the web service.  When the saga determines all the pars of an order have arrived (the order  and its line items), it calls a web service in our primary application to create the order.  At this point, the users can go in and do what they do with the orders.  As the orders progress thru the order application, messages are published about state changes.  The saga in the windows service consumes these messages and sends updates back to the partner’s web service.

In the end, the integration should add significant business value by increasing the overall efficiency of our employees and reducing errors caused by manual data entry.

Introduction, Say Hello

0
on

So I have decided to get more involved with the community by blogging.  This is my introduction to the world.

My name is James and I am a software developer in central Texas.  My professional interests include enterprise integration, custom application development, agile processes and general best practices.  Personal interests are my family, hiking/camping, fitness and healthy living, and snow boarding.

The majority of my posts will focus on my professional interests, products I use, and the discussions I have about technology.  Through this blog, I hope to spark constructive discussion, help people solve problems, and introduce others to the concepts/topics I consider important to my career.

Thanks for reading and please bare with me as I improve my writing ability.