Friday, August 15, 2008

ProtoSOA

At last, my colleague and I have completed the SOA enablement framework called "ProtoSOA". We successfully warded off all other distractions for the past 2 months while finishing up our last trip to Beijing and finally completing a reference implementation and testing of the product. Success! The reference implementation will help prove out the capabilities of this framework. While other opportunities arise to present new challenges, new features and enhancements to the product are on the horizon also.

Next steps will be to complete a thorough QA process while continuing to design for future capabilities. The next stage will bring some exciting features such as BPEL for workflow management, drag & drop interface, and auto-discovery.

Friday, May 16, 2008

Distractions

Well, at my last update I was anticipating my next trip to China which was to have occurred from May 9 - June 30. As luck would have it, I have been drafted into a project in Milwaukee which requires me to postpone my trip and threatens to temporarily derail my plans to get back to work on ProtoSOA. My friend and colleague, Tom Culpepper, is over there now, working hard to keep above water with one less architect and a smaller than expected development team. Distractions like these are difficult but the customer comes first, and in this case, the current project is providing challenges aplenty.
If anyone would like to offer their advice and expertise on the usage of OpenLDAP to create a somewhat complex Schema architecture, I would appreciate your comments. I am not up to speed yet on this technology but I'm working to overcome my own lack of experience.
In the meantime, I'm hoping to complete this design soon, after which I plan to join up with Tom and continue work on my "child". Next post, hopefully, I'll get back to the topic of this blog and perhaps think of some words of wisdom.

Wednesday, March 26, 2008

ProtoSOA Update

As we near the end of March '08, we have reached a milestone in ProtoSOA development. The first "pre-release" of the software will be available on a very limited basis to approved ComFrame customers. This is a very short list at the moment, but having this version of the software available for trial and testing is a significant milestone.

In the next few months, my colleague and I will once again join the development team in Beijing to continue developing the first full public release of the product. I would like to recognize the efforts of the ComFrame Beijing office for all they have done toward building a quality product. This is a fine group of engineers who have proven to be a very valuable asset to ComFrame. Their efforts have not gone un-noticed in our company circles.

By year's end, I hope to report that ProtoSOA has begun an "SOA (R)Evolution" in the software industry. More to come...

Saturday, December 1, 2007

ProtoSOA

I'm thinking right now I wish I had more time to keep my blog updated!
At any rate, the current happenings on my plate are concerned with a new software product a colleague and I have been designing called "ProtoSOA". ComFrame Software is positioned to expand this design into a working product.

ProtoSOA is a Dynamic Enterprise Service Framework for Service Oriented Architecture (SOA) enablement. It is designed to allow business architects to define standard web services through metadata using administrative tools. The metadata not only provides the service descriptions, but also provides semantic mappings between canonical business terminology and “system terms” which are embedded in code. ProtoSOA not only exposes services that are fully compliant with current web service interoperability standards, it also seamlessly interacts with business process orchestration tools and provides the data transformation, transport, versioning, reliable messaging, security, auditing, and integration capabilities expected for an enterprise-class service bus.

If you would like to find out more about this product, please respond to this post.

That's all I have time for... later.

Wednesday, October 24, 2007

UML Training

Today I am preparing to teach a UML course at Emageon in Milwaukee, WI. I have presented this course several times for different clients in the past and have refined it each time. The central theme in my training is a "use case driven" process coupled with visual modeling. These two concepts are cornerstones to the USDP.

UML, therefore, is a visual expression and expansion of the use case model. The use case model is a reflection of the system requirements, and the UML model expands upon this model. It is beneficial to achieve both behavioral and structural views of the use case model using UML. Structural views manifest themselves as class diagrams, component diagrams, and collaboration diagrams, while behavioral views are manifested by activity diagrams, sequence diagrams, and state machines. Additionally, it is helpful to have a good mix of these diagram types -- each one is intended to address a specific viewpoint or level of detail.

Structural models address the "static" view of things. For example, class diagrams express the structure of classes, their associations with other classes, and their inheritance hierarchy. Behavioral models address the dynamic interaction of things in the system. For example, a sequence diagram emphasizes the messages between objects in a scenario, especially the sequence of those messages. It is very important to address both the structure and the behavior of objects in a system.

Another useful view is the State Machine, which is primarily used to express the complex behavior exhibited by a class, especially when the class exhibits different behavior depending on its state.

I have found that the most useful progression of UML modeling is as follows:
1) Begin with the use case model.
2) Expand the use case model using Activity diagrams.
3) Identify the "things" in the system. These are most evident by looking for nouns in the use cases and activity model. These are classes, modeled (of course) by a Class diagram.
4) Examine the simple behaviors of each class and how each class collaborates with other classes. Document these behaviors as operations on each class (in the Class diagram) and as collaborations (in the Collaboration diagram).
5) Document each scenario in which message sequence is critical by using a Sequence diagram.
6) In cases where objects exhibit complex, state-dependent behavior, use a State Machine.

For completed systems, use the Component and Deployment diagrams to depict the physical implementation and relationships among nodes.

Thursday, October 11, 2007

It occurs to me that some folks know about the Unified Software Development Process (USDP) and how it can ensure quality results. They may even act as process evangelists, helping IT shops implement process changes and USDP development techniques.

It also seems to me that some of them don't really believe in it. Maybe they understand the benefits from an academic perspective, but having never actually lived in a "process pure" environment, they see software development processes as intrusive and weighty.

The truth is, software development is chaotic by nature. The questions of "how do we begin", "how do we know when we are done", "what are our deliverables", and "what is quality" seem basic. However, it is surprising how often development projects are undertaken without understanding what these things mean. Even when process evangelists are involved from the beginning, when the team fails to follow the process systematically the project will begin to degrade toward chaos.

A good development process does not have to be heavy. The most important features (use case driven development, visual modeling, and iterative development) can be tailored to the project and the project team.

Following a USDP can lend order to the chaos. It provides focus to the development effort. Everyone on the team has a common mental picture of what must be done, how it should be done, what is being produced, how the components relate to each other, and how to know when they are done and done correctly. Even when things start to degrade, as they often do when schedules and budgets get tight, a good development process is self-healing. It provides the disciplines needed to regroup and re-focus the team, mitigate risks, resolve unforeseen issues, and establish corrective measures.

Actually putting the USDP into practice is the key to understanding its benefits. Once you have been on a development team whose focus is USDP, you will never want to do things the "old way" again.

Friday, September 28, 2007

My GNU Public Key

To encrypt data you send to me, or to verify docs digitally signed by me, please use my GNU Public Key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.2 (MingW32)

mQGiBEaJVpoRBAC7aD0MH+QpFj0FzZZ/A0eUIK6f0YxgueT2jHKcQqRhQzigimXi
Ztsg9YVGF+xpC2OJ9za/I6GNpG4kdI4+JhWWzKeKPygGTmx/xjA5tzGJX4zQAtGQ
af25S6jW1xEBJI81gGAvcTllbe6rKrFHHkYCN0dlBRtWg+H3fcNUetT05wCgvdJY
ipkBV7VTo9qZ2TlpOug0WRcD/2lL2r3i+buBe72FKpvCOfo3W3px8zPAywlryeC1
me2SAjWp4JxT9bE8GCcP5hXMJanlESO963xxgM7pig6riZUFe/fmrhgpUmm+PGns
rxScRVdhbNRewa2pPrrbWIrykMJAZHCabc5AX/QLLQ83VpaZB54Hn58Lv3jsiqVQ
ABZjBACiPR4IrqDh1+oNl/ILimtv4Wpv42LD4O4f8vGFQtc3Rh19Soo2H2qX3zyJ
vdmyW6ZLfoJkGZfw34UXTBesPkZlx8QPFCL/QaTwqXU9QYWxP223NGpPouOG4Na3
4JIpFYjM8gXboyhKF3D57DGMq0rFDoPj/+J0OZavK2BlccSNzbRQQmlsbCBXcmln
aHQgKFRoaXMgaXMgbXkgdmVyeSBzcGVjaWFsIENvbUZyYW1lIHB1YmxpYyBrZXkp
IDxid3JpZ2h0QGNvbWZyYW1lLmNvbT6IWwQTEQIAGwUCRolWmgYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRCEy9mEvjZ9SNrFAKChXVTk5pGx6ntDrCm9/2oYkuQqYgCf
UNTylzchwpQhDJz6XXuV7J9fIuG5AQ0ERolWnBAEAPsP8fWX+FoIQVhST/TySD4w
mbn8UsGD9UCPe7EfJKsGfVeteAQsU8+PUPxqDviSxnlSaouUftZl44Xt5KT3qKGX
PZdkcr9xjt5Y2+C2Qdd94mnTMj+WdtfeviXHzkRWo+HrJPygONGTB0zFwiVsuLJu
c1v+/C3xUVwcIEdjxq4/AAMHA/9I+G5UxOIS1GMFMblsz9lq7YGlkceIb4cKixpM
n9oMP0BQMKVnVnW3kOfFQaY69CE0BCmVK+k7Xh49EqaZ34KuWrXNSGkYF8r2saHB
YUyR0B+oEdIWF9JhC2FjA2M5BiPOGmU6OGSDzq8zmc6eZBq6FyCdeU2/dKzSOBTw
9F+VJohGBBgRAgAGBQJGiVacAAoJEITL2YS+Nn1IH8oAnjx0JWw2DdcoY316L5j9
G3GYYEXBAJsGhz569+k1AKmxzKVNGMhyWcx5bg==
=/RXh
-----END PGP PUBLIC KEY BLOCK-----